Shellová zábava (diskuse)

[Max]

Tak o dashi se ví, že toho moc neumí a není na takové úrovni jako bash. Ostatně to myslím nebyl ani jeho záměr.
Každopádně, jaký smysl má zápis "V=1 f" kromě testování syntaxe různých interpretů?

Jinak odpověď na to, proč symlink "/bin/sh -> /bin/bash" dává jiný výsledek, najdeš v manpage, cituji :

"If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well."

Zdar Max

[Marcel Šebek]

Hm, zajímavý, tušil jsem, že bash se o něco takového bude pokoušet, ale man jsem důkladně nepročítal.

Jen tak mimochodem, na problém jsem paradoxně přišel tím, že skript mi nefungoval v bashi, ale v dashi fungoval.

[Michal Kubeček]

Ten dash se takhle podivně chová i v případě, že je tam místo funkce normální (ne builtin) příkaz?

[Marcel Šebek]

Ne, pro příkaz (builtin se dash chová normálně, jen pro funkci to ponechá hodnotu nastavenou. Problém je, že ze syntaxe není vždy na první pohled jasné, zda jde o funkci nebo o příkaz.

[Odin]

Jak jste sam napsal, problem to neni. Proste to nepouzivejte a muzete v klidu spat.

[skunkOS]

Přesně toto je popsáno i v Advanced Bash Scripting Guide, který je imho perfektní pro naučení Bashe.

[Michal Kubeček]

Každopádně, jaký smysl má zápis "V=1 f" kromě testování syntaxe různých interpretů?

Hodně často se to používá např. v konstrukcích typu

  ... | LC_COLLATE=C sort

Obecně v situaci, kdy potřebujete spustit konkrétní příkaz s určitou hodnotou určité proměnné, ale nechcete ji nastavovat (jako exportovanou) v environmentu shellu, okdud by ji zdědily i všechny ostatní příkazy.

To chování dashe (jestli se tak opravdu chová a nebyla to nějaká jiná chyba) je hodně nešťastné a obávám se, že to rozbije hodně skriptů.

[pc2005]

+1 Jo už jsem to chtěl taky napsat.

Já teda nejčastěji používám LD_LIBRARY_PATH="něco" program. Třeba ve steamu je to všude.

btw Ještě u toho sortu by mohl být rozdíl mezi funkcí bashe a externím programem, ale stejné chování u obou je prostě logické.

[kralyk z abclinuxu]

Každopádně, jaký smysl má zápis "V=1 f" kromě testování syntaxe různých interpretů?

Tenhle zápis mi přijde jako naprosto běžná věc, například CC=/nekde/nejaky/cc make . Něbo máš na mysli specificky při používání shellových funkcí (ie. ne programů)? V takovém případě to je, pravda, asi trochu neobvyklé...

[Max]

Ano, myslel jsem v případě použití shellové fce, ale ono to smysl dává, jen to nevídám, tak mi to přišlo divný.
Zdar Max

[snajpa]

Jsem jediny, kteremu v kontextu poslednich udalosti mrazi v zadech pri cteni "narazil jsem na podivne chovani..."?

[mimi.vx]

j,

 

na vetsinu poslednich veci se neprislo nahodou ale celkem dost usilovnou praci velmi dobre placenych lidi

[marbu]

Ne :)

[Odin]

Ehm a co je divneho na tom, ze si to kazdy shell implementuje po svem, kdyz, jak jste si ostatne sam dohledal, standard toto chovani nedefinuje? Myslim, ze to snad ani nestoji za ten blogpost. Ono vubec obecne pouzivat globalni promenne neni dobry napad a to nikdy a v zadnem normalnim jazyku.

[mimi.vx]

a v tomto pripade se jedna ciste jen o  lokalni definici promene pro konkretni volani funkce f bez zasahu do env..

takze bash se narozdil od dashe chova logicky

[Odin]

Jiste, chovani bashe je v tomto asi lepsi, ale to nic nemeni na tom, ze jine shelly to implementuji po svem a nelze to oznacit za spatnou implementaci. Proste neni v 99 procentech pripadu dobry napad toto pouzit.

[mimi.vx]

jj, bud clovek musipsat dle posixu a davat si pozor na nedefinovane veci. A nebo proesne specifikovat shell/jazyk

[xkucf03]

co je divneho na tom, ze si to kazdy shell implementuje po svem

Smyslem konstrukce:

PROMĚNNÁ=hodnota nějaký-příkaz;

je spustit nějaký-příkaz s danou hodnotou proměnné prostředí – zatímco jiné/následující příkazy chci spouštět bez této proměnné resp. s její původní hodnotou – jinak bych totiž napsal:

PROMĚNNÁ=hodnota;

nějaký-příkaz;
nějaký-další-příkaz;

[RM]

Tak on příkaz přiřazení 'PROMĚNNÁ=hodnota' má tu vlastnost, že má navíc platný oddělovač mezeru. Nejedná se o plnohodnotný oddělovač jako středník nebo nový řádek, protože přiřazení na takovém řádku se provedou stejně až po ; nebo \n. Takže něco jako V=1 M=2 echo $V$M sice funguje, ale nic nevytiskne. U "funkce" (ono je to spíš makro) je situace jiná. Ta při vložení kódu na místo přidá hned řádný oddělovač, proměnné se tedy nastaví a echo uvnitř funkce má už k dispozici nastavené proměnné ze stejného řádku. Z toho pohledu je logické chování dashe. Fíčura bashe toho využívá jako levého argumentu a snaží se chování připodobnit chování externího programu. -- Je to prostě taková hezká bashovina, co nestojí za hádku.

[Michal Kubeček]

Mně tedy chování dashe vůbec logické nepřipadá, protože hlavně vůbec není konzistentní. V okamžiku, kdy se konstrukce

  var=val cmd

chová diametrálně odlišně podle toho, jestli je cmd (externí) příkaz nebo funkce, stačí nahradit příkaz vlastním wrapperem (což je běžný postup) a skript se rozbije. Tohle prostě autoři dashe nedomysleli.

"funkce" (ono je to spíš makro)

Shellová funkce se ani zdaleka nechová jako makro.

[RM]

není konzistentní

Ono být ani konzistentní nemůže, když externí programy a built-in, které je překrývají, podporují levý argument a jiné built-in programy argument na levé straně nepodporují. (S tím echem jsem neuvedl moc dobrý příklad, to se zrovna překrývá s externím programem echo a u těch co levou stranou nepodporují hlásí shell chybu, kromě samotného přiřazení.)

nahradit příkaz vlastním wrapperem

Já nevim, jestli bych chtěl měnit změnou parametru prostředí před funkcí chování všech programů použitých uvnitř wrapperu. Zejména, když u některých ani nevím, co by to mohlo způsobit. Navíc hojné používání levého argumentu mi moc čitelné nepřijde; raději, když to funkce nepodporují.

Shellová funkce se ani zdaleka nechová jako makro

Vycházím z toho, že je to skoro stejné jako makro TeXu (až na expanze): žádné lexikální prostory - jen localizace proměnné uvnitř bloku; výstupem je tisk na stdout (pokud nepoužívám return pro status do stderr); takže pokud bych ve funkci nahradil poziční parametry hodnotou, tak to celé mohu napsat jen do bloku spuštěném v externím procesu třeba jako (makro.....) | cat nebo u přiřazení se blok vloží do substituce m=$(makro....). Mně to tedy vždycky přišlo tak trochu na pomezí makro/funkce, ale představa makra mi přijde u řešení některých problémů výhodnější. Nevím sice jak to je uvnitř shellu naprogramované, ale pochybuji, že "funkce" skutečně proběhne mimo program a pak vrací jen výsledek; nehledě na to, že to ani návratovou hodnotu nemá. Kdyby to tak bylo, pak by se to zřejmě nenazýváno makro-procesorem. Ale zkuste mne přesvědčit o opaku, rád si v tom případně udělám jasno.

[Michal Kubeček]

podporují levý argument a jiné built-in programy argument na levé straně nepodporují

Tak tady se nechytám. Co myslíte termínem levý argument?

Já nevim, jestli bych chtěl měnit změnou parametru prostředí před funkcí chování všech programů použitých uvnitř wrapperu.

Já samozřejmě ano. Když to bude samostatný script, také tu proměnnou dostane do svého environmentu. A funkce je v podstatě takový "embedded script", tedy až na to, že defaultně sdílí environment se zbytkem scriptu.

nehledě na to, že to ani návratovou hodnotu nemá

Opravdu? Tak zkuste spustit tohle

#!/bin/bash

function starts_with_a()
{
    if [ "${1#a}" = "$1" ]; then
        return 1
    else
        return 0
    fi
}

starts_with_a abc && echo "abc YES"
starts_with_a abc || echo "abc NO"
starts_with_a def && echo "def YES"
starts_with_a def || echo "def NO"

a vysvětlit, proč to vypíše

abc YES
def NO

[RM]

Co myslíte termínem levý argument?

Samozřejmě to, co je uvedeno na levé straně příkazu/programu. Nejčastěji nastavení hodnot prostředí LC_TYPE aj., ale v podstatě tam může být cokoliv, co program podporuje, třeba nastavení vlastních proměnných při spuštění shellu; asi je vám jasné, že se nejedná o příkaz shellu pro přiřazení do proměnné, ač to tak opticky vypadá. Dokonce -- což se tak často neví -- tam může být nastavení file-deskriptoru (přesměrování), který se ze zvyku a pro lepší čitelnost dává na pravou stranu až na konec.

funkce je v podstatě takový "embedded script"

Jinými slovy: vložený blok makra s expandovanými pozičními parametry, případně vyměněnou proměnnou, která by byla v makru označena jako local

vysvětlit, proč to vypíše...

Však jsem psal, že return vrací (spíš posílá) status do stderr. Já psal ale o návratové hodnotě, která jde dál ke zpracování -- nějaký řetězec. V shellu je to jen o přesměrování stdout. Samozřejmě s přivřením oka to můžeme také nazývat návratovou hodnotou, pokud nám nebude vadit, že ji vrací příkaz jako echo nebo printf.

[Michal Kubeček]

Samozřejmě to, co je uvedeno na levé straně příkazu/programu.

Uff… Tak říkat tomu argument by mne ani ve snu nenapadlo. To přece není žádný argument, ta konstrukce prostě znamená "spusť tenhle příkaz s těmito hodnotami těchto proměnných", nic víc a nic méně. S argumenty to nemá nic společného, příkaz nemá žádnou možnost, jak poznat, jestli jste použil tu jednořádkovou konstrukci nebo jste tu proměnnou prostě a jednoduše nastavil klasickým způsobem (jako exportovanou).

Dokonce -- což se tak často neví -- tam může být nastavení file-deskriptoru (přesměrování), který se ze zvyku a pro lepší čitelnost dává na pravou stranu až na konec.

Snad nechcete přesměrování také říkat argument? Zkuste se zamyslet např. nad tím, proč

  wc file
  wc <file

mají rozdílný výstup (hlavně proč první vypíše jméno souboru a druhý ne).

Však jsem psal, že return vrací (spíš posílá) status do stderr. Já psal ale o návratové hodnotě, která jde dál ke zpracování -- nějaký řetězec. V shellu je to jen o přesměrování stdout. Samozřejmě s přivřením oka to můžeme také nazývat návratovou hodnotou, pokud nám nebude vadit, že ji vrací příkaz jako echo nebo printf.

Je mi líto, ale v tomhle odstavci není pravda skoro nic. Návratová hodnota nemá se stderr nic společného a u funkce funguje v podstatě stejně jako u externího příkazu a stejně se i zpracovává. Návratová hodnota je číslo, žádný řetězec, jak u funkce, tak u externího příkazu. Výstup (standard output) a chybový výstup (standard error) jsou něco úplně jiného.

[RM]

Tak mohl jsem to nazvat pravou a levou stranou příkazu nebo tokeny před a za příkazem; přesměrování je samozřejmě věcí shellu a program s tím nemá nic společného. Já se na to dívám stále jako na výraz na řádku shellu, zkuste mi tedy prominout zjednodušení "pravý a levý argument". Přesnější dělení tu -- podle mne -- nebylo potřeba. Máte ale pravdu, že stderr se statusem nesouvisí, to jsem napsal špatně; sám se tomu teď divím. Jinak myslím, že vše ostatní platí.

[ehm]

DFTT. Psal to už Michal Kubeček v #3. Kdybyste si to s Odinem přečetli, mohlo mu zbýt o několik minut víc času na jeho dva psy a tobě na abstraktní univerzálně konfigurovatelný multi-threading enterprise edition rozblikávač LED.

[limit_false]

U bashe jsem nasel tohle divne chovani:

ls -d [A-Z]*

V bashi vypise i soubory nezacinajici velkym pismenem. Pod zsh to ma ocekavany vysledek. Nevim zda je to zpusobeno locale nebo cim, ale ani nastaveni locale na LC_ALL=C to chovani nezmeni.

[Michal Kubeček]

Works for me:

mike@unicorn:/tmp/a> ls -d [A-Z]*
A  b  B  c  C  d  D
mike@unicorn:/tmp/a> LC_ALL=C
mike@unicorn:/tmp/a> ls -d [A-Z]*
A  B  C  D

[Lyco]

Jistě že to závisí na locale. Ovšem výsledek záleží na locale shellu (jaké parametry se předají a v jakém pořadí) a na locale ls (jak se jména souborů seřadí a jak se interpretují):

[lyco@hubb test]$ LC_ALL=cs_CZ.utf8
[lyco@hubb test]$ ls *
a  A  á  Á  b  B  c  C  č  Č
[lyco@hubb test]$ ls [A-C]*
A  á  Á  b  B  c  C
[lyco@hubb test]$ ls [A-Z]*
A  á  Á  b  B  c  C  č  Č
[lyco@hubb test]$ LC_ALL=C
[lyco@hubb test]$ ls [A-C]*
A  B  C
[lyco@hubb test]$ 
[lyco@hubb test]$ LC_ALL=C ls [A-C]*
A  B  C
[lyco@hubb test]$ LC_ALL=cs_CZ.utf8
[lyco@hubb test]$ LC_ALL=C ls [A-C]*
 A   B   C   b   c  ''$'\303\201'  ''$'\303\241'