Dotaz: Kdy dávat proměnné do uozovek

[Martas]

Ahoj, nemůžu najít, kdy dávat a kdy nedávat ve scriptech bash/shell proměnné do uvozovek. poradí někdo? Děkuji

---

---

Odpovědi

[podlesh]

Rozhodně vždy, když se tam mohou vyskytnout whitespace (mezery apod). Ideálně vždy, pokud si nejsem opravdu 100% jistý že tam mezery fakt nejsou.

[Martas]

Díky a co třba tohle? Takto

source "$(dirname $0)/foo/bar"

nebo takto ?

source  $(dirname $0)/foo/bar

Díky

[Šangala]

source "$(dirname "$0")/foo/bar" ;)

OT: Takové source-ování nebude fungovat jak asi chceš při použití linek.

[Martas]

Tak že to má být bez uvozovek? Takto?

source $(dirname $0)/foo/bar

[Šangala]

Proč?, ne, má to být jak jsem napsal:

source "$(dirname "$0")/foo/bar"

Ale zjištění adresáře nebude vždy, to co si asi zamýšlíš.

[Šangala]

Mám pocit, že tě napínám, takže příklad:

Příprava:

mkdir kuk
echo -e "#\!/bin/bash\n\necho \"\$(dirname \"\$0\")/foo/bar\"\n" > kuk/do.bash
ln -s kuk/do.bash dolink
ln -s kuk kuklink
chmod +x kuk/do.bash

Test:

./kuk/do.bash
./dolink 
./kuklink/do.bash 

Otázka:
 Chceš to tak?

Úklid:

rm ./dolink
rm ./kuk/do.bash
rm ./kuklink
rmdir kuk

[Martas]

Tak to jsem ted zcela v prdli Můžeš ještě jednou co se snažíš říct - pro blba? Díky

[Šangala]

Výstup z těch ukázek:

 $ ./kuk/do.bash     -> ./kuk/foo/bar       - OK
 $ ./dolink          -> ./foo/bar           - ???
 $ ./kuklink/do.bash -> ./kuklink/foo/bar   - OK!

1. OK - standard
2. Pokud budeš source-ovat script, který je ve stejném adresáři, jako ten script co spoustíš, tak ho takto nenajde, bo ho hledá jinde.
3. Do vnořených adresářů OK, ale základní adresář scriptu není „kuk“ - jen ukázka chování.

„¡Studenti! pokud nechápe výklad je chyba přednášejícího, ne vaše …rozumíte tomu?“…

[Semo]

Vzdy. Okrem miest, kde velmi dobre vies, preco by tam byt nemali.

[Andrej]

Kromě případu, kdy chceš z proměnné s mezerami vytvořit pole, je vhodné mít uvozovky v podstatě všude. Možná se najde ještě pár dalších exotických situací, kde se uvozovky nehodí, ale moc jich nebude.

text='a b c d e'
tokens=(${text})              # Tohle je ten speciální případ.
other_tokens=("${tokens[@]}") # Kopírování pole má uvozovky.

Složené závorky jsou u proměnných, které nejsou pole, v podstatě dobrovolné, ale většinou je používám. Přijdou vhod třeba v případě, kdy člověk změní "${text} s mezerami" na "${text}bez_mezer", protože zatímco "$text s mezerami" funguje podle očekávání, "$textbez_mezer" se se značnou pravděpodobností rozexpanduje na velké kulové.

Následuje ještě jeden příklad s poli a s uvozovkami. Expanze ${words[@]} a ${words[*]} dělají mimo uvozovky totéž, ale v uvozovkách se chovají odlišně.

words=(' a  b ' ' c  d ')
for word in ${words[*]}; do echo "${word}" \| ${word}; done        # 4 řádky
for word in ${words[@]}; do echo "${word}" \| ${word}; done        # 4 řádky
for word in "${words[@]}"; do echo "${word}" \| ${word}; done        # 2 řádky
for word in "${words[*]}"; do echo "${word}" \| ${word}; done        # 1 řádek

Zajímavé je též pořadí expanze v shellu — na první pohled nemusí být zřejmé, že přidání uvozovek do následujícího příkladu vůbec nic nezmění.

quotes=('"' '"' '"');
for i in ${quotes[@]}; do echo $i; done

[potato]

Možná se najde ještě pár dalších exotických situací, kde se uvozovky nehodí

Exotických situací jako když máš v proměnné několik voleb programu?

Ano, používat uvozovky všude, kde není zapotřebí word splitting, neškodí. Škodlivý je ovšem názor, že chtěný word splitting je cosi exotického. Je to příznak velkolepého formálního programování v shellu (ve srovnání se skriptováním), při kterém se nevyužívají silné stránky shellu, zato se složitě matlají věci, které ve vhodnějším jazyce fungují mnohem lépe.

[Andrej]

Na druhé straně není nic horšího než matlání skriptů, které selžou při první neočekávané mezeře. Viděl jsem takových dost na to, abych byl skalním příznivcem uvozovek. Když chci mít v jedné proměnné víc optionů, je spousta důvodů pro použití pole, ve kterém se například option obsahující mezeru nerozdělí na dva. Pokud parsuju strukturovaná data, u kterých vím naprosto jistě, co je oddělovač a co ne, je to samozřejmě zcela jiná situace. Nejhorší je expandovat obyčejnou proměnnou obsahující parametry příkazové řádky, které mohou obsahovat jména souborů, která mohou obsahovat téměř libovolné bílé místo.