eco che emette su stderr

Esiste uno strumento Bash standard che agisce come l'eco ma genera su stderr anziché su stdout?

So di poterlo fare, echo foo 1>&2ma è un po 'brutto e, sospetto, soggetto a errori (ad esempio, è più probabile che venga modificato in modo errato quando le cose cambiano).

Potresti farlo, il che facilita la lettura:

>&2 echo "error"

>&2copia il descrittore di file n. 2 nel descrittore di file n. 1. Pertanto, dopo aver eseguito questo reindirizzamento, entrambi i descrittori di file faranno riferimento allo stesso file: l'unico descrittore di file n. 2 si riferiva originariamente . Per ulteriori informazioni, consultare il tutorial di reindirizzamento illustrato di Bash Hackers .

È possibile definire una funzione:

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

Questo sarebbe più veloce di uno script e non ha dipendenze.

Il suggerimento specifico di bash di Camilo Martin usa una "stringa qui" e stamperà tutto ciò che gli passa, inclusi argomenti (-n) che l'eco normalmente inghiottirebbe:

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

La soluzione di Glenn Jackman evita anche l'argomento deglutizione argomento:

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

Poiché 1è l'output standard, non è necessario nominarlo esplicitamente di fronte a un reindirizzamento dell'output come, >ma invece è sufficiente digitare:

echo Questo messaggio va a stderr> & 2

Dal momento che sembri preoccupato che 1>&2sarà difficile digitare in modo affidabile, l'eliminazione del ridondante 1potrebbe essere un leggero incoraggiamento per te!

Un'altra opzione

echo foo >>/dev/stderr

No, questo è il modo standard per farlo. Non dovrebbe causare errori.

Se non ti dispiace registrare il messaggio anche su syslog, il modo not_so_ugly è:

logger -s $msg

L'opzione -s significa: "Invia il messaggio all'errore standard e al registro di sistema".

Questa è una semplice funzione STDERR, che reindirizza l'input della pipe su 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

Nota: sto rispondendo al post, non alla domanda fuorviante / vaga "eco che emette a stderr" (già risposta dall'OP).

Utilizzare una funzione per mostrare l' intenzione e ottenere l'implementazione desiderata. Per esempio

#!/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!"

Ed error_handlingessere:

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"; }

Ragioni che gestiscono le preoccupazioni in OP:

• la sintassi più bella possibile (parole significative anziché simboli brutti)
• più difficile fare un errore (specialmente se riutilizzi lo script)
• non è uno strumento Bash standard, ma può essere una libreria shell standard per te o per la tua azienda / organizzazione

Altri motivi:

• chiarezza - mostra l'intenzione di altri manutentori
• velocità: le funzioni sono più veloci degli script di shell
• riusabilità: una funzione può chiamare un'altra funzione
• configurabilità: non è necessario modificare lo script originale
• debugging: è più facile trovare la linea responsabile di un errore (specialmente se stai lavorando con un sacco di output di reindirizzamento / filtro)
• robustezza: se manca una funzione e non è possibile modificare lo script, è possibile ricorrere all'utilizzo di uno strumento esterno con lo stesso nome (ad es. log_error può essere modificato con il logger su Linux)
• commutazione di implementazioni: è possibile passare a strumenti esterni rimuovendo l'attributo "x" della libreria
• output agnostico: non devi più preoccuparti se va su STDERR o altrove
• personalizzazione: è possibile configurare il comportamento con le variabili di ambiente

Il mio consiglio:

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

o

echo "my errz" >> /dev/stderr

echo "my errz" > /proc/self/fd/2sarà efficacemente uscita stderrperché /proc/selfè un collegamento al processo corrente, e /proc/self/fdtiene il processo aperto descrittori di file, e poi, 0, 1, e 2riposare stdin, stdoute stderrrispettivamente.

Il /proc/selfcollegamento non funziona su MacOS, tuttavia, /proc/self/fd/*è disponibile su Termux su Android, ma non /dev/stderr. Come rilevare il sistema operativo da uno script Bash? può aiutarti se devi rendere il tuo script più portatile determinando quale variante usare.

Non usare catcome alcuni sono menzionati qui. catè un programma mentre echoe printfsono builtin bash (shell). Lanciare un programma o un altro script (anche menzionato sopra) significa creare un nuovo processo con tutti i suoi costi. Usando i builtin, le funzioni di scrittura sono abbastanza economiche, perché non è necessario creare (eseguire) un processo (-ambiente).

L'opner chiede "esiste uno strumento standard per l'output ( pipe ) su stderr", la risposta schort è: NO ... perché? ... rediredcting pipe è un concetto essenziale in sistemi come unix (Linux ...) e bash (sh) si basa su questi concetti.

Sono d'accordo con l'apri che reindirizza con notazioni come questa: &2>1 non è molto piacevole per i programmatori moderni, ma è bash. Bash non aveva lo scopo di scrivere programmi enormi e robusti, ma ha lo scopo di aiutare gli amministratori a farci lavorare con meno tasti premuti ;-)

E almeno, puoi posizionare il reindirizzamento in qualsiasi punto della linea:

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

Un'altra opzione su cui mi sono imbattuto di recente è questa:

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

Questo utilizza solo i built-in di Bash, rendendo l'output di errori su più righe meno soggetto a errori (poiché non è necessario ricordare di aggiungere &>2ad ogni riga).

read è un comando incorporato della shell che stampa su stderr e può essere usato come eco senza eseguire trucchi di reindirizzamento:

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

La -t 0.1è un timeout che disattiva funzionalità principale di leggere, memorizzare una riga di stdin in una variabile.

Crea una sceneggiatura

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

quello sarebbe il tuo strumento.

Oppure crea una funzione se non vuoi avere uno script in un file separato.

Combinazione di soluzioni suggerite da James Roth e Glenn Jackman

• aggiungi il codice colore ANSI per visualizzare il messaggio di errore in rosso:

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: ho provato la risposta accettata e un paio di altre risposte e tutte hanno portato a scrivere STDOUT e non STDERR sul mio Mac.

Ecco un modo portatile per scrivere sull'errore standard usando Perl:

echo WARNING! | perl -ne 'print STDERR'