écho qui sort vers stderr

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

Je sais que je peux le faire, echo foo 1>&2mais c'est un peu moche et, je suppose, sujet aux erreurs (par exemple, plus susceptibles de se tromper lorsque les choses changent).

Vous pouvez le faire, ce qui facilite la lecture:

>&2 echo "error"

>&2copie le descripteur de fichier # 2 dans le descripteur de fichier # 1. Par conséquent, après cette redirection est effectuée, les deux descripteurs de fichiers se référeront au même fichier: le descripteur d' un fichier # 2 a été à l' origine référence. Pour plus d'informations, consultez le didacticiel de redirection illustré de Bash Hackers .

Vous pouvez définir une fonction:

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

Ce serait plus rapide qu'un script et sans dépendances.

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

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

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

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

Puisque 1c'est la sortie standard, vous n'avez pas besoin de la nommer explicitement devant une redirection de sortie comme >mais à la place vous pouvez simplement taper:

echo Ce message va à stderr> & 2

Étant donné que vous semblez inquiet de ce que vous 1>&2aurez du mal à taper de manière fiable, l'élimination du redondant 1pourrait être un léger encouragement pour vous!

Une autre option

echo foo >>/dev/stderr

Non, c'est la façon standard de procéder. Cela ne devrait pas provoquer d'erreurs.

Si cela ne vous dérange pas de consigner également le message dans syslog, la méthode not_so_ugly est la suivante:

logger -s $msg

L'option -s signifie: "Envoyer le message à l'erreur standard ainsi qu'au journal système."

Il s'agit d'une simple fonction STDERR, qui redirige l'entrée de canal 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

Remarque: je réponds à la question - pas à la question "écho trompeur / vague qui sort vers stderr" (déjà répondu par OP).

Utilisez une fonction pour montrer l' intention et source l'implémentation que vous souhaitez. 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"; }

Raisons qui gèrent les préoccupations du PO:

• syntaxe la plus agréable 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 responsables
• vitesse - les fonctions sont plus rapides que les scripts shell
• réutilisabilité - une fonction peut appeler une autre fonction
• configurabilité - pas besoin de modifier le script d'origine
• débogage - plus facile de trouver la ligne responsable d'une erreur (surtout si vous vous trompez avec une tonne de sortie de redirection / filtrage)
• robustesse - si une fonction est manquante et que vous ne pouvez pas modifier le script, vous pouvez revenir à l'utilisation d'un outil externe du même nom (par exemple, log_error peut être aliasé dans logger sous Linux)
• changer d'implémentation - vous pouvez passer à des outils externes en supprimant l'attribut "x" de la bibliothèque
• sortie agnostique - vous n'avez plus à vous soucier si elle va à STDERR ou ailleurs
• personnalisation - vous pouvez configurer le comportement avec des variables d'environnement

Ma suggestion:

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

ou

echo "my errz" >> /dev/stderr

echo "my errz" > /proc/self/fd/2aura pour effet de sortie , stderrcar /proc/selfun lien vers le processus en cours, et /proc/self/fdmaintient le processus descripteurs de fichiers ouverts, puis, 0, 1et 2reposer stdin, stdoutetstderr respectivement.

Le /proc/selflien ne fonctionne pas sur MacOS, cependant, /proc/self/fd/*est disponible sur Termux sur Android, mais pas /dev/stderr. Comment détecter le système d'exploitation à partir d'un script Bash? peut vous aider si vous devez rendre votre script plus portable en déterminant la variante à utiliser.

Ne pas utiliser catcar certains sont mentionnés ici. catest un programme while echoet printfsont intégrés à bash (shell). Lancer un programme ou un autre script (également mentionné ci-dessus) signifie créer un nouveau processus avec tous ses coûts. En utilisant les fonctions intégrées, les fonctions d'écriture sont assez bon marché, car il n'est pas nécessaire de créer (exécuter) un processus (-environnement).

L'opner demande "existe-t-il un outil standard pour sortir ( pipe ) vers stderr", la réponse de schort est: NON ... pourquoi? ... rediriger les tuyaux est un concept élémentaire dans des systèmes comme unix (Linux ...) et bash (sh) s'appuie sur ces concepts.

Je suis d'accord avec l'ouvreur que la redirection avec des notations comme celle-ci: &2>1n'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 administrateurs à 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

Une autre option sur laquelle j'ai récemment trébuché est la suivante:

    {
        echo "First error line"
        echo "Second error line"
        echo "Third error line"
    } >&2

Cela n'utilise que les Bash intégrés tout en rendant la sortie d'erreur multi-lignes moins sujette aux erreurs (puisque vous n'avez pas à vous rappeler d'ajouter &>2à chaque ligne).

read est une commande intégrée au shell qui imprime sur stderr et peut être utilisée comme echo sans effectuer de trucs de redirection:

read -t 0.1 -p "This will be sent to stderr"

Le -t 0.1est un timeout qui désactive la fonctionnalité principale de read, stockant une ligne de stdin dans une variable.

Faire un script

#!/bin/sh
echo $* 1>&2

ce serait votre outil.

Ou créez une fonction si vous ne voulez pas avoir un script dans un fichier séparé.

Solution de combinaison suggérée par James Roth et Glenn Jackman

• ajoutez un code couleur ANSI pour afficher le message d'erreur en rouge:

echoerr() { printf "\e[31;1m%s\e[0m\n" "$*" >&2; }

# if somehow \e is not working on your terminal, use \u001b instead
# echoerr() { printf "\u001b[31;1m%s\u001b[0m\n" "$*" >&2; }

echoerr "This error message should be RED"

Mac OS X: J'ai essayé la réponse acceptée et quelques autres réponses et toutes ont abouti à l'écriture de STDOUT et non de STDERR sur mon Mac.

Voici une façon portable d'écrire sur une erreur standard en utilisant Perl:

echo WARNING! | perl -ne 'print STDERR'