Kolejna ³ata.

[Grzegorz Stanislawski]

On Tue, 23 Feb 1999, Tomasz Kłoczko wrote:

> Grzesiek czy w takim razie mógłbyś przedstawić interpretację sytuacji
> związanej z zajętością pamięci w przypadku kiedy mamy bash+bash, bash+ksh
> i ksh+ksh ? Jeżeli widzicie także jakieś inne konsekwencje takiej zmiany
> oprócz różnic w prędkości (sprawdzałem z configure z ksh jakiego mam
>
 Widze takie konsekwencje ze bedzie "burdel" w rc-scriptsach.
 W porzadku, jesli ksh jest kompatybilny w stosunku do wiekszoci tego 
co w bashu to musze sie wycofac z mojego poprzedninego stanowiska.
Myslalem ze jest to cos dziwnego jak (t)csh.
Oczywisie dalej stoje po stronie basha, chocby z uwagi na locale ($""),
ktore predzej czy pozniej pojawia sie w rc-scriptsach.

Proponuje pobawic sie nastepujacym skryptem:
---
#!/bin/bash
export A=`expr $A - 1`
echo $A
if [ $A = 0 ] ; then
cat /proc/meminfo;
exit;
fi
./test.sh;
---
jak go zapiszemy pod nazwa ./test.sh i ustawimy zmienna A na jakas wartosc
np. export A=20 i uruchomimy, odpali sie rekursywnie 20 razy bash.
po zakonczeniu mozemy sobie porownac tamto /proc/meminfo z nowym.
U mnie wychodzi przy 20 srednio 135k na kazdego basha.

Aa, te wlasciwosc kernela zle nazwalem, copy-on-write wystepuje podczas
forkowania. 

>  
> Decyzja co do zmiany bazowebo /bin/sh nie jest czymś mało istotnym. W
> takiej sytuacji dobrze by było żeby ta decyzja nie była podjęta na
> podstawie impusu.
> 
Decyzja jaki powinen byc bazowy shell powinna IMHO nalezec do
_administratora_ _konkretnego_ _systemu_. Zaczynam obserwowac ze PLD robi
sie za bardzo Windowsowate. Nie uszczesliwiajmy ludzi na sile.

> 
> kloczek
> -- 
Grzegorz Stanislawski
Open-Net / PKFL