Bash tips: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
rimozione bash scripting per scorpamento
(→‎Bash Scripting: caratteri di escape e correzioni)
(rimozione bash scripting per scorpamento)
Riga 152: Riga 152:
> nome_del_file
> nome_del_file
</pre>
</pre>
==Bash Scripting==
In questa sezione verranno elencati alcuni brevi tip per lo scripting Bash. Questa non vuole essere assolutamente una guida completa, ma piuttosto un elenco di costrutti per lo scripting bash particolarmente eleganti, curiosi e/o poco noti.
===Variabili speciali===
; <code>$?</code> : contiene il valore di uscita dell'ultimo comando o funzione. Il comando ha successo se restituisce zero, qualsiasi altro valore indica invece un codice di errore;
''Esempio:''
$ cd ..
$ echo $?
0
$ cd ...
$ echo $?
1
; <code>$@</code> : contiene la lista dei parametri passati allo script corrente o a una funzione. Ogni parametro viene opportunamente quotato, se questa variabile è quotata, e questo ne permette l'utilizzo nei '''cicli for''' per processare (ad esempio) una lista di nomi di file che possono contenere anche spazi. L'uso di questa variabile è quindi in genere preferito rispetto a <code>'''$*'''</code> che ha la stessa funzione ma, se quotata, non quota i vari parametri ma l'intera stringa;
''Esempio:''
<pre>
for file in "$@"; do
    # Fare quello che si vuole con $file
    echo "$file"
    # ...
done
</pre>
; <code>$$</code> : PID del processo corrente;
; <code>$!</code> : PID dell'ultimo job in background.
=== Altre variabili ===
In Bash ogni variabile (di default) è trattata come una stringa, e come nella maggior parte dei linguaggi di programmazione un nome di variabile ammette soltanto caratteri alfabetici (maiuscoli e minuscoli), l'underscore "_" e numeri (questi ultimi purché non in prima posizione).
Il contenuto di una variabile si accede con <code>${nome}</code> oppure con la forma abbreviata <code>$nome</code>.
Si noti che la forma abbreviata considera il nome della variabile come composto da tutti i caratteri validi incontrati. Per esempio <code>"$nome$cognome"</code> è equivalente a <code>"${nome}${cognome}"</code>, ma <code>"$nome_$cognome"</code> non lo è a <code>"${nome}_${cognome}"</code> perché <code>nome_</code> (con underscore finale) sarebbe un nome di variabile valido. In caso di concatenazione di variabili è preferibile accedere alle variabili con le graffe, o in alternativa (meno elegante) delimitarle dalle virgolette; infatti <code>"$nome"_"$cognome"</code> corrisponde a <code>"${nome}_${cognome}"</code>.
Nelle assegnazioni non si deve usare il <code>'''$'''</code>, salvo che per accedere al contenuto di altre variabili:
<pre> variable="stringa"                        # assegno un valore (una stringa)
variabile="stringa con spazi"            # assegno una stringa con spazi
variabile=$altra_variabile                # assegno una variabile
variabile=${altra_variabile}              # equivalente a sopra
variabile="${var1} testo ${var2}_${var3}" # assegno una concatenazione di variabili e stringhe
</pre>
È bene notare che in tutti gli altri casi, quando si accede al contenuto di una variabile senza quotarla, questa può essere trasformata in più di una singola stringa, in base agli spazi contenuti, e perfino in "niente" se è vuota ("niente" proprio come se non presente nel codice). Se si vuole sempre considerare il contenuto della variabile come una singola stringa, è necessario accederla quotata (tra virgolette), ossia con <code>"$variabile"</code> oppure <code>"${variabile}"</code>.
Questo fatto è di particolare importanza, e una comune sorgente di errori, quando si utilizza la variabile in una condizione (<code>[ ... ]</code>, <code>test ...</code>, ecc...), perché la variabile potrebbe essere sostituita da più di una stringa o perfino da nessuna; e anche quando la si passa a un comando, in particolare se agisce su un file indicato dalla variabile, che potrebbe venir trattato come una lista di file se il nome contiene spazi (cosa molto comune per i file degli utenti). <br/>
Esempio di codice che crea un backup di un file indicato da una variabile, se il suo nome non termina già con estensione .bak. Si notino le virgolette attorno alla variabili, omesse solo nelle assegnazioni (senza spazi), per garantire che ogni variabile venga espansa in uno e un solo argomento:
<pre> if [ "$file" = "${file%.bak}" ]; then
    oldfile=$file
    file=${file}.bak
    cp -- "$oldfile" "$file"
fi
</pre>
D'altra parte accedere una variabile senza quotarla permette di assegnare tutte le opzioni da passare a un comando, se sono stringhe senza spazi, alla variabile per poi accederle in una volta sola:
<pre>ARGUMENTS="" # nell'intestazione del file, solo opzioni senza spazi
...
comando $ARGUMENTS # la variabile, non quotata, può essere vuota (come non scritta) o essere espansa in uno o più argomenti
</pre>
Si noti invece che usando <code>"$ARGUMENT"</code> (quotata) per una variabile contenente la stringa vuota, il comando leggerebbe lo stesso un argomento e potrebbe fallire.
=== Manipolazione delle stringhe ===
Nelle shell *nix, storicamente, la manipolazione delle stringhe viene fatto attraverso programmi esterni alla shell come sed, awk e perl. Questi programmi vengono ancora usati quando si vuole mantenere la compatibilità con la shell <code>'''sh'''</code> (''POSIX''), tuttavia imparare anche il solo sed (il più semplice dei tre) non è cosa immediata.
Se si usa Bash non è necessario usare nessun programma esterno, ma basta imparare i tre operatori fondamentali ed alcuni concetti di base, per poter fare tutte le manipolazioni più comuni direttamente sulle variabili.
Si assegna una stringa a una variabile e accedendola tramite la forma con le graffe, si può ricorrere a un modificatore che manipola la stringa (senza modificare il contenuto della variabile), ad esempio:
VAR="stringa-di-esempio"
echo ${VAR#stringa-}
ritorna il contenuto della variable VAR senza il prefisso "stringa-". VAR non viene modificata, salvo una nuova assegnazione:
VAR=${VAR#stringa-}
ora il prefisso "stringa-" è stato eliminato anche dalla variabile VAR.
I modificatori sono molti, ma possono essere facilmente ricordati se si imparano i tre fondamentali:
; <code>#</code> : sottrae dall'inizio della stringa ''(minimale)''
; <code>%</code> : sottrae dalla fine della stringa ''(minimale)''
; <code>/</code> : sostituisce una sottostringa con un'altra ''(solo la prima volta che viene incontrata)''
Questi operatori sono minimali, questo vuol dire che se si usano le espressioni regolari per indicare la sottostringa (da eliminare o sostituire) verrà individuata in caso di ambiguità la sottostringa più piccola (o solo la prima nel caso della sostituzione).
Per ottenere gli operatori massimali basta raddoppiare il simbolo:
; <code>##</code> : sottrae dall'inizio della stringa ''(massimale)''
; <code>%%</code> : sottrae dalla fine della stringa ''(massimale)''
; <code>//</code> : sostituisce una sottostringa con un'altra ''(tutte le volte che viene incontrata)''
Gli operatori massimali cercano di individuare la sottostringa più grande che corrisponde all'espressione regolare (nel caso del modificatore '''//''' tutte le sottostringhe vengono sostituite). Gli operatori di questo tipo vengono comunemente chiamati anche ''greedy (ingordi)''.
Per una spiegazione dettagliata di tutti i modificatori e anche di altri modi di manipolare le stringhe in Bash (ad esempio <code>expr</code>) vedere:
* [http://www.tldp.org/LDP/abs/html/string-manipulation.html Advanced Bash-Scripting Guide: Manipulating Strings]
==== Esempi: manipolazione delle stringhe ====
<pre>VAR="questa.sarebbe.una.stringa.di.esempio"
 
                      # Risultato:
 
  echo ${VAR#*.}      # --> sarebbe.una.stringa.di.esempio
  echo ${VAR##*.}    # --> esempio
 
  echo ${VAR%.*}      # --> questa.sarebbe.una.stringa.di
  echo ${VAR%%.*}    # --> questa
 
  echo ${VAR/st/ST}  # --> queSTa.sarebbe.una.stringa.di.esempio
  echo ${VAR//st/ST}  # --> queSTa.sarebbe.una.STringa.di.esempio</pre>
===Caratteri di escape===
Alcuni caratteri hanno un valore speciale per la shell, per consentirne le espansioni (di variabile, parametro, comando, percorso, ecc...). Di conseguenza se si intende scrivere un carattere speciale senza espanderlo, è necessario comunicarlo alla shell facendolo precedere da un carattere di escape '<code>\</code>' oppure racchiudendolo tra apici o virgolette (a seconda dell'espansione da disattivare).
Questa sezione non è esaustiva, ma consiglia qualche semplice accorgimento:
* racchiudere tra apici (apostrofi) una stringa riduce a uno soltanto i caratteri speciali, ossia lo stesso apice, rappresentando la stringa per il suo solo valore letterale e impedendo tutte le espansioni. Lo svantaggio è che non esiste un carattere di escape, e che quindi un apice contenuto nella stringa non può essere racchiuso tra apici, rendendone più complicato l'escape. Per esempio:
:<pre>echo '$PATH "" \ `ls ..` \$HOME ~ * .[a-z]*'  # stampa la stringa tra apici, così com'è scritta</pre>
:<pre>echo 'L'\''albero di... ' # l'accento non deve essere racchiuso tra apici, e va preceduto da \</pre>
* racchiudere tra virgolette (ossia quotare) ogni stringa è in genere raccomandabile e la scelta consigliata, così da ridurre drasticamente il numero di caratteri speciali, permettendo l'uso delle variabili. I soli caratteri speciali sono <code>$</code>, <code>`</code> (ma non l'apice), <code>"</code> e <code>\</code> devono essere preceduti dal carattere di escape <code>\</code>. Le espansioni di percorso e tilda (*, ?, [...], ~, ... ) non sono possibili; mentre lo sono quelle di variabile e parametro (attraverso un <code>$</code> senza <code>\</code>), e quelle di comando (attraverso un <code>`</code> o un <code>$(</code> senza <code>\</code>). Riprendendo l'esempio:
:<pre>echo "$PATH \"\" \\ `ls ..` \$HOME ~ * .[a-z]*" # espande PATH e il comando ls, ma non HOME. Si noti l'uso dei \.</pre>
* non racchiudere tra virgolette e apici serve a permettere le espansioni di percorso e tilda. È sempre consigliabile racchiudere tutto il resto tra virgolette. I più comuni sono (si ricordi per le espansioni che su ambienti UNIX e Unix-like per file si intende sia un file regolare, sia una directory, un link, una pipe, un socket, un device, ecc...):
** <code>~</code> espande alla home (equivalente alla variabile $HOME, che però può essere quotata);
*** <code>~utente</code> espande alla home di un dato utente, ma la stringa utente non può essere quotata né essere una variabile da espandere;
** <code>?</code> pattern per un singolo carattere di un file;
*** <code>nomefile.???</code> combacia con tutti i file con nome "nomefile" e terminanti con tre caratteri qualsiasi per estensione;
** <code>*</code> pattern per tutti i possibili caratteri di un file (di default tranne quelli inizianti con .):
*** <code>*</code> da solo espande a tutti i file non nascosti nella directory corrente. È sempre buona norma far precedere l'asterisco da un ./, che indica la cartella corrente, se è il primo carattere del pattern, per impedire espansioni di file inizianti con "-", che potrebbero essere visti come opzioni da alcuni comandi;
*** <code>./*</code> equivalente a <code>*</code> ma più sicuro; di seguito si aggiunge il prefisso della directory corrente a tutte le espansioni inizianti con <code>*</code>;
*** <code>./*.txt</code> espande a tutti i file con estensione .txt;
*** <code>./*/</code> espande a tutte le directory non nascoste;
*** <code>prefisso*suffisso</code>espande a tutti i file con un dato prefisso e suffisso;
*** <code>./*."${estensione}"</code> espande dopo aver espanso la variabile (contrariamente a ~), che può anche essere quotata.
È importante tenere presente per le espansioni di percorso che, se nessun file combacia con un dato pattern, allora l'espansione *non* viene effettuata e i caratteri mantengono il loro valore originale. Per di più <code>*</code> e <code>?</code> sono caratteri validi per un nome di file. L'esistenza di file ottenuti da tali espansioni va pertanto sempre controllata, per esempio con <code>[ -e "$file" ]</code>:
<pre>for file in ./*; do
  if [ -e "$file" ]; then
      ...
  fi
done</pre>
===Concatenazione e redirezione===
; <code>&&</code> : operatore logico AND, il secondo comando verrà eseguito solo se il primo avrà esito positivo
; <code>;</code> : separatore di comandi, il secondo comando verrà eseguito in ogni caso (in uno script è equivalente a un "a capo" e questa è la concatenazione di default)
$ cd ... && echo done
$ cd ... ; echo done
Nel caso specifico di un'applicazione che resta in esecuzione il secondo comando non verrà eseguito finché il
primo non sarà terminato, in questo caso si usa <code>'''&'''</code> e saranno eseguiti entrambi in quanto il primo comando viene mandato in background; prendiamo xterm come esempio:
$ xterm && xterm -rv
$ xterm ; xterm -rv
$ xterm & xterm -rv
; <code>|</code> : pipe, passa l'output del comando che la precede come input del comando che la segue
$ ls -A1 | less
; <code>||</code> : operatore logico OR, restituisce esito positivo se almeno una delle condizioni di verifica valutate è vera
<pre>
$ if [ -f ~/.bashrc ] || [ -d ~/.config ]; then echo 'w00t!'; else echo 'no such file or directory'; fi
$ if [ -f ~/.bashrc ] || [ -d ~/.configs ]; then echo 'w00t!'; else echo 'no such file or directory'; fi
$ if [ -f ~/.bash ] || [ -d ~/.configs ]; then echo 'w00t!'; else echo 'no such file or directory'; fi
</pre>
* [http://www.tldp.org/LDP/abs/html/special-chars.html Advanced Bash-Scripting Guide: Special Characters]
Dirige output di comando su file:
$ man xterm > xterm.txt
Dirige output di errore su file:
$ xterm 2> xterm-errors.log
Entrambi su file diversi:
$ xterm > xterm_out.log 2> xterm_err.log
Entrambi sullo stesso file:
$ xterm &> xterm.log
Entrambi sullo stesso file, alternativa:
$ xterm > xterm.log 2>&1
Appende nuovo testo a quello già presente in un file:
$ man uxterm >> xterm.txt
Cancella contenuto di un file:
$ :> xterm.txt
===Alternativa a basename===
Quando in uno script ci si deve riferire al nome dello script stesso è usuale utilizzare il comando (esterno a bash) <code>'''basename'''</code>. Tuttavia, tramite i modificatori del paragrafo precedente, Bash stessa è in grado di fornire questa funzionalità. Basta usare l'espressione <code>${0##*/}</code>.
Esempio:
<pre>
usage () {
        echo "usage: ${0##*/} "
        exit 1
}
</pre>
=== Cambiare l'estensione ai file ===
Rinomina tutti i file <code>*.txt</code> della directory corrente in <code>*.log</code>:
$ for f in ./*.txt; do if [ -e "$f" ]; then mv -- "$f" "${f/%txt/log}"; fi; done
{{Suggerimento | L'opzione "--" dopo il comando esterno <code>mv</code> serve per comunicargli che le stringhe che seguono non sono opzioni, nemmeno se iniziassero con il carattere "-". È sempre buona norma utilizzarla come controllo aggiuntivo con comandi che accettano file come argomenti, il cui nome non è noto a priori, in particolare per comandi che manipolano i file come: <code>rm</code>, <code>cp</code>, <code>mv</code>, ecc... <br/>
L'opzione deve essere supportata dal comando esterno, non è trattata specialmente dalla shell.}}
=== Debug integrato ===
'''Bash''', proprio come '''dash''', ha delle opzioni che ne consentono il debug.
Per iniziare invocando uno script con <code>-n</code> è possibile effettuare un primitivo controllo di sintassi. Si noti che possibili comandi inesistenti non vengono controllati e nemmeno le espansioni (di variabili, percorsi, ecc...), ma può essere utile per verificare che tutti i blocchi sono stati chiusi correttamente prima di eseguire lo script:
$ bash -n script.sh
Dopo questo primo controllo ci sono altre opzioni utili, che possono essere impiegate anche congiuntamente nell'esecuzione dello script:
* <code>-x</code> invia sull'output per gli errori ogni comando prima di eseguirlo, preceduto da un prompt "+ ";
* <code>-v</code> invia sull'output per gli errori l'intero blocco di codice che è stato letto (solo la prima volta);
* <code>-u</code> interrompe l'esecuzione dello script se si accede a una variabile che non è mai stata assegnata, può essere utile in caso di errori di battitura;
* <code>-e</code> interrompe lo script in caso un comando ritorni un errore, se il suo valore di ritorno non è controllato da un <code>if</code>, <code>while</code>, <code>until</code> o dalla concatenazione di comandi con <code>||</code>.
Le opzioni possono essere anche accorpate:
$ bash -evx script.sh
L'opzione <code>-e</code> può essere utilizzata anche fuori dal debug, ma è consigliabile non fare affidamento sulla sua presenza nella prima riga dello script (<code>#! /bin/bash -e</code>), visto che può essere ignorata semplicemente invocando la shell con lo script come argomento oppure importando il contenuto dello script. I valori di ritorno di ogni comando che può fallire vanno invece controllati nel codice.


==Il file .bashrc==
==Il file .bashrc==
Riga 491: Riga 255:
Link ad altre risorse su '''GNU Bash''':
Link ad altre risorse su '''GNU Bash''':


* [http://www.gnu.org/software/bash/manual/bash.html Bash Referece Manual]: manuale ufficiale
* [http://www.gnu.org/software/bash/manual/bash.html Bash Referece Manual]: manuale ufficiale;
* [http://www.tldp.org/LDP/abs/html/ Advanced Bash-Scripting Guide]: la '''Bibbia''' dello bash scripting.
* [http://www.tldp.org/LDP/abs/html/ Advanced Bash-Scripting Guide]: la '''Bibbia''' dello bash scripting;
* [[Bash Scripting]]: consigli a cura di debianizzati sullo scripting con Bash.


{{Autori
{{Autori
Riga 498: Riga 263:
|Verificata_da=
|Verificata_da=
:[[Utente:S3v|S3v]]
:[[Utente:S3v|S3v]]
:[[Utente:HAL 9000|HAL 9000]] 14:34, 25 giu 2014 (CEST)
:[[Utente:HAL 9000|HAL 9000]] 19:59, 2 lug 2014 (CEST)
|Estesa_da=
|Estesa_da=
:[[Utente:S3v|S3v]]
:[[Utente:S3v|S3v]]
3 581

contributi

Menu di navigazione