echo wysyłane do stderr

Czy istnieje standardowe narzędzie Bash, które działa jak echo, ale wysyła sygnał do stderr zamiast stdout?

Wiem, że mogę to zrobić, echo foo 1>&2ale jest to trochę brzydkie i, jak podejrzewam, podatne na błędy (np. Bardziej prawdopodobne, że zostaną źle zmienione, gdy coś się zmieni).

Możesz to zrobić, co ułatwia czytanie:

>&2 echo "error"

>&2kopiuje deskryptor pliku # 2 do deskryptora pliku # 1. Dlatego po wykonaniu tego przekierowania oba deskryptory plików będą odnosić się do tego samego pliku: pierwotnie odnosiło się do deskryptora jednego pliku # 2 . Więcej informacji można znaleźć w samouczku ilustrowanym przekierowaniu hakerów Bash .

Możesz zdefiniować funkcję:

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

Byłoby to szybsze niż skrypt i nie miałyby żadnych zależności.

Sugestia specyficzna dla bash Camilo Martina używa „tutaj ciągu” i wypisze wszystko, co do niej przekażesz, w tym argumenty (-n), które echo normalnie przełknie:

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

Rozwiązanie Glenna Jackmana pozwala również uniknąć problemu z połykaniem argumentów:

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

Ponieważ 1jest to standardowe wyjście, nie musisz jawnie nadawać mu nazwy przed przekierowaniem wyjścia, >ale możesz po prostu wpisać:

echo Ta wiadomość trafia do stderr> i 2

Ponieważ wydajesz się martwić, że 1>&2trudno będzie Ci rzetelnie pisać, eliminacja zbędnych 1może być dla ciebie niewielką zachętą!

Inna opcja

echo foo >>/dev/stderr

Nie, to standardowy sposób na zrobienie tego. Nie powinno to powodować błędów.

Jeśli nie masz nic przeciwko rejestrowaniu wiadomości również w syslog, nie not_so_ugly sposób to:

logger -s $msg

Opcja -s oznacza: „Wyświetlaj komunikat o błędzie standardowym, a także w dzienniku systemowym”.

Jest to prosta funkcja STDERR, która przekierowuje wejście potoku do 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

Uwaga: odpowiadam na pytanie, a nie na mylące / niejasne echo „wyjściowe do stderr” (na które już odpowiedział OP).

Użyj funkcji, aby pokazać zamiar i źródło pożądanej implementacji. Na przykład

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

I error_handlingbędąc:

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

Powody, które uwzględniają obawy w PO:

• najładniejsza możliwa składnia (znaczące słowa zamiast brzydkich symboli)
• trudniej popełnić błąd (szczególnie jeśli ponownie użyjesz skryptu)
• nie jest to standardowe narzędzie Bash, ale może być standardową biblioteką powłoki dla Ciebie lub Twojej firmy / organizacji

Inne powody:

• jasność - pokazuje zamiar innym opiekunom
• prędkość - funkcje są szybsze niż skrypty powłoki
• wielokrotnego użytku - funkcja może wywoływać inną funkcję
• konfigurowalność - nie trzeba edytować oryginalnego skryptu
• debugowanie - łatwiej znaleźć linię odpowiedzialną za błąd (szczególnie jeśli jesteś martwy z mnóstwem wyników przekierowywania / filtrowania)
• solidność - jeśli brakuje funkcji i nie możesz edytować skryptu, możesz wrócić do korzystania z zewnętrznego narzędzia o tej samej nazwie (np. log_error może być aliasowany do loggera w systemie Linux)
• przełączanie implementacji - możesz przełączyć się na narzędzia zewnętrzne, usuwając atrybut „x” biblioteki
• wyjście agnostyczne - nie musisz się już przejmować, czy przejdzie do STDERR czy gdzie indziej
• personalizacja - możesz skonfigurować zachowanie za pomocą zmiennych środowiskowych

Moja sugestia:

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

lub

echo "my errz" >> /dev/stderr

echo "my errz" > /proc/self/fd/2będzie skutecznie wyjście do stderrponieważ /proc/selfjest link do bieżącego procesu, a /proc/self/fdtrzyma procesu otwarte deskryptory plików, a następnie 0, 1i 2stanąć na stdin, stdouti stderrodpowiednio.

/proc/selfLink nie działa na MacOS, jednak /proc/self/fd/*jest dostępny na Termux na Androidzie, ale nie /dev/stderr. Jak wykryć system operacyjny ze skryptu Bash? może pomóc, jeśli chcesz uczynić skrypt bardziej przenośnym, określając, którego wariantu użyć.

Nie używaj, catponieważ niektóre są tutaj wymienione. catto program, podczas echoi printfsą atakujących (Shell) builtins. Uruchomienie programu lub innego skryptu (również wspomnianego powyżej) oznacza utworzenie nowego procesu ze wszystkimi jego kosztami. Korzystanie z wbudowanych funkcji pisania jest dość tanie, ponieważ nie ma potrzeby tworzenia (wykonywania) procesu (środowiska).

Opner pyta „czy jest jakieś standardowe narzędzie do wyprowadzania ( rury ) do stderr”, odpowiedź Schorta brzmi: NIE… dlaczego? ... przeprojektowane potoki to elementarna koncepcja w systemach takich jak unix (Linux ...) i bash (sh) bazuje na tych koncepcjach.

Zgadzam się z otwieraczem, że przekierowywanie za pomocą takich notacji: &2>1nie jest zbyt przyjemne dla współczesnych programistów, ale to bzdura. Bash nie był przeznaczony do pisania dużych i solidnych programów, ma na celu pomóc administratorom w pracy przy mniejszej liczbie naciśnięć klawiszy ;-)

Przynajmniej możesz umieścić przekierowanie w dowolnym miejscu linii:

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

Inną opcją, na którą ostatnio natknąłem jest:

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

Wykorzystuje tylko wbudowane Bash, jednocześnie zmniejszając ryzyko wystąpienia błędów wieloliniowych (ponieważ nie trzeba pamiętać o dodawaniu &>2do każdej linii).

read to wbudowane polecenie powłoki, które drukuje na stderr i może być używane jak echo bez wykonywania sztuczek przekierowania:

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

-t 0.1Jest limit czasu, który wyłącza czytać Głównego funkcjonalność przechowywania jeden wiersz standardowego wejścia do zmiennej.

Stwórz skrypt

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

to byłoby twoje narzędzie.

Lub utwórz funkcję, jeśli nie chcesz mieć skryptu w osobnym pliku.

Mac OS X: Wypróbowałem zaakceptowaną odpowiedź i kilka innych odpowiedzi, a wszystkie z nich spowodowały napisanie STDOUT, a nie STDERR na moim komputerze Mac.

Oto przenośny sposób zapisu standardowego błędu za pomocą Perla:

echo WARNING! | perl -ne 'print STDERR'