escape - colors bash prompt

eco que da salida a stderr

Question

¿Existe una herramienta estándar de Bash que actúe como eco pero que salga a stderr en lugar de stdout?

Sé que puedo hacer echo foo 1>&2 pero es algo feo y, sospecho, propenso a errores (por ejemplo, es más probable que se edite mal cuando las cosas cambian).

Answer 1

Dado que 1 es la salida estándar, no tiene que nombrarlo explícitamente delante de una redirección de salida como > sino que simplemente puede escribir:

echo This message goes to stderr >&2

Ya que parece que le preocupa que 1>&2 le resulte difícil escribir de manera confiable, ¡la eliminación del redundante 1 podría ser un leve estímulo para usted!

Answer 2

Esta es una función STDERR simple, que redirige la entrada de la tubería a 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

Answer 3

Esta pregunta es antigua, pero puedes hacer esto, lo que facilita la lectura:

>&2 echo "error"

El operador >&2 significa literalmente redireccionar la dirección del descriptor de archivo 1 ( stdout ) a la dirección del descriptor de archivo 2 ( stderr ) para ese comando ¹ . Dependiendo de qué tan profundamente quiera entenderlo, lea esto: http://wiki.bash-hackers.org/howto/redirection_tutorial

Para evitar la interacción con otras redirecciones use subshell.

(>&2 echo "error")

¹ _{>&2 copia el descriptor de archivo # 2 al descriptor de archivo # 1. Por lo tanto, después de realizar esta redirección, ambos descriptores de archivo se referirán al mismo archivo: el descriptor de archivo # 2 originalmente se refería.}

Answer 4

Esto ya ha sido respondido y con muchos votos. Solo para que conste:

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

efectivamente se hará salir a stderr . Explicación: /proc/self es un enlace al proceso actual y /proc/self/fd contiene el proceso abierto de descriptores de archivos. Luego, 0 , 1 y 2 siglas de stdin , stdout y stderr respectivamente.

Lo encontré más legible. También esto puede funcionar en la mayoría de las distribuciones de Linux:

echo "my errz" > /dev/stderr

Haciéndolo mucho más legible.

Answer 5

Hacer un guion

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

Esa sería tu herramienta.

O haga una función si no quiere tener un script en un archivo separado.

Answer 6

No use cat como algunos se mencionan aquí. cat es un programa, mientras que echo y printf son bash (shell) builtins. Lanzar un programa u otro script (también mencionado anteriormente) significa crear un nuevo proceso con todos sus costos. Usando builtin, las funciones de escritura son bastante baratas, porque no hay necesidad de crear (ejecutar) un proceso (-environment).

El opner pregunta: "¿hay alguna herramienta estándar para enviar ( tubería ) a stderr?" ... rediredcting pipe es un concepto fundamental en sistemas como Unix (Linux ...) y bash (sh) se basa en estos conceptos.

Estoy de acuerdo con la apertura de que la redirección con notaciones como esta: &2>1 no es muy agradable para los programadores modernos, pero eso es bash. Bash no tenía la intención de escribir programas grandes y robustos, estaba destinado a ayudar a los administradores a lograr que funcionen con menos pulsaciones de teclas ;-)

Y al menos, puede colocar la redirección en cualquier lugar de la línea:

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

Answer 7

No, esa es la forma estándar de hacerlo. No debería causar errores.

Answer 8

Otra opción

echo foo >>/dev/stderr

Answer 9

Podrías definir una función:

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

Esto sería más rápido que un script y no tendría dependencias.

La sugerencia específica de bash de Camilo Martin utiliza una "cadena de aquí" e imprimirá todo lo que le pases, incluidos los argumentos (-n) que el eco normalmente tragaría:

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

La solución de Glenn Jackman también evita el problema de tragar el argumento:

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

Answer 10

Si no le importa registrar el mensaje también en syslog, la forma de not_so_ugly es:

logger -s $msg

La opción -s significa: "Enviar el mensaje a un error estándar así como al registro del sistema".

Answer 11

read es un comando incorporado en la shell que se imprime en stderr, y se puede usar como eco sin realizar trucos de redirección:

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

El -t 0.1 es un tiempo de espera que deshabilita la funcionalidad principal de lectura, almacenando una línea de entrada estándar en una variable.

Answer 12

Mac OS X: probé la respuesta aceptada y un par de otras respuestas y todas resultaron en escribir STDOUT no STDERR en mi Mac.

Aquí hay una forma portátil de escribir un error estándar usando Perl:

echo WARNING! | perl -ne ''print STDERR''

Answer 13

Nota: Estoy respondiendo la pregunta post-no el "eco que induce a error / impreciso a stderr" (ya contestada por OP).

Utilice una función para mostrar la intención y la fuente de la implementación que desea. P.ej

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

Y error_handling siendo:

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

Razones que manejan preocupaciones en OP:

• La mejor sintaxis posible (palabras significativas en lugar de símbolos feos)
• Es más difícil cometer un error (especialmente si reutiliza el script)
• no es una herramienta Bash estándar, pero puede ser una biblioteca de shell estándar para usted o su empresa / organización

Otras razones:

• claridad - muestra intención a otros mantenedores
• velocidad - las funciones son más rápidas que los scripts de shell
• reutilización - una función puede llamar a otra función
• Configurabilidad - no es necesario editar el script original
• depuración: es más fácil encontrar la línea responsable de un error (especialmente si está perdiendo el tiempo con una tonelada de salida de redireccionamiento / filtrado)
• robustez: si falta una función y no puede editar el script, puede recurrir a la utilización de una herramienta externa con el mismo nombre (por ejemplo, log_error puede asociarse al registrador en Linux)
• cambio de implementaciones: puede cambiar a herramientas externas eliminando el atributo "x" de la biblioteca
• agnóstico de salida: ya no tiene que preocuparse si va a STDERR o a otro lugar
• Personalización: puede configurar el comportamiento con variables de entorno.