Dotaz: závorky v shellu

[RM]

Dobrý den, snažím se přijít na to, jestli je nějaký rozdíl v

sleep 60 &

a

(sleep 60) &

Přijde mi to stejné?

---

---

Odpovědi

[petr_p]

Kulatá závorka v shellu spustí uzávorkovaný příkaz v novém shellu. Vypadá to, že pokud je uzávorkovaný jen jeden příkaz, bash vynechá spuštění podshellu jako nového procesu. Ale i tak se použije prostředí podshellu. (Například FOO=1 & nenstaví proměnnou FOO v aktuálním shellu.)

[RM]

podshell se spustit musí kvůli & (hádám) i přesto, že jde o builtin příkaz. Právě z toho důvodu mi přijdou závorky už zbytečné. Ale jen hádám.

[RM]

& .. spouští nový proces (to je mi jasné)

[RM]

ještě abych tady nezdržoval. Jde mi o tohle: Závorky spouští nový subshell, & musí také spustit subshell, to jsou tedy dva subshelly (nejspíš vnořené); leč to se asi nestane (podle toho co ukáže ps), takže si to shell přebere tak, že to spustí na pozadí v jednom subshellu. Podle toho usuzuju, že v tomto případě nemají závorky žádný efekt.

[Jakub Lucký]

Pokud by to tedy nemělo funkční význam, je asi vhodnější používat (builtin_cmd) &. Stejnou věc řeším také u funkcí. Ono, když člověk volá funkci bez parametru na novém řádku, kde už nic jiného není a funkce nic nevrací, pak to nevypadá hezky a místo lze i snadno přehlédnout. Pokud je taková funkce v závorkách, které navíc správný editor zvýrazní, tak už je to hned o něčem jiném. Přičemž i v tomto případě si to shell zřejmě přebere a spustí jeden subshell. Pokud to tak je, pak závorky, které mají skupinový význam a spouští subshell, mohou mít také význam syntaktický a ničemu to vadit nebude.

[nobody]

tak nevim, ale co pouzivam mcedit nebo mousepad tak zvyraznuji sleep stejne i bez zavorek :)

[RM]

Chtěl jsem tím krátce řici, že je třeba mít editor, který podporuje syntaxi a zvýrazní v shellu závorky (o sleep tady nešlo, šlo o funkce). Něco k věci nemáte?

[nobody]

tak nejdriv pises sleep a builtin prikaz a najednou je z toho funkce ? ;)

ragoval jsem k teto veci "Pokud je taková funkce v závorkách, které navíc správný editor zvýrazní, tak už je to hned o něčem jiném" - mcedit i mousepad zvyraznuje syntaxi sh scriptu...

ale vidim ze si v tomto vlakne vystacis sam, tak nebudu rusit a pozdravuj sve nafoukle ego a pofoukejte si oba sve kuri oko ;)

[RM]

"funkce v závorkách" a ne příkaz shellu (sleep), ale díky za informaci o editorech

[RM]

Nyní koukám, že ve Vaší krátké odpovědi je mnohé z toho, co jsem potřeboval vědět. Nejprve jsem ale musel zkorigovat některé své nesprávné domněnky. Takže díky.

[petr_p]

Není nad to, když si člověk přijde na řešení sám :)

Kdybyste chtěl vědět, proč zrovna takhle to bash dělá, doporučuji zeptat se jeho autorů.

[RM]

Ten Váš příklad s FOO je velmi dobrý ke zkoumání. Pokud místo read i (viz tabulka) použiji FOO=1, pak se ani v jednom případě proměnná v aktuálním shellu neprojeví. Pokud ale nepoužiji fork (&), pak se nenastaví jen v případě uzávorkovaného výrazu (FOO=1). To tedy znamená, že prostředí sub-shellu se použije vždy v případě forku (kde jsem uváděl 0x). Moje domněnka, že sub-shell se musí použít stejně, nebyla tedy zcela špatná :).

[RM]

Rychlá pomoc v sobotu nepřišla, a tak jsem se to jal ještě trochu prozkoumat. Tabulka obsahuje počet spuštěných sub-shellů v bashi a ashi. Příkaz jsem volal ve skriptu, pro zjištění jsem používal příkaz ps f.

 
 .-----------------.-----.------.
 | cmd             | ash | bash |
 +-----------------+-----+------+
 | sleep 60 &      |  1x |  1x  |
 | (sleep 60) &    |  2x |  1x  |
 | { sleep 60; } & |  1x |  2x  |
 '-----------------'-----'------'

Výsledky jsou překvapivé. Pokud nechceme spouštět zbytečně sub-shehll v sub-shellu, pak závorky takto raději nepoužívat, nedá se na to v různých shellech spoléhat (viz můj dotaz a (sleep 60)& , kdy mi to v bashi prošlo ). Proč bash spustí 2x sub-shell v případě složených závorek je mi zatím záhadou.

[luky]

Prijde mi, ze mate vsude o jedna vic. Sleep neni subshell ale normalni program, z ostatnich komentaru jsem dosel k zaveru za ho mylne povazujete za built-in.

Duvod, proc se v pripade jednoho prikazu v ( ) & nespusti dalsi shell je optimalizace - je to to stejne, jako by tam zavorky nebyly.

Osobne povazuju to, co chete udelat, za peknou blbost - predstavte si, az ten skript bude nekdo cist a bude si rikat, proc se to vsechno spousti v subshellu, kdyz to nema zadny vyznam a ten neexistujci vyznam v tom bude hledat.

[RM]

Mate pravdu, sleep je program. Byl jsem na tom, ze je stejne jako read nebo echo, builtin.

[RM]

Prijde mi, ze mate vsude o jedna vic

Jj, dosud jsem se domníval, že každý subproces je stejně spuštěn v subshellu. Nějak jsem si nedovedl představit, že by se file deskriptor mohl nastavit jen pro program bez subshellu. Takže to jsem si nyní vyjasnil, že lze spustit také subproces samotný a deskriptory se mu stejně nastaví.

Co se týče optimalizace, našel jsem pár odkazů, které se poměrně podrobně zaobírají tím, na co jsem se tu ptal. Nyní je mi tedy zcela jasné, že používat () případně {} pro obalení volané funkce, není dobrý nápad. Vzešlo to ale z toho, že jsem (cmd) & viděl v jednom příkladu použité. A jak píšete, přemýšlel jsem nad tím, proč to autor použil, načež jsem to porovnal v bashi, kde -- jak vidno -- není rozdíl. A teprve na základě toho mi napadla možnost, nějak to využít.

Takže díky za nasměrování. Je to věc trochu méně přehledná. Nějaká pravidla se z toho ale přece nechají vyčíst. Zde jsou mé upravené (a rozšířené) pokusy, pokud by to někomu pomohlo:

 .-----------------.-----.------.
 | ext prg         | ash | bash |
 +-----------------+-----+------+
 | sleep 60 &      |  0x |  0x  |
 | (sleep 60) &    |  1x |  0x  |
 | { sleep 60; } & |  0x |  1x  |
 '-----------------'-----'------'

 .---------------------------.-----.------.
 | more ext prg or pipe      | ash | bash |
 +---------------------------+-----+------+
 | (sleep 30; sleep 30) &    |  2x |  1x  |
 | { sleep 30; sleep 30; } & |  1x |  1x  |
 '---------------------------'-----'------'

 .-----------------.-----.------.
 | f() {sleep 60}  | ash | bash |
 +-----------------+-----+------+
 | f &             |  1x |  1x  |
 | (f) &           |  2x |  1x  |
 | { f; } &        |  1x |  1x  |
 '-----------------'-----'------'

 .-----------------.-----.------.
 | builtin cmd     | ash | bash |
 +-----------------+-----+------+
 | read i &        |  0x |  0x  |
 | (read i) &      |  1x |  1x  |
 | { read i; } &   |  0x |  0x  |
 '-----------------'-----'------'

Snad už je tedy vše správně, začíná mi z toho pozorování subshellů a subprocesů jít hlava kolem.

[RM]

oprava: pro (read i) & v tabulce má být také 0x v obou případech