Question echo qui renvoie vers stderr


Existe-t-il un outil Bash standard qui fonctionne comme un écho mais qui renvoie vers stderr plutôt que stdout?

Je sais que je peux faire echo foo 1>&2 mais il est plutôt moche et, je le soupçonne, sujet à des erreurs (par exemple, plus susceptible d'être mal édité lorsque les choses changent).


785
2018-06-07 14:36


origine


Réponses:


Cette question est ancienne, mais vous pouvez le faire, ce qui facilite la lecture:

>&2 echo "error"

L'opérateur >&2 signifie littéralement rediriger l'adresse du descripteur de fichier 1 (stdout) à l'adresse du descripteur de fichier 2 (stderr) pour cette commande1. En fonction de la profondeur de votre compréhension, lisez ceci: http://wiki.bash-hackers.org/howto/redirection_tutorial

Pour éviter l'interaction avec d'autres redirections, utilisez le sous-shell

(>&2 echo "error")

1>&2 copie le descripteur de fichier n ° 2 dans le descripteur de fichier n ° 1. Par conséquent, après que cette redirection est effectuée, les deux descripteurs de fichiers se référeront au même fichier: le descripteur de fichier # 2 était initialement se référant à.


977
2018-05-08 18:59



Vous pourriez définir une fonction:

echoerr() { echo "$@" 1>&2; }
echoerr hello world

Ce serait plus rapide qu'un script et n'a pas de dépendances.

La suggestion spécifique de bash de Camilo Martin utilise une "chaîne ici" et imprime tout ce que vous lui passez, y compris les arguments (-n) que l'écho devrait normalement avaler:

echoerr() { cat <<< "$@" 1>&2; }

La solution de Glenn Jackman évite également le problème de déglutition:

echoerr() { printf "%s\n" "$*" >&2; }

355
2018-06-07 14:52



Depuis 1 est la sortie standard, vous n'avez pas à le nommer explicitement devant une redirection de sortie comme > mais au lieu de simplement taper:

echo Ce message va à stderr> & 2

Puisque vous semblez être inquiet 1>&2 sera difficile pour vous de taper de manière fiable, l'élimination du redondant 1 pourrait être un léger encouragement pour vous!


202
2017-07-10 21:24



Une autre option

echo foo >>/dev/stderr

39
2018-01-16 03:57



Non, c'est la façon standard de le faire. Cela ne devrait pas causer d'erreurs.


29
2018-06-07 14:37



C'est une fonction STDERR simple, qui redirige l'entrée de pipe vers STDERR.

#!/bin/bash
# *************************************************************
# This function redirect the pipe input to STDERR.
#
# @param stream
# @return string
#
function STDERR () {

cat - 1>&2

}

# remove the directory /bubu
if rm /bubu 2>/dev/null; then
    echo "Bubu is gone."
else
    echo "Has anyone seen Bubu?" | STDERR
fi


# run the bubu.sh and redirect you output
tux@earth:~$ ./bubu.sh >/tmp/bubu.log 2>/tmp/bubu.err

12
2018-02-03 08:40



Si cela ne vous dérange pas de consigner le message dans syslog, not_so_ugly est:

logger -s $msg

L'option -s signifie: "Affiche le message dans l'erreur standard ainsi que dans le journal système."


9
2017-08-04 19:15



Ne pas utiliser cat comme certains sont mentionnés ici. cat est un programme  tandis que echo et printf sont des intégrations bash (shell). Lancement d'un programme ou un autre script (également mentionné ci-dessus) signifie créer un nouveau processus avec tous ses coûts. En utilisant les builtins, les fonctions d'écriture sont assez bon marché, car il n'est pas nécessaire de créer (exécuter) un processus (-environment).

L'opener demande "existe-t-il un outil standard pour sortir (tuyau) à stderr ", la réponse schort est: NON ... pourquoi? ... rediredcting pipes est un concept élémantaire dans des systèmes comme unix (Linux ...) et bash (sh) construit sur ces concepts.

Je suis d'accord avec l'ouverture que rediriger avec des notations comme ceci: &2>1 n'est pas très agréable pour les programmeurs modernes, mais c'est bash. Bash n'était pas destiné à écrire des programmes énormes et robustes, il est destiné à aider les admins à y travailler avec moins de touches ;-)

Et au moins, vous pouvez placer la redirection n'importe où dans la ligne:

$ echo This message >&2 goes to stderr 
This message goes to stderr

9
2017-10-09 13:18



Note: Je réponds à la question post - pas à la question trompeuse / vague "echo that outputs to stderr" (déjà répondu par OP).

Utilisez une fonction pour montrer le intention et source l'implémentation que vous voulez. Par exemple.

#!/bin/bash

[ -x error_handling ] && . error_handling

filename="foobar.txt"
config_error $filename "invalid value!"

output_xml_error "No such account"

debug_output "Skipping cache"

log_error "Timeout downloading archive"

notify_admin "Out of disk space!"

fatal "failed to open logger!"

Et error_handling étant:

ADMIN_EMAIL=root@localhost

config_error() { filename="$1"; shift; echo "Config error in $filename: $*" 2>&1; }

output_xml_error() { echo "<error>$*</error>" 2>&1; }

debug_output() { [ "$DEBUG"=="1" ] && echo "DEBUG: $*"; }

log_error() { logger -s "$*"; }

fatal() { which logger >/dev/null && logger -s "FATAL: $*" || echo "FATAL: $*"; exit 100; }

notify_admin() { echo "$*" | mail -s "Error from script" "$ADMIN_EMAIL"; }

Les raisons qui gèrent les préoccupations dans OP:

  • meilleure syntaxe possible (mots significatifs au lieu de symboles laids)
  • plus difficile de faire une erreur (surtout si vous réutilisez le script)
  • ce n'est pas un outil Bash standard, mais il peut s'agir d'une bibliothèque shell standard pour vous ou votre entreprise / organisation

Autres raisons:

  • clarté - montre l'intention aux autres mainteneurs
  • speed - les fonctions sont plus rapides que les scripts shell
  • réutilisabilité - une fonction peut appeler une autre fonction
  • configurabilité - pas besoin d'éditer le script original
  • débogage - plus facile de trouver la ligne responsable d'une erreur (surtout si vous êtes deadling avec une tonne de sortie de redirection / filtrage)
  • robustesse - si une fonction est manquante et que vous ne pouvez pas éditer le script, vous pouvez revenir à l'utilisation d'un outil externe portant le même nom (par exemple, log_error peut être aliasé par un enregistreur sous Linux)
  • les implémentations de commutation - vous pouvez passer à des outils externes en supprimant l'attribut "x" de la bibliothèque
  • sortie agnostique - vous n'avez plus à vous préoccuper de savoir si ça va à STDERR ou ailleurs
  • personnalisation - vous pouvez configurer le comportement avec des variables d'environnement

6
2018-03-18 18:07



Cela a déjà été répondu et avec beaucoup de votes. Juste pour info:

echo "my errz" > /proc/self/fd/2

va effectivement sortir à stderr. Explication: /proc/self est un lien vers le processus actuel et /proc/self/fd détient le processus des descripteurs de fichiers ouverts. Alors, 0, 1, et 2 signifie stdin, stdout et stderr respectivement.

Je l'ai trouvé plus lisible. Cela peut également fonctionner dans la plupart des distributions Linux:

echo "my errz" > /dev/stderr

Ce qui rend beaucoup plus lisible.


5
2017-09-03 01:48