Sì,
nl='
'
case $var in
(*"$nl"*) echo yes;;
(*) echo no;;
esac
(per principio, mi piace citare tutte le espansioni variabili all'interno del case
modello a meno che non voglia che vengano trattate come modello, anche se qui non fa differenza in quanto $nl
non contiene caratteri jolly).
o
case $var in
(*'
'*) echo yes;;
(*) echo no;;
esac
Dovrebbero funzionare tutti e sono conformi a POSIX, e cosa vorrei usare per quello. Se rimuovi la (
s, funzionerebbe anche nella vecchia shell Bourne.
Per un altro modo di impostare la $nl
variabile:
eval "$(printf 'nl="\n"')"
Si noti che $'\n'
è previsto l'inclusione nella prossima versione dello standard POSIX . E 'già supportato da ksh93
, zsh
, bash
, mksh
, busybox e FreeBSD sh
almeno (a partire da febbraio 2018).
Per quanto riguarda se il test che hai è sufficiente, hai un test per entrambi i casi, quindi verificherei tutti i percorsi del codice.
Al momento c'è qualcosa che non è chiaramente specificato nelle specifiche POSIX: se *
corrisponde a una stringa che contiene sequenze di byte che non formano caratteri validi o se le variabili della shell possono contenere quelle stringhe.
In pratica, a parte le yash
cui variabili possono contenere solo caratteri e a parte i byte NUL (che non hanno shell ma zsh
possono memorizzare nelle loro variabili), *$nl*
dovrebbero corrispondere a qualsiasi stringa che contiene $nl
anche se contengono sequenze di byte che non formano valide personaggi (come $'\x80'
in UTF-8).
Alcune find
implementazioni, ad esempio, non riuscirebbero a combaciare con -name "*$nl*"
esse, quindi se testate una nuova shell e se intendete gestire cose che non sono garantite come testo (come i nomi di file), potreste voler aggiungere un caso di prova. Come con:
test=$(printf '\200\n\200')
in una locale UTF-8.