bash: if con condizione multipla

[tom]

vorrei creare in uno script una condizione multipla con "if ... then" di questo tipo:

Codice: Seleziona tutto

ARGOMENTO=$1
if [ $ARGOMENTO = "A" oppure "B"] ; then
  echo SI
else
  echo NO
fi

praticamente otterrei il mio risultato utilizzando case, così:

Codice: Seleziona tutto

ARGOMENTO=$1
case $ARGOMENTO in
  A|B) echo SI ;;
    *) echo NO ;;
esac

però ho bisogno di usare if-then, come faccio?

[zoros]

forse così ... ma attenzione agli spazi

Codice: Seleziona tutto

ARGOMENTO=$1
if [  "a$ARGOMENTO" == "aA" ] || [  "a$ARGOMENTO" == "aB" ] ; then
  echo SI
else
  echo NO
fi

[tom]

funge, ma... non c'è un modo più "elegante"?

[zoros]

funge, ma... non c'è un modo più "elegante"?

probabilmente sì ... comunque le varie shell sono piene di bachi ... per esempio la "a" davanti alla variabile serve ad evitare che sia rilevato un errore nel caso di variabile nulla

[targzeta]

Vedi test(1), la bash ha altri suoi test, però questi sono quelli standard. In particolare potresti fare:

Codice: Seleziona tutto

[ ! -z $ARGOMENTO ] && [ $ARGOMENTO = 'A' -o $ARGOMENTO = 'B' ]

Nota che puoi fare dei test su stringhe, numeri e file.

Emanuele

P.S. Se un argomento non dev'essere espanso, non quotarlo con i doppi apici, usa l'apice singolo.

[targzeta]

probabilmente sì ... comunque le varie shell sono piene di bachi ... per esempio la "a" davanti alla variabile serve ad evitare che sia rilevato un errore nel caso di variabile nulla

Non so a quali bachi ti riferisci, però quello che citi non è un bug, ma il comportamento corretto. Se tu esegui un controllo del tipo:

Codice: Seleziona tutto

[ $a -eq 1 ]

ma poi la variabile 'a' non è settata, l'espansione del controllo (il test che viene veramente effettuato) diventa:

Codice: Seleziona tutto

[ -eq 1]

e quindi il comando 'test' lamenta l'assenza di un argomento. O meglio, ti dice che hai effettuato un test unario (gli hai dato un solo argomento) ma che gli hai passato un operatore binario (il test '-eq'). Lui ovviamente ti dice che, avendogli passato un unico argomento, si aspettava un operatore unario.

Spero di essermi spiegato bene ,
Emanuele

P.S. E comunque l'eventuale 'lamentela' non viene neanche dalla shell, ma dal comando 'test'. Quindi hai sbagliato proprio esempio

[Mario Vanoni]

P.S. E comunque l'eventuale 'lamentela' non viene neanche dalla shell, ma dal comando 'test'. Quindi hai sbagliato proprio esempio :lol:

test e [ sono bash built-in, il comando si trova in
/bin/test
/usr/bin/test
/usr/X11R6/bin/test

[targzeta]

Hai ragione! Non ho controllato, ma credo che quello builtin dovrebbe comportarsi come quello in /bin/, ma a rigore a questo punto il manuale da controllare è quello della bash e non di test.

Emanuele

[zoros]

probabilmente sì ... comunque le varie shell sono piene di bachi ... per esempio la "a" davanti alla variabile serve ad evitare che sia rilevato un errore nel caso di variabile nulla

Non so a quali bachi ti riferisci, però quello che citi non è un bug, ma il comportamento corretto. ...

è scritto anche in alcuni libri di riferimento GNU/Linux che le shell sono piene di bug ... ma, si sa, i libri sono pieni di bug ... comunque l'interpretazione del testo nelle varie shell che abbiamo a disposizione fa veramente pena, basta uno spazio dimenticato e compaiono errori assurdi ... la questione di cui parlo sopra sarà anche nornale ... ma non puoi dire che è "normale" ...

[targzeta]

Non volevo dire che le shell non hanno bachi, mi limitavo solo all'esempio riportato, visto che non è un baco .

Comunque:

... la questione di cui parlo sopra sarà anche nornale ... ma non puoi dire che è "normale" ...

ti meriti una vecchia citazione:

I computer non fanno ciò che vuoi, ma ciò che gli dici di fare!

Emanuele

[zoros]

Non volevo dire che le shell non hanno bachi, mi limitavo solo all'esempio riportato, visto che non è un baco .

Comunque:

... la questione di cui parlo sopra sarà anche nornale ... ma non puoi dire che è "normale" ...

ti meriti una vecchia citazione:

I computer non fanno ciò che vuoi, ma ciò che gli dici di fare!

Emanuele

il problema non sono i computer, ma gli umani ... dopo aver faticato a capire le mille "trappole" della bash, ci sembra giusto così ... quindi andiamo avanti così ... ma non è proprio giusto così ...

[masalapianta]

comunque l'interpretazione del testo nelle varie shell che abbiamo a disposizione fa veramente pena, basta uno spazio dimenticato e compaiono errori assurdi ... la questione di cui parlo sopra sarà anche nornale ... ma non puoi dire che è "normale" ...

pensa che nei bonifici basta uno zero in più ed invece di pagare cento euri ne pago mille, mica è normale questa cosa, le macchine dovrebbero leggerci nel pensiero e fare quello che vorremmo fare e non quello che gli diciamo di fare

[Mario Vanoni]

Hai ragione! Non ho controllato, ma credo che quello builtin dovrebbe comportarsi come quello in /bin/, ma a rigore a questo punto il manuale da controllare è quello della bash e non di test.

Per curiosita` mia ho confrontato i due manuali, test(1) non capisce le opzioni/operatori di bash(1):
-N
-o
==
<
>

Poi da non dimenticare
/bin/[
/usr/bin/[
/usr/X11R6/bin/[
dai tempi di UNIX, altra variante di test.

[Vito]

pensa che nei bonifici basta uno zero in più ed invece di pagare cento euri ne pago mille, mica è normale questa cosa, le macchine dovrebbero leggerci nel pensiero e fare quello che vorremmo fare e non quello che gli diciamo di fare

Questo tipo di risposte non sono apprezzate,
soprattutto perchè inutili ai fini della risoluzione del problema.
Evitiamole.

[masalapianta]

pensa che nei bonifici basta uno zero in più ed invece di pagare cento euri ne pago mille, mica è normale questa cosa, le macchine dovrebbero leggerci nel pensiero e fare quello che vorremmo fare e non quello che gli diciamo di fare

Questo tipo di risposte non sono apprezzate,
soprattutto perchè inutili ai fini della risoluzione del problema.
Evitiamole.

se ci fosse un problema avresti ragione, ma visto che la risposta corretta al problema posto da chi ha aperto il thread era gia stata fornita, non vedo il problema; di più, esaurito quel problema, chi ha aperto il thread ne ha posto un altro ("è un bug o meno che la bash si comporti in tal maniera?"), quindi la mia risposta era volta a far capire che non si può considerare un bug il fatto che un programma faccia quel che gli dici di fare e non quello che vorresti che facesse (poi ovviamente ci può sempre essere qualcuno che, quando c'era l'offerta sull'ironia, ha preferito dirigersi al banco dei salumi, ma di questo onestamente non posso farmene carico io)