Existe-t-il un outil Bash standard qui agit comme echo mais qui sort sur stderr plutôt que sur stdout ?
Je sais que je peux faire echo foo 1>&2 mais c'est plutôt laid et, je le soupçonne, sujet à des erreurs (par exemple, plus susceptible d'être modifié de manière erronée lorsque les choses changent).
Vous pouvez le faire, ce qui facilite la lecture :
>&2 echo "error">&2 copie le descripteur de fichier n°2 sur le descripteur de fichier n°1. Par conséquent, une fois cette redirection effectuée, les deux descripteurs de fichiers feront référence au même fichier : le descripteur de fichier n°2 était à l'origine se référant à. Pour plus d'informations, voir le Tutoriel de redirection illustré par Bash Hackers .
J'ai appris cette astuce il y a longtemps. Cette page contient de bonnes informations. tldp.org/LDP/abs/html/io-redirection.html
@BCS Je ne sais pas si l'on peut utiliser une alias dans un shell script. Il serait probablement plus sûr d'utiliser errcho(){ >&2 echo $@; }
Vous pourriez définir une fonction :
echoerr() { echo "$@" 1>&2; }
echoerr hello worldCela serait plus rapide qu'un script et n'aurait pas de dépendances.
La suggestion spécifique à bash de Camilo Martin utilise une "here string" et imprimera tout ce que vous lui passez, y compris les arguments (-n) que echo devrait normalement avaler :
echoerr() { cat <<< "$@" 1>&2; }La solution de Glenn Jackman évite également le problème de la déglutition des arguments :
echoerr() { printf "%s\n" "$*" >&2; }
Je dois dire que l'écho n'est pas très fiable. echoerr -ne xt ne va pas imprimer "-ne xt". Il vaut mieux utiliser printf pour ça.
Depuis 1 est la sortie standard, il n'est pas nécessaire de la nommer explicitement devant une redirection de sortie telle que > . Au lieu de cela, vous pouvez simplement taper :
echo This message goes to stderr >&2Puisque vous semblez être inquiet que 1>&2 sera difficile à taper de manière fiable, l'élimination de la redondance 1 pourrait être un léger encouragement pour vous !
Cette option est-elle portable ? Quelqu'un sait-il si cela ne fonctionne pas pour certaines saveurs Unix ?
Si le script qui exécute cette ligne - appelons-le foo - a son propre stderr redirigé - e.g. foo >foo.log 2>&1 - alors echo foo >/dev/stderr va écraser toutes les sorties avant elle. >> doit être utilisé à la place : echo foo >>/dev/stderr
Il ne devrait pas provoquer d'erreurs, mais il est plus probable que ce soit le cas. Par contre, ce n'est pas si grave.
La seule possibilité d'échec est que l'ID de fichier pour stdout ne soit pas 1 ou que l'ID de fichier pour stderr ne soit pas 2. Comme ces constantes sont définies par POSIX.1, qui, je crois, est une condition préalable à la construction de bash, cela fonctionnera dans un avenir prévisible. Ainsi, je suis curieux de savoir ce que vous entendez par "susceptible d'être modifié de façon erronée lorsque les choses changent". Avez-vous un problème similaire avec les personnes qui changent le mot "echo" en quelque chose d'autre ?
@Mike DeSimone : Si quelqu'un d'autre s'amuse avec le code, mélange la sortie, et ne connaît pas vraiment bash, il pourrait facilement laisser tomber (ou faire une erreur de frappe) l'option 1>&2 . Nous souhaitons tous que cela n'arrive pas, mais je suis sûr que nous avons tous été dans des endroits où cela arrive.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
En rapport : stackoverflow.com/a/12704488/194894