Oui,
nl='
'
case $var in
(*"$nl"*) echo yes;;
(*) echo no;;
esac
(par principe, j'aime citer toutes les extensions de variables à l'intérieur du case
modèle, sauf si je veux qu'elles soient traitées comme un modèle, bien qu'ici cela ne fasse aucune différence car $nl
il ne contient pas de caractères génériques).
ou
case $var in
(*'
'*) echo yes;;
(*) echo no;;
esac
Si tous fonctionnent et sont conformes à POSIX, et ce que j'utiliserais pour cela. Si vous supprimez le (
s, cela fonctionnerait même dans l'ancien shell Bourne.
Pour une autre façon de définir la $nl
variable:
eval "$(printf 'nl="\n"')"
Notez qu'il $'\n'
est prévu de l'inclure dans la prochaine version de la norme POSIX . Il est déjà soutenu par ksh93
, zsh
, bash
, mksh
, busybox et FreeBSD sh
au moins (en Février 2018).
Quant à savoir si le test que vous avez est suffisant, vous avez un test pour les deux cas, ce serait donc tester tous les chemins de code.
Il y a actuellement quelque chose qui n'est pas clairement spécifié dans la spécification POSIX: si *
correspond à une chaîne qui contient des séquences d'octets qui ne forment pas des caractères valides ou si les variables de shell peuvent contenir ces chaînes.
En pratique, en dehors des yash
variables dont les caractères ne peuvent contenir que des caractères, et en dehors des octets NUL (qui ne zsh
peuvent pas être shell mais stockés dans leurs variables), *$nl*
doivent correspondre sur n'importe quelle chaîne qui contient $nl
même si elles contiennent des séquences d'octets qui ne sont pas valides caractères (comme $'\x80'
en UTF-8).
Certaines find
implémentations, par exemple, ne pourraient pas correspondre avec -name "*$nl*"
elles, donc si vous testez un nouveau shell et si vous avez l'intention de traiter des choses qui ne sont pas garanties comme du texte (comme les noms de fichiers), vous voudrez peut-être lui ajouter un cas de test. Comme avec:
test=$(printf '\200\n\200')
dans un environnement local UTF-8.