Citando entro $ (sostituzione comando) in Bash

Nel mio ambiente Bash uso variabili contenenti spazi e utilizzo queste variabili nella sostituzione dei comandi. Purtroppo non riesco a trovare la risposta su SE.

Qual è il modo corretto di citare le mie variabili? E come devo fare se questi sono nidificati?

DIRNAME=$(dirname "$FILE")

o cito al di fuori della sostituzione?

DIRNAME="$(dirname $FILE)"

o entrambi?

DIRNAME="$(dirname "$FILE")"

o uso i segni di spunta?

DIRNAME=`dirname "$FILE"`

Qual è il modo giusto per farlo? E come posso verificare facilmente se le virgolette sono impostate correttamente?

In ordine dal peggiore al migliore:

• DIRNAME="$(dirname $FILE)" non farà quello che vuoi se $FILEcontiene spazi bianchi o personaggi sconvolgenti \[?*.
• DIRNAME=`dirname "$FILE"`è tecnicamente corretto, ma i backtick non sono raccomandati per l'espansione dei comandi a causa della complessità aggiuntiva durante l'annidamento.
• DIRNAME=$(dirname "$FILE")è corretto, ma solo perché si tratta di un compito . Se si utilizza la sostituzione del comando in qualsiasi altro contesto, come export DIRNAME=$(dirname "$FILE")o du $(dirname "$FILE"), la mancanza di virgolette causerà problemi se il risultato dell'espansione contiene spazi bianchi o caratteri globbing.
• DIRNAME="$(dirname "$FILE")"è il modo raccomandato. È possibile sostituire DIRNAME=con un comando e uno spazio senza modificare nient'altro e dirnamericeve la stringa corretta.

Per migliorare ulteriormente:

• DIRNAME="$(dirname -- "$FILE")"funziona se $FILEinizia con un trattino.
• DIRNAME="$(dirname -- "$FILE"; printf x)" && DIRNAME="${DIRNAME%?x}"funziona anche se $FILEtermina con una nuova riga, poiché $()taglia le nuove righe alla fine dell'output e dirnamegenera una nuova riga dopo il risultato. Sheesh dirname, perché devi essere diverso?

Puoi annidare le espansioni di comando quanto vuoi. Con $()te crei sempre un nuovo contesto di quotazione, così puoi fare cose come questa:

foo "$(bar "$(baz "$(ban "bla")")")"

Tu non vuoi provare quello con apici inversi.

Puoi sempre mostrare gli effetti della quotazione delle variabili con printf.

Suddivisione delle parole eseguita su var1:

$ var1="hello     world"
$ printf '[%s]\n' $var1
[hello]
[world]

var1 citato, quindi nessuna suddivisione delle parole:

$ printf '[%s]\n' "$var1"
[hello     world]

Scissione di parole var1all'interno $(), equivalente a echo "hello" "world":

$ var2=$(echo $var1)
$ printf '[%s]\n' "$var2"
[hello world]

Nessuna suddivisione in parole var1, nessun problema con la mancata citazione di $():

$ var2=$(echo "$var1")
$ printf '[%s]\n' "$var2"
[hello     world]

Ripartizione della parola var1:

$ var2="$(echo $var1)"
$ printf '[%s]\n' "$var2"
[hello world]

Citando entrambi, il modo più semplice per essere sicuri.

$ var2="$(echo "$var1")"
$ printf '[%s]\n' "$var2"
[hello     world]

Problema globale

Non quotare una variabile può anche portare all'espansione globale dei suoi contenuti:

$ mkdir test; cd test; touch file1 file2
$ var="*"
$ printf '[%s]\n' $var
[file1]
[file2]
$ printf '[%s]\n' "$var"
[*]

Si noti che ciò si verifica solo dopo l'espansione della variabile. Non è necessario citare un glob durante l'assegnazione:

$ var=*
$ printf '[%s]\n' $var
[file1]
[file2]
$ printf '[%s]\n' "$var"
[*]

Utilizzare set -fper disabilitare questo comportamento:

$ set -f
$ var=*
$ printf '[%s]\n' $var
[*]

E set +fper riattivarlo:

$ set +f
$ printf '[%s]\n' $var
[file1]
[file2]

Aggiunta alla risposta accettata:

Anche se in genere sono d'accordo con la risposta di @ l0b0 qui, sospetto che il posizionamento di backtick nudi nell'elenco "peggiore in assoluto " sia almeno in parte il risultato del presupposto che $(...)è disponibile ovunque. Mi rendo conto che la domanda specifica Bash, ma ci sono molte volte in cui Bash scopre che significa /bin/sh, che potrebbe non essere sempre la shell Bourne Again completa.

In particolare, la semplice shell Bourne non saprà cosa farsene $(...), quindi gli script che dichiarano di essere compatibili con essa (ad es. Tramite una #!/bin/shlinea shebang) probabilmente si comporteranno male se sono effettivamente gestiti dal "reale" /bin/sh- questo è di interesse speciale quando, per esempio, producendo script di inizializzazione o impacchettando pre e post-script, e può atterrare in un posto sorprendente durante l'installazione di un sistema di base.

Se qualcuno di questi sembra qualcosa che stai pianificando di fare con questa variabile, l'annidamento è probabilmente meno preoccupante che avere lo script in realtà, prevedibilmente eseguito. Quando è un caso abbastanza semplice e la portabilità è una preoccupazione, anche se mi aspetto che lo script di solito venga eseguito su sistemi in cui si /bin/shtrova Bash, spesso tendo ad usare i backtick per questo motivo, con assegnazioni multiple anziché nidificazione.

Detto questo, l'ubiquità delle shell che implementano $(...)(Bash, Dash, et al.), Ci lascia in un buon posto per rimanere con la sintassi POSIX più carina, più facile da annidare e più recentemente preferita nella maggior parte dei casi, per tutti i motivi menzionati da @ l0b0.

A parte: questo è apparso occasionalmente anche su StackOverflow -

• Sostituzione del comando: simboli o backtick o simbolo del dollaro racchiusi? [duplicato] (febbraio 2012)
• Shell Programming: Qual è la differenza tra $ (comando) e `comando` (gennaio 2011)