Pregunta echo que salidas a stderr


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

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


785
2018-06-07 14:36


origen


Respuestas:


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

>&2 echo "error"

El operador >&2 literalmente significa redirigir la dirección del descriptor de archivo 1 (stdout) a la dirección del descriptor de archivo 2 (stderr) para ese comando1. Dependiendo de cuán profundamente quieras entenderlo, lee esto: http://wiki.bash-hackers.org/howto/redirection_tutorial

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

(>&2 echo "error")

1>&2 copia el descriptor de archivo n. ° 2 al descriptor de archivo n. ° 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 fue originalmente refiriéndose a.


977
2018-05-08 18:59



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 tiene dependencias.

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

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

La solución de Glenn Jackman también evita el problema de deglución de argumentos:

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

355
2018-06-07 14:52



Ya que 1 es el resultado estándar, no tiene que nombrarlo explícitamente frente a una redirección de salida como > pero en su lugar puede simplemente escribir:

echo Este mensaje va a stderr> & 2

Dado que pareces estar preocupado de que 1>&2 será difícil para ti escribir de manera confiable, la eliminación de los redundantes 1 podría ser un ligero aliento para ti!


202
2017-07-10 21:24



Otra opción

echo foo >>/dev/stderr

39
2018-01-16 03:57



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


29
2018-06-07 14:37



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

12
2018-02-03 08:40



Si no le importa registrar el mensaje también en syslog, la manera no_saliente es:

logger -s $msg

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


9
2017-08-04 19:15



No usar cat como algunos se mencionan aquí. cat es un programa  mientras echo y printf son basil (shell) builtins. Lanzando un programa o un script adicional (también mencionado anteriormente) significa crear un nuevo proceso con todos sus costos. Al usar las instrucciones internas, las funciones de escritura son bastante baratas, porque no es necesario crear (ejecutar) un proceso (-entorno).

El opner pregunta "¿hay alguna herramienta estándar para producir (tubo) stderr ", la respuesta de Schort es: NO ... ¿por qué? ... las tuberías de redirección son un concepto elemental en sistemas como Unix (Linux ...) y Bash (sh) se basa en estos conceptos.

Estoy de acuerdo con el abridor que redirige 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, sino ayudar a los administradores a trabajar allí con menos teclados ;-)

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

9
2017-10-09 13:18



Nota: Estoy respondiendo la pregunta post-no engañosa / vaga "echo that outputs to stderr" (ya respondida por OP).

Use una función para mostrar intención y fuente 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 desagradables)
  • más difícil de cometer un error (especialmente si reutilizas 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 las secuencias de comandos 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á reduciendo un montón de redirigir / filtrar)
  • solidez: si falta una función y no puede editar la secuencia de comandos, puede recurrir a la herramienta externa con el mismo nombre (por ejemplo, log_error puede asociarse al registrador en Linux)
  • Conmutación de implementaciones: puede cambiar a herramientas externas eliminando el atributo "x" de la biblioteca
  • agnóstico de salida: ya no tiene que importarle si va a STDERR o a otro lugar
  • personalización: puede configurar el comportamiento con variables de entorno

6
2018-03-18 18:07



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

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

efectivamente dará salida a stderr. Explicación: /proc/self es un enlace al proceso actual y /proc/self/fd mantiene el proceso abierto descriptores de archivos. Entonces, 0, 1y 2 representa 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.


5
2017-09-03 01:48



read es un comando integrado de 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"

los -t 0.1 es un tiempo de espera que desactiva la funcionalidad principal de la lectura, almacenando una línea de stdin en una variable.


3
2018-01-24 00:16