bash vs. dash és egyéb shell script problémák

Szkriptek: Python, Perl, Bash, ...

Lehet hogy ez Debian Squeeze specifikus, de lehet hogy mások is beleszaladnak.
1. script1 -ből szeretnék lefuttatni egy másik script2 -őt úgy, hogy a script2 -ben definiált és értéket kepott változókat megkapja a script1. A bash erre a "source ./script2" használja, de mit használhatok dash -ban?
Debian Squeeze -ben /bin/sh -> /bin/dash. Belenéztem az /etc/init.d scriptekbe, ott pl. a következő (számomra új) érdekes szintaxist találtam: 


if [ -f /lib/lsb/init-functions ]; then
  . /lib/lsb/init-functions
else
  # itt már semmi különös
fi

2. Próbálom összerakni a dash - bash különbségeket (a bash memória és terület igénye a sokszorosa a dash -nak, úgy gondolom érdemes vele foglalkozni) és találtam egy ilyet
http://princessleia.com/plug/2008-JP_bash_vs_dash.pdf
A 14-ik oldalon a "for" ciklus és a dash/bash beépített aritmetikai képességei kapcsán van egy "bonyolult" példa program: 


i=0
while ($i < 3)
do
  ...
  ((i++))
done

Na ez csak hibaüzeneteket generál, ráadásul a shell scripteknek megfelelően eléggé homályosat:
./prb-loop.sh: 12: cannot open 3: No such a file

Ez most mi lehet?

3. Arra gondoltam, jó lenne tudni (esetleg kellhet) hogy milyen shell -t is alkalmazok amikor futtatom a scriptemet. Nosza betettem:
echo "using shell = $SHELL"

No ez mindig azt írja hogy /bin/bash, tekintet nélkül, mit írok a script "fejlécébe" #! /bin/sh vagy /bin/bash és /bin/dash
Most ez egy hiba? - környezeti változó van rosszul beállítva.

Szerkesztve:
Kipróbáltam a $help parancsot - erre azt köpte ki, hogy "GNU bash, version 4.1.5(1)-release (x86-pc-linux-gnu)". Kezdek teljesen összezavarodni - a /bin/sh - a /bin/dash -ra mutat, így ha a shell script úgy indít hogy #! /bin/sh a dash fogja végrehajtani - a tudományából ítélve is. A drága jó Debian csak a felhasználót sz'vatja, az alap shell az a bash? Mire jó ez?

Szerkesztve:
Akkor most lehet, hogy az init scripteket is valójában a bash futtatja?

  • 3943 megtekintés

( zeller | 2012. 01. 21., szo – 14:25 )

Az a hibaüzenet teljesen világos, a "<" az egy átirányítás, és nem találja a shell a "3" nevű fájlt. Ha a dash tényleg összehasonlításra _is_ használja, akkor az szerintem igencsak problémás, vagy inkább baromi nagy f...ság.

1:0 oda! Kösz! Azt már kiszúrtam, hogy az illető úriember kicsit furcsa dolgokat írogat, a while ciklus feltételét sima zárójelek közé tette, én javítottam szögletesre, gondoltam valami szimpla elírás, de ez most akkor mi? Úgy írogat konkrét nyelvi különbségekről, hogy valami közbülső leíró nyelvet használ a példákban?
(Miért éppen nekem kell ilyenekbe beleszaladnom?)

* Én egy indián vagyok. Minden indián hazudik.

( mn3monic v | 2012. 01. 21., szo – 14:29 )

1. a . az a source
2. ez hülyeség, így esetleg: 

i=0
while [ $i -lt 3 ]
do
	echo $i
	let i++
done

3. debiannal érdemes megnézni az alternatives-t, ha jól tudom, de ezt passzolom.
--
HUPbeszolas FF extension

( tovis v | 2012. 01. 21., szo – 14:36 )

Ami viszont fontosnak tűnik, az ilyen vizsgálatoknál, hogy tudni melyik shell is működteti a scriptet. Tud valaki ilyet?

* Én egy indián vagyok. Minden indián hazudik.

( stra | 2012. 01. 21., szo – 14:54 )

1.) man dash:
 . file
  The commands in the specified file are read and executed by the shell.

3.) A SHELL változót exportálod a bash-ből, a dash meg nem állítja.
man bash:
 SHELL The full pathname to the shell is kept in this environment variable. If it is not set when the shell starts, bash assigns to it the full pathname of the current user's login shell.

 
 
"melyik shell is működteti a scriptet"
Ezt ugye célszerűen te határozod meg a script legelső sorában a hashbang után. Ha bash-t írsz, akkor bash lesz, ha dash-t, akkor dash-t, ha meg sh-t, akkor az, amelyikre az sh linkel. Annak nem sok értelmét látom, hogy sh-t kérsz, majd pedig ha dash-t kaptál, akkor a bash-specifikus kódot egy feltétellel kiiktatod. De ha más ötlet nincs, a readlink megteszi. 

readlink /bin/sh

Igen. Összeraktam egy kis scriptet: 


REF_SHELL=`ps -e -o pid,cmd | grep $$ | grep -v grep |awk '{print $2}'`
if [ -h $REF_SHELL ]
then
  echo "using shell: $REF_SHELL -> " `readlink $REF_SHELL`
else
  echo "using shell: $REF_SHELL"
fi

Ez a hashbang -re való tekintet nélkül megmutatja ki a shell.

Akkor most megpróbálom megérteni, mit is jelent a "The commands in the specified file are read and executed by the shell." - pl. mi van ha a másik script egy másik shell -re hivatkozik a hashbang -ben.

szerkesztve:
Nohát írtam egy ilyet: 


#! /bin/sh
#
. ./what-shell.sh
#
echo "SHELL_REF = $SHELL_REF"

A ./what-shell.sh a fenti kis kódot tartalmazza.
Nohát, a $SHELL_REF -ről a "meghívó" scriptnek fogalma nincs :(
Ha jól értem, ez a szintaxis csak arra jó, hogy amikor meghívjuk a másik scriptet, azt ugyanaz a shell hajtja végre - azaz nem hív meg egy újabb shell -t, ami végrehajtja a scriptet. Viszont, hogy mi zajlik le abban a scriptben arról fogalma nincs tekintet nélkül arra, hogy ez bash vagy dash.
Viszont akkor nem világos mire jó meghívni az init scriptekben egy olyan scriptet, amiben "csak" egy kupac funkció van?
Ami még nagyon fontos lenne, hogy tudok-e a bash "source" parancsának megfelelő utasítást használni a dash -ban?

* Én egy indián vagyok. Minden indián hazudik. 


REF_SHELL=`ps -e -o pid,cmd | grep $$ | grep -v grep |awk '{print $2}'`

helyett: 


ps -p $$ -o ucomm=

Viszont akkor nem világos mire jó meghívni az init scriptekben egy olyan scriptet, amiben "csak" egy kupac funkció van?

Azért, hogy használd őket. A közös függvényeket szokás így külső fileba rakni amit újból fellehet használni több helyen. Gondolj rá úgy mint C-ben az #include-ra.

Ami még nagyon fontos lenne, hogy tudok-e a bash "source" parancsának megfelelő utasítást használni a dash -ban?

Ezt hogy érted? Előbb használtad a "." parancsot az ugyan az. Vagy lemaradtam valamiről?

A . vagy source lényegében include-olja az utána megnevezett file-t, s az eredeti shell hajtaj azt végre. A hashbang a source-ban nem számít, hiszen az komment lesz.

Külön shell már csak azért sem hajthatja végre, mert akkor az önálló process-ben futna, az önálló memóriaterületet foglalna, s akkor el is veszítenéd az ottani változókat. Különben lehet subshell-ben futtatni valamit, ehhez sima, gömbölyded zárójelbe kell tenni azt, amit subshell-ben futtatnál.

Gondold végig mi történik így:

valtozo=alma
echo szilva | read valtozo
echo "$valtozo" # azt fogja kiírni, hogy alma, s nem azt, hogy szilva

Ez ugye azért van, mert a pipe miatt önálló shellben, külön process-ben futott a read, s a kilépéskor fel is számolódott a memóriaterülete. A read utáni valtozo egy egészen másik shellben lett definiálva, aztán meg is lett szüntetve. A mi változónk továbbra is alma értékű. Erre érdemes figyelni, különben keresheted a hibát napestig egy script-ben.

Az initben a függvényeket csak be kell include-olni, hogy meg lehessen őket hívni, nem?

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

A . és az "source" parancs NEM ugyanaz.

1. A dash nem ismeri az "source" parancsot.

2. A . valóban ugyanabban a shell folyamatban fut (így erőforrásokat takarít meg), viszont az így be "includeolt" scriptben létrehozott, módosított változók nem jönnek át a scriptet "includoló" scriptbe. Ha az "includolt" script változói, érték módosításai kellenek, akkor azokat "export" -al kell definiálni.

3. A "source" parancsal "includolt" script úgy hajtódik végre, mintha a meghív script része lenne.

Amit még nem próbáltam ki, hogy mi lesz a . paranccsal "includolt" scriptben de3finiált funkciókkal - ez azért is érdekes, mert mint azt írtam a Debian /etc/init.d/ scriptek hemzsegnek az ilyen parancsoktól.

Remélem nem értettem félre amit írtál.

* Én egy indián vagyok. Minden indián hazudik.

A dash-t nem ismerem, nem használtam. Bash-ben a . és a source ugyanaz, nézd meg a manualban. Mivel lényegében include, így a .-tal vagy source-szel beszúrt file-ra nem kell futtatási jog, elég olvasás, valamint nem kell export, a változó sima definiálás után a "hívó" script-ből elérhető. Mivel nem hívás történik, csak egész egyszerűen beszúrás, behelyettesítés.

4.2.20-as bash-ről beszélek, Fedorán ez van.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"A . valóban ugyanabban a shell folyamatban fut [...], viszont az így be "includeolt" scriptben létrehozott, módosított változók nem jönnek át a scriptet "includoló" scriptbe. Ha az "includolt" script változói, érték módosításai kellenek, akkor azokat "export" -al kell definiálni."
Ezek az információk honnan származnak?! Tudnál valami forrást idézni, például manual?

Most a bash és a dash viszonylatában beszélünk erről? A dash, ahogy írtad, nem ismeri a source-ot, csak pontként. A bash manualja pedig egyértelműen leírja, hogy a két forma ugyanaz.

De tegyünk egy próbát a 2. pontodnak megfelelően:

A két forrás: 


  $ cat a.sh
  #!/bin/bash
  
  V=135
  echo "A1: $V"
  . b.sh
  echo "A2: $V ; $W"
  $

  $ cat b.sh
  #!/bin/bash
  
  echo "B1: $V"
  V=246
  W=357
  echo "B2: $V ; $W"
  $

Szerinted 135 és semmi lenne az a.sh utolsó (A2) eredménye. Valójában pedig: 


  $ ./a.sh
  A1: 135
  B1: 135
  B2: 246 ; 357
  A2: 246 ; 357
  $

És hogy mi produkálta ezt a szerinted nem megfelelő eredményt? Egy Debian Squeeze, pont olyan, mint a te rendszered. 


$ bash --version
bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$

No még egyszer.
dash "." lefuttatja a "beágyazott" scriptet, de az ott definiált változók, módosított változók, nem kerülnek át a másik scriptbe.

A bash "." parancsával nem foglalkoztam, mivel ott erre a feladatra ott a "source" és az egyértelmű.

Nálad a mind két script hashbang = /bin/bash - azaz NEM /bin/sh ami a Squeeze -n, alapértelmezés szerint a /bin/dash -ra mutat (lásd a "what-shell.sh scriptemet) - vagyis az általad mutatott esetben a "source" és a "." utasítás ugyan azt az eredményt adja, mivel a bash -t használja.

megjegyzés: ahogy a cím is mutatja a bash vs. dash összehasonlítás fontos számomra, és gondolom mások számára is fontos lehet akinek takarékoskodnia kell az erőforrásokkal (bash 905K / dash 102K és ez csak a futtatható fájl mérete Squeeze -n amd64).

* Én egy indián vagyok. Minden indián hazudik.

No még egyszer. Sem a tapasztalat, sem a manual nem támasztja alá amit írsz. Ezért kértem valami forrást, manualt, esetleg példát.

"dash "." lefuttatja a "beágyazott" scriptet, de az ott definiált változók, módosított változók, nem kerülnek át a másik scriptbe."
Állításod az, hogy dash esetén az előző példascript A2 sora 135 és semmi lesz.

Ha fixen dash: 


  $ cat a.sh
  #!/bin/dash
  
  V=135
  echo "A1: $V"
  . ./b.sh
  echo "A2: $V ; $W"
  $

  $ cat b.sh
  #!/bin/dash
  
  echo "B1: $V"
  V=246
  W=357
  echo "B2: $V ; $W"
  $

  $ ./a.sh
  A1: 135
  B1: 135
  B2: 246 ; 357
  A2: 246 ; 357
  $

Ha sh, ami link a dash-re: 


  $ ls -l /bin/sh
  lrwxrwxrwx 1 root root 4 Jul 22  2011 /bin/sh -> dash
  $

  $ cat a.sh
  #!/bin/sh
  
  V=135
  echo "A1: $V"
  . ./b.sh
  echo "A2: $V ; $W"
  $

  $ cat b.sh
  #!/bin/sh
  
  echo "B1: $V"
  V=246
  W=357
  echo "B2: $V ; $W"
  $

  $ ./a.sh
  A1: 135
  B1: 135
  B2: 246 ; 357
  A2: 246 ; 357
  $

A kérdés továbbra is az, hogy ha nálam rendben működik Squeeze alatt mind bash, mind dash, mind dash-re symlinkelt sh, miküzben nálad pedig nem, akkor vajon hol lehet a gond, és az állításod alátámasztja-e valami forrás.

Na most összezavarodtam - ha már ennyire unszoltál, csináltam két kis scriptet: 


#! /bin/sh
# script a.sh
#
ARG2=$(($ARG2 + 4))
ARG1=0
ARG1=$(($ARG1 + 5))

#! /bin/sh
# script b.sh
#
ARG2=0
. ./a.sh
echo "ARG1 = $ARG1"
echo "ARG2 = $ARG2"

Az eredmény ARG1=5 és ARG2 = 4 - teljesen jó!? Most akkor én mi az ördögöt tapasztaltam? Tény hogy az igazi scriptjeimet a busybox html appletje mozgatja, de ő is csak ugyanazt a Squeeze rendszert használja és ott a hasonló definíció nem működött.
Így most a dash "." parancsa megfelel a bash "." és akkor az eddigi vizsgálatok szerint a bash "source" parancsával is (bár akkor nem világos miért ugyanarra két ennyire különböző szintaxis ugyanazon a shell -en belül).
Amit még meg kellene vizsgálnom, az az hogy mi a helyzet a funkciókkal - nagy valószínűséggel azokat is átveszi.

* Én egy indián vagyok. Minden indián hazudik.

( uid_2716 | 2012. 01. 21., szo – 15:47 )

Az interpreter hashbang általi kijelölése nem hordozható (ld. SUS).

Az egyetlen biztos dolog, amit tehetsz, az a dokumentáció -- levenni az exec jogot a scriptről, eltávolítani a hashbang-et, ezáltal rákényszerítni a felhasználót, hogy kézzel adja meg az interpretert. (Azaz a futtatáshoz "bash script", vagy "dash script", vagy SUS-kompat. környezet beállítása után "sh script" parancs kell.) Hogy konkrétan mivel futtassa, azt meg mondd meg neki a dokumentációban.

A C shell kiment a divatból; ha nem így történt volna, sokkal kisebb kavarodást tudnának ma okozni a ksh/bash/dash apró eltérései. Ui. a C shell azonnal pofára esik az utóbbiak script-jein (és vice versa), tehát (úgy saccolom) az emberek nem is nagyon próbálkoznának egy biztos közös nevező megkeresésével. Simán megmondanák, melyik shell-hez készült a script és kész.

(Ezen belül természetesen a SUS shell nyelvét érdemes leginkább választani, mert azt fogja tudni a legtöbb gyártó ilyen vagy olyan shell-je (a megfelelő beállításokkal) értelmezni.)

Összefoglalva: ha szükséged van bash-specifikumokra, akkor írd abban, és követeld meg a doksiban. Ha nincs, akkor írd a shell script-et POSIX/SUS szerint (linkek alant), és követeld meg a felhasználótól az ő adott POSIX shell-jével való végrehajtást. (linyukszon ez leginkább dash, esetleg bash --posix.)

SUSv2: shell command language, UNIX 98 tanúsított rendszerek listája

SUSv3: shell command language, UNIX 03 tanúsított rendszerek listája

SUSv4: shell command language

Alapvetően a SUSv3-ra lőnék; GNU/Linux-oknak elvileg tudniuk kell (dash-sal vagy bash --posix-szal), ill. a FreeBSD is arra figyel.

kiegészítés: a "." utility már SUSv2 óta standard (legalábbis a fent linkeltek közül ez a legkorábbi, mert valójában már a SUSv1-ben is benne volt, illetve bizonyára annak az előd-specifikációiban is).

http://pubs.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_0…

Köszönöm!
Sejtettem, hogy ez a megoldás "as is" hiszen, ha a hasbang -et kihgagyom akkor is működik, tehát semmi nem kötelez a használatára (nem úgy mint amikor először találkoztam azzal, hogy az általam írott C üngyümke-büngyümke amit i386 -os architektúrán fordítottam, nem indult el x86 -on, sőt nem is találta, holott az ls mutatta, hogy ott van és az engedély "futtatható", beletelt néhány másodpercbe míg rájöttem mi a helyzet :).

Mindenesetre, ünnepélyesen megfogadom, hogy mindig beírom a hasbang -et! Knuth engem úgy segítsen!

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2012. 01. 21., szo – 16:19 )

Hazudós vagyok, illetve a saját figyelmetlenségem ártatlan áldozata :D
Kicsit átalakítva az előző scripteket (mellőzve az elírásokat):
[code]
#! /bin/sh
# első script: what-shell.sh
export REF_SHELL=`ps -e -o pid,cmd | grep $$ |grep -v grep | awk {print $2}`
if [ -h $REF_SHELL ]
then
export REF_SHELL=`readlink $REF_SHELL`
fi
echo "using shell: $REF_SHELL"

#! /bin/sh
# második script: prb-source.sh
. ./what-shell.sh
echo "REF_SHELL = $REF_SHELL
[code]

Így már működik, az hogy a második script megkapja a változót és annak értékét.
Érdekességek:
- Ha az első scriptben a hasbang -et átírom /bin/bash -ra (a második scriptben marad a /bin/sh - azaz jelen esetben dash) a REF_SHELL /dash lesz.
- Ha a második scriptben, a hashbang -er /bin/bash -ra teszem akkor REF_SHELL értéke /bin/bash lesz.
- Ha az eslő scriptben a második, feltételes értékadásból kiveszem aaz "export" kulcsszót akkor is a helyes érték "jön át" az első scriptbe vagyis dash (mindkét scriptben a hashbang /bin/sh).
- Miután kilépek a felhasználói shellbe (ahonnan futtattam a scripteket) a REF_SHELL elvész.
Ez így nekem tetszik!

* Én egy indián vagyok. Minden indián hazudik.

Ahogy a manból is idézted: "The commands in the specified file are read and executed by the shell.". Shell, és nem subshell. Az "érdekességek" részből úgy veszem észre, éppen ezt a lényeget nem találtad meg a fentiekben. Minimálisan kifejtve hozzávetőlegesen ezek az okok:

Source-ot (.) használsz, tehát ennek hatására az alapeset ez: 


  #!/bin/sh
  # második script: prb-source.sh
  #!/bin/sh
  # első script: what-shell.sh
  export REF_SHELL=`ps -e -o pid,cmd | grep $$ |grep -v grep | awk '{print $2}'`
  if [ -h $REF_SHELL ]
  then
    export REF_SHELL=`readlink $REF_SHELL`
  fi
  echo "using shell: $REF_SHELL"
  echo "REF_SHELL = $REF_SHELL"

 
"Ha az első scriptben a hasbang -et átírom /bin/bash -ra (a második scriptben marad a /bin/sh - azaz jelen esetben dash) a REF_SHELL /dash lesz."
Mert az egy egyszerű komment lesz. (Az első sorban pedig egy, a hívó shell által speciálisan értelmezett komment.) Megközelítőleg így: 


  #!/bin/sh
  # második script: prb-source.sh
  #!/bin/bash
  # első script: what-shell.sh
  export REF_SHELL=`ps -e -o pid,cmd | grep $$ |grep -v grep | awk '{print $2}'`
  if [ -h $REF_SHELL ]
  then
    export REF_SHELL=`readlink $REF_SHELL`
  fi
  echo "using shell: $REF_SHELL"
  echo "REF_SHELL = $REF_SHELL"

 
 
"Ha a második scriptben, a hashbang -er /bin/bash -ra teszem akkor REF_SHELL értéke /bin/bash lesz."
Természetesen, mivel az az első sor, ennek megfelelően van megkülönböztetett jelentősége.
 
 
"Ha az eslő scriptben a második, feltételes értékadásból kiveszem aaz "export" kulcsszót akkor is a helyes érték "jön át" az első scriptbe vagyis dash (mindkét scriptben a hashbang /bin/sh)."
Az ok ugyanaz, mint ami a többinél. Ahogy Kambus írta, ez innentől egyetlen scriptnek tekinthető, tehát az export nem oszt, nem szoroz. (A feltételben meg felesleges másodszor is exportra jelölni a változót, mivel már megtetted előtte.)

Ha saját szemmel is meg akarsz győződni a fentiekről, akkor tegyél a shell neve mögé egy -v paramétert is (vagy set -o verbose).

Az "érdekes" helyett talán summázatot vagy megjegyzendőt kellett volna írni.
"A feltételben meg felesleges másodszor is exportra jelölni a változót" - neked ez lehet hogy világos, nekem nem volt az. Érdekes lehet az is, hogy mi lesz ezekkel a változókkal, ha egy összetett script, több külön scriptben is módosítja az értékét, uram bocs'á rekurzív hívások.

Eddig ennél sokkal egyszerűbb dolgokat írtam shell -ben, inkább csak arra használtam, hogy a bonyolult, sok argumentumos parancsokat automatizáljam ne kelljen mindig ugyanazt bepötyögni. A shell inicializációba is bepakoltam néhányat (alias), a kedvencem
alias addr='netstat -ie | grep -B 1 inet'
ez kidobja az összes felkapcsolt interfészt és a címüket (beleértve az ethx:y is).

Összeraktam olyat is, hogy scriptből 4-5 ablakos screen ami különféle programokat és scripteket futtat. Ha nincs különös sebesség kritérium, az ilyen kombó elég komplex feladatot el tud látni. Az indító scriptből exportált változókat mindenki látja, de nem igen tudják a többiek számára is láthatóan módosítani - amikor egy scriptet elindítasz az megkapja ezeket a változókat és a pillanatnyi értéküket, saját magának módosíthatja is őket, azonban a többi script ezt nemigen látja.

Ha most ezt megvadítod úgy, hogy ezek valójában cgi scriptek ... mókás:)
Viszont nagyon gyorsan lehet javítani/módosítani, ha egyébként nincs koncepcionális hiba.

* Én egy indián vagyok. Minden indián hazudik.