mksh exec bug.
Tomasz Pala
gotar at polanet.pl
Sun Jan 15 21:31:05 CET 2012
On Sun, Jan 15, 2012 at 20:41:25 +0100, Adam Osuchowski wrote:
>> alternatives - może i tak, ale NIE dla /bin/sh
>> System _musi_ być robiony pod konkretnego shell-a i nic tego nie zmieni.
>
> I co w takim razie zrobisz z przypadkiem od którego zaczął się ten wątek?
> Jak wg Ciebie ,,system musi być robiony'', żeby to zadziałało skoro
> aktualny /bin/sh nie wspiera danej funkcjonalności?
Można mu dać #!/bin/dash albo #!/bin/bash - ale kto wybierze, który? Ja
bym preferował #!/bin/zsh, pewnie też działa:)
> 2. Weryfikujemy takie przypadki i jeżeli skrypt wymaga funkcjonalności
> np. basha to odpalamy go z ,,#!/bin/bash'' a nie ,,#!/bin/sh''. Kto
> powiedział, że każdy skrypt shellowy w systemie musi być pod /bin/sh?
No właśnie. Problem będzie z tym, że i tutaj mamy alternatywy... Więc
może /bin/sh, /bin/sh2, /bin/sh3, /bin/sh4? ;) Ale poważnie...
> W tym przypadku różne usługi mogą wymagać różnych shelli, które można
> postawić obok siebie. Natomiast skrypty wykorzystujące wspólne
> funkcjonalności (lub te wprost i ściśle zdefiniowane w standardzie) mogą
> być uruchamiane z /bin/sh, co tym bardziej nie przeszkadza we wsadzeniu
> /bin/sh do alternatives.
Jak rozumiem Paweł obawia się tego, że dając wybór ograniczamy się do
zestawu funkcji nie jednego shella, lecz przecięcia zbiorów wszystkich
powłok dopuszczalnych jako alternatywy i w ten sposób może się okazać,
że coraz większa liczba skryptów będzie wymagała wskazania tego jednego
konkretnego, na którym działa, a w skrajnym przypadku, gdy jakieś echo
będzie działało odwrotnie w 2 implementacjach, w ogóle nie będziemy
mogli /bin/sh mieć, albo trzeba będzie odwalić bezsensowną robotę
połatania góry skryptów.
I tutaj zupełnie poważnie bym się zastanowił, czy nie lepiej po prostu
zacząć używać czegoś full-featured & maintained jak zsh. I kto wie, może
nawet bash byłby alternatywą, bo odkąd go ostatnio używałem naprawili
sporo byków.
--
Tomasz Pala <gotar w pld-linux.org>
More information about the pld-devel-pl
mailing list