Kolejna ³ata.

Marcin Dalecki dalecki w cs.net.pl
Pon, 22 Lut 1999, 22:01:35 CET


Tomasz K³oczko wrote:
 
> Takie przej¶cie nie jest g³upie szczególnie je¿eli zauwa¿yæ dwa argumenty
> za takim przej¶ciem:
> - ksh jest du¿o mniejszy i szybszy,
> - ksh jest czystym sh.

Czyli mi³o widzie¿, i¿ znów jak zwykle w kwestich technicznych
nie mamy wielkich ró¿nic zdañ :-).

> Pierwszym etapem chyba jednak powinno byæ przestawieni ca³ej machiny
> startowej na nieu¿ywanie bash extensions. W etapie po¶rednim uzyskamy co¶
> co bêdzie mog³o pracowaæ pod dowolnym shellem sh compat.

Z tego ca ja do tej pory zauwa¿y³em przestawiaj±c wczoraj mój system
w domu na PLD, (do tej pory to od lat mia³em w³ase
skrypty inicjalizacyjne, bed±ce pochodn± SunOS4.xx), to te
bash-extensions,
jakie do tej pory widzia³em, s± w zasadzie równie¿ obejmowane przez
ksh. A ksh to standard POSIX b±d¿ co b±d¿. Nawet FreeBSD go instaluje.
Jedyne poprawki jakie musi³aem wprowadziæ to te które w³a¶nie ju¿
przes³a³em. Z wyjatkiem zmiany w #!/bin/bash na #!/bin/ksh. Poprawki te
zawieraj± równie¿ wyczyszczenia b³êdów w uzyciu bash-a, aczkolwiek s±
to b³edy tolerowane przez bash-a 2.0x... natomiast ju¿ nie przez
bash-1.14.xx.

I tu widzimy kolejny argument za przej¶ciem na pdksh. Ten siê
przynajmniej
trzyma jakiego¶ standardu a nie "wolnej improwizacji jazzowej" FSF.

> Samo ostateczne przestawienie na ksh musia³oby byæ w³a¶nie chyba
> poprzedone próbami takiego przej¶cia (prywatnymi) gdy¿ w niektórych
> miejscach zak³ada siê permanentn± obecno¶c basha. Dwa przyk³ady takich
> miejsc jakie mi siê w tej chwili nasyuwaj± na czo³o to:
> 
> - w indeksie info zak³ada siê, ¿e link do info z bashem jest zawsze i ¿e
>   nie ma sensu {de}rejestrowaæ jego stron,

To chyba nie tragiczne...

> - jak powy¿ej ale z {de}rejestracj± w /etc/shells.

Tego nie rozumiem. chsh? jest trafiony, czy co? Komu ³at± w ³eb?

> Nie wiem czy siê zgodzisz Marcina ale próba przej¶cia na u¿ywanie ksh
> powinna wygl±daæ IMHO nieco inaczej. Ja bym to zrobi³ w ten sposób, ¿e po
> pierwsze usun±³ te dwie powy¿sze odstêpstwa od regó³, zastanaowi³ siê w
> mniêdzyczasie czy nie jeszcze jaki¶ takich wybryków i od razu zmieni³
> zawarto¶æ dwuch pakietów .. ksh i bash. Chodzi o to ¿eby usun±æ linka
> sh -> /bin/bash z bash i dodaæ w ksh sh -> /bin/ksh. W ten sposób nie
> mieliby¶my konieczno¶ci przerabiania wszystkich skryptów przestawiaj±c im
> "#!/bin/sh" na "#!/bin/ksh", a od razu mamy prosty test na to czy wszystko
> jest zgodne z standardowym sh.

Zogda. Masz z pewno¶ci± racjê i sporo wiêcej pojêcia o pakietowaniu niz
ja. 
Ja to przej¶cie na systemie domowym zrobi³em rêcznie. Tak jak ju¿ raz 
wspomnia³em tu: Ja jestem raczej od kodowania...

> Dodanie ksh jako base shella nie jest g³upie ze wzglêdu na mo¿liwo¶æ
> zmieniejszenia base systemu. Faktem jest, ¿e wtedy skrypty sh pozostan±
> sh, a te które u¿ywaj± namiêtnie bash ext bêdzie mo¿na przerobiæ b±æ na
> standard b±æ zmieniæ im pierwsz± linijkê na "#!/bin/bash" i wtedy jawnie
> bêdzie widaæ, ¿e jest to ewidentnie bash skrypt, a nie "sh like".

W³a¶nie. Zreszt± jedyn± ¿ecz± której tak faktycznie brak w normalnym
sh to arytmetyka. Zak³adaj±c jednak, ¿e /bin/sh jest tak czy siak
linkiem na jakiego¶ klona ksh (albo pdksh albo bash) ten problem jest 
raczej czysto hipotetyczny. Na wszystkich nowoczesnych Workstations
jest z reszt± dok³adnie tak (Solaris-2.6, HPUX-10.x, Digital, itd.)

> > To co ja proponujê to jest raczej: bash jako szell interakcyjny.
> > pdksh jako /bin/sh i /bin/ksh. Naprawê róznica w prêdko¶ci
> > dzia³ania np. scryptów configure jest wrêcz *widoczna*...
> 
> Dok³adnie .. szkoda ¿e nie przeczyta³em tego najpierw :>
> 
> > W scryptach inicjalizacyjnych chêtnie bym u góry widzia³ to co siê
> > faktycznie stosuje, czyli /bin/ksh, co doskonale mo¿e byæ linkiem na
> > bash...
> 
> Zerknij jeszcze na to co napisa³em powy¿ej .. moze skorygujesz nieco
> zdanie :)

Jeep. Tylko, ¿e ja faktycznie jak do tej pory poza moj± ³at± jak do tej 
pory polegania na funkcjach bash-a niebêd±cych w zasiêgu ksh jeszcze nie
zauwa¿y³em.

> Generalnie jestem za przej¶ciem na ksh bo widzê zalety takiego
> rozwi±zania .. ró¿n± tylko widze drogê do takiego przej¶cia i wydaje mi
> siê, ¿e jest ona mniej "prowizoryczna" :)

Zgoda.

W  miêdzyczasie zerkna³em do miejsca maintainance pskdh. Aktualn± wersj±
jest pdksh-5.2.13.7. OK jest on nieco developer-ski, ale w
rzeczywistosci 
zawiera jedynie drobne korrekty b³êdów wraz z t± moj± ³at± na 5.2.12. 
Przekompilowa³em nim ca³e glibc i egcs, no i system siê wyci±ga na jego
bazie jako /bin/sh.

Mam ju¿ w domu odpowiednio dostosowany pakiet pdksh z PLD. Dzi¶ 
jednak nie by³em jeszcze na tyle na si³ach aby,
w¿uciæ to na ftp w robocie. Jutro chyba ju¿ to zrobiê. A wiêc Tomek 
sci±gnij to sobie potem z ftp://devleop.dacotec.net/pub

Umieszczê tam równie¿ pozosta³e ostatnio sendfile-owane przezemnie
pakiety...

Ah jeszcze pozwolê sobie na drobn± uwagê, dlaczego nie zalecam
/bin/sh podlinkowywaæ na bash-a. Otó¿: SECURITY.
Interpretacja zmiennych PSx w bash-u pozwala na do¶æ ciekawe zabawy.
Nie pamiêtam ju¿ wiêcej dok³adnie jakie by³y dalsze problemy, no ale
nie jestem te¿ specem od w³amañ...

Tak wiêc w FreeBSD domy¶ln± otoczk± dla korzenia jest zsh.
Pod Solaris-em w dokumentacji ostrzega siê *explicite* przed bash-em.
A w DLR (Deutsche Luft und Raumfahrt), gdzie kiedy¶ pracowa³em w
projekcie
dla Airbussa, rygor by³a taki, ¿e sotsowanie bash-a przez u¿ytkowników
by³o *surowo* zakazane. Nawiasem mówi±c podobnie jak i EMACS-a: 
"Bo tu u nas to komputery nie s± na wiwat, tylko do liczenia!", i racjê 
mieli cholera szwaby. Minê³o ju¿ do¶æ czasu, a wiêc mogê chyba bez
obawy, ¿e
smutni panowie w ciemych p³aszczach (nie ci z RH) podskocz± na
krzese³kach.

Apropo, ipcalc z rc-scripts flirtuje z jak±¶ dziwn± bibliotek± o której
jak do tej pory jeszcze nigdy nie widzia³em. Ju¿ go leczê...

--Marcin



Więcej informacji o liście dyskusyjnej pld-devel-pl