9.2. Bash (Bourne-Again Shell)
Red Hat Enterprise Linux 6 include la versione 4.1 di Bash come shell predefinita. Questa sezione descrive le problematiche relative alla compatibilità che questa versione introduce rispetto alle versioni precedenti.
- Bash-4.0 e versioni più recenti permette ora il passaggio non modificato dei concetti di sostituzione del processo attraverso l'espansione delle parentesi graffe, così ogni espansione dei contenuti deve essere specificata separatamente ed ogni sostituzione del processo dovrà essere inserita separatamente.
- Bash-4.0 e versioni più recenti permettono ora a SIGCHLD di interrompere wait builtin, come specificato da Posix, in modo tale che la SIGCHLD trap non venga sempre invocata una sola volta per ogni figlio in uscita se state usando `wait' per l'attesa di tutti i figli.
- Poichè Bash-4.0 e versioni più recenti seguono le regole di Posix per la ricerca del delimitatore di chiusura di un $() command substitution, esso non si comporta come le precedenti versioni ma sarà in grado di raccogliere un numero maggiore di errori di sintassi e di analisi prima di generare una shell secondaria per analizzare il command substitution.
- Il codice di autocompletamento programmabile utilizza lo stesso set di caratteri delimitatori di readline quando separa la riga del comando in due parole al posto del set di metacaratteri della shell, per questo motivo readline e l'autocompletamento programmabile dovrebbero essere più continui.
- Quando read builtin scade esso tenterà di assegnare qualsiasi input letto alle variabili specificate, causando una impostazione delle variabili su di una stringa vuota se non è presente un input sufficiente. Le versioni precedenti scartavano i caratteri letti.
- Con Bash-4.0 e versioni più recenti, quando uno dei comandi in un pipeline veniva terminato da un SIGINT durante l'esecuzione di un comando dell'elenco, la shell si comportava come se avesse ricevuto il segnale di interruzione.
- Bash-4.0 e le versioni più recenti presenta un modo diverso di gestire l'opzione
set -e, con questa gestione la shell è in grado di uscire se un pipeline fallisce (e non solo quando l'ultimo comando presente nel pipeline fallito è un comando semplice). Tale comportamento non è specificato da Posix. Sono in atto degli sforzi per aggiornare questa porzione di standard; il comportamento di Bash-4.0 cercherà di raggiungere un consenso al momento della release. - Bash-4.0, e versioni più recenti, corregge un bug relativo alla modalità di Posix il quale causava una ricerca da parte di
. (source)builtin, della directory corrente tramite l'argomento del filename anche se"."non era presente in PATH. In questo caso Posix indica che la shell non dovrebbe andare alla ricerca nella variabile PWD. - Bash-4.1 utilizza il locale corrente durante il confronto delle stringhe usando gli operatori con il comando
[[. Ciò può essere ritornato al comportamento precedente impostando una della opzionicompatNNshopt.
Espressioni regolari
Oltre ai punti precedentemente elencati, l'aggiunta di apici all'argomento del pattern per l'espressione regolare corrispondente all'operatore =~ potrebbe causare l'arresto del regexp matching. Tale comportamento avviene su tutte le architetture. Nelle versioni di bash precedenti a 3.2, l'effetto dovuto all'uso di apici con l'argomento dell'espressione regolare insieme a =~ del comando [[ non era specificato. L'effetto pratico era che i doppi apici usati con l'argomento del pattern avevano bisogno di backslash per usare gli apici con i caratteri speciali del pattern i quali interferivano con la processazione del backslash eseguita dall'espansione della parola racchiusa in apici doppi inconsistente con il metodo attraverso il quale l'operatore == affrontava i caratteri racchiusi all'interno di apici.
Nella versione 3.2 di bash la shell è stata modificata in modo da usare internamente apici singoli e doppi per argomenti della stringa con l'operatore =~, il quale annulla il significato speciale dei caratteri importanti per la processazione dell'espressione regolare (`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$'), forzandoli a corrispondere ad ogni lettera. Tale comportamento è coerente con quello dell'operatore == durante la gestione delle sezioni all'interno di apici dell'argomento del proprio pattern.
Poichè il comportamento relativo alla gestione degli argomenti delle stringhe racchiuse in apici è stato modificato, si sono verificati ulteriori problemi tra i quali quello relativo agli spazi negli argomenti del pattern insieme al diverso trattamento presente tra bash 3.1 e bash 3.2. Entrambi i problemi possono essere risolti usando una variabile della shell in grado di contenere il pattern. Poichè non viene eseguita la suddivisione delle parole durante l'espansione delle variabili della shell in tutti gli operandi del comando [[, ciò fornisce la possibilità di usare gli apici per i pattern quando desiderato durante l'assegnazione della variabile ed espandere i valori in una stringa nella quale sono presenti gli spazi. Il primo problema può essere risolto usando i backslash o qualsiasi altro meccanismo per l'uso di apici per evitare gli spazi all'interno dei pattern.
Bash 4.0 introduce il concetto di un livello di compatibilità controllato da diverse opzioni per shopt builtin. Se l'opzione compat31 è stata abilitata, bash ritornerà al comportamento della versione 3.1 in relazione all'utilizzo degli apici nella parte destra dell'operatore =~.
