2010-12-12 13 views
34

Questo Bash frammento di opere come mi sarei aspettato:Perché "local" scopa il codice di ritorno di un comando?

$ fun1() { x=$(false); echo "exit code: $?"; } 
$ fun1 
exit code: 1 

Ma questo, utilizzando local, non lo fa:

$ fun2() { local x=$(false); echo "exit code: $?"; } 
$ fun2 
exit code: 0 

Qualcuno può spiegare perché fa local spazzare il codice di ritorno del comando ?

+1

Vedere https://lists.gnu.org/archive/html/bug-bash/2010-03/msg00007.html – tokland

risposta

41

Il motivo per cui il codice con local restituisce 0 è perché $? "Si espande allo stato di uscita della pipeline in primo piano eseguita più recentemente." Così $? sta tornando il successo di local

È possibile risolvere questo comportamento separando la dichiarazione di x dalla inizializzazione della x in questo modo:

$ fun() { local x; x=$(false); echo "exit code: $?"; }; fun 
exit code: 1 
+0

Di solito preferisco definire e utilizzare una variabile in una singola riga, ma sì questa è una soluzione accettabile. – tokland

+4

Per la cronaca, il problema è discusso nel wiki BashPitfalls: http://mywiki.wooledge.org/BashPitfalls#local_varname.3D.24.28command.29 – tokland

+0

Pensavo stavo impazzendo ... grazie! – peteroak

2

Il codice di ritorno del comando local oscura il codice di ritorno false

+1

Sì, lo capisco, ma essendo locale una parola chiave speciale mi aspetterei di non oscurarlo. Immagino fosse una falsa ipotesi. – tokland

+3

Non è una "parola chiave speciale", è una shell incorporata. Persino i builtin hanno valori di ritorno. –

+0

grazie @Ignacio, hai ragione, dovrò controllare i miei script per gli usi errati di "VAR locale = $ (comando) || restituire 1" – tokland

Problemi correlati