¿Por qué " >/dev/console" para el pitido remoto (comando de eco)?

Question

Aprendí que este comando:

echo -e "\a"

activa un pitido en el sistema local, mientras que este comando:

echo -e "\a" >/dev/console

activa un pitido en un sistema remoto.

¿Por qué es esto? ¿Qué está haciendo la >/dev/consoleparte?

¿Por qué la ejecución echo -e "\a"en una máquina remota activa el pitido localmente y no de forma remota?

¿Por qué al comando "echo" no le gusta sudo?

¿Existe un esquema similar a una capa OSI? Por favor proporciónenme alguna documentación externa.

Solo tengo un conocimiento básico de redirigir stdout/stderr a un archivo, no mucho más, pero la pregunta probablemente se refiere a cómo está diseñado "Gnu/Linux/Kernel" para requerir redirección a

" > /dev/console" para que funcione un pitido remoto.

¿Un control remoto echo "Hello World"requiere una redirección a /dev/console?

Answer 1

echoescribe su salida en su salida estándar. Ese es su descriptor de archivo 1.

Con echo -e '\a', dependiendo de la echoimplementación, se escribirá un carácter BEL (valor de byte 0x7 en ASCII) seguido de LF (también conocido como nueva línea) o -e \aseguido de LF o -e seguido de BEL y LF.

Para escribir solo un carácter BEL, prefiere escribir printf '\a'.

De todos modos, eso no hace mucha diferencia en el núcleo de esta pregunta. printf, me gusta echoescribirá lo que tiene que escribir en su salida estándar.

Si ingresa ese comando en el indicador de un shell interactivo sin redirección, la salida estándar se heredará del shell. Si el shell fue iniciado por un emulador de terminal como xtermo screen, el descriptor de archivo 1 habrá sido abierto (por xterm) en un /dev/pt<something>archivo de dispositivo (ver lsof -ad1 -p "$$"o readlink -f /proc/self/fd/1en Linux). Ese será el lado esclavo del par pseudoterminal.

Lo único importante que hay que saber aquí es que es una especie de canal de comunicación. Un poco como una pipa, excepto que tiene algunas características más que ayudan con la interacción del usuario.

Entonces, cuando printfescribe el BEL en ese archivo de dispositivo, lo que sucede es que se transmite a algo en el otro extremo. En este xtermcaso, ese es el propio emulador de terminal. El carácter BEL es un carácter de control que hace que el terminal y los emuladores de terminal alerten al usuario de alguna manera ( \aes para alerta). Puede ser un pitido audible, un timbre o un parpadeo visual de la pantalla o ambos. xtermnormalmente usará la XBell()llamada API X11 para eso o mostrará su ventana si se ha configurado para usar una campana visual. screenen sí mismo simplemente enviaría el BEL alanfitriónterminal(es) al que está conectado y donde esa ventana de pantalla está activa o emitir un terminaldestellosecuencia de control o "¡¡Guau, guau!!" (sic) mensaje dependiendo de cómo se configuró (ver info screen vbell).

Si inicia sesión en una PC que ejecuta Linux fuera de la sesión gráfica, fd 1 se habrá abierto (por getty) en un /dev/tty<1-...>dispositivo. Aquí, es el núcleo el que implementa un emulador de terminal y utiliza el monitor para la salida y los teclados para la entrada. El mismo principio, cuando printfescribe ese BEL allí, el núcleo hace que el altavoz de la PC emita un pitido.

Cuando ejecuta ese comando en el indicador de un shell interactivo ssh, fd 1 también será un dispositivo pseudoterminal ( /dev/pt<something>), esta vez iniciado por el servidor ssh que inició el shell de inicio de sesión del usuario remoto en el sistema remoto. En el otro extremo del par de pseudoterminales se encuentra el servidor ssh. Al recibir ese BEL (o cualquier otra cosa), el servidor ssh lo envía a través de la conexión cifrada al cliente ssh, y el cliente ssh lo escribe en su salida estándar, que eventualmente llegará a la ventana de terminal en la que se encuentra. en.

En

printf '\a' > /dev/console

El shell abre el /dev/consolearchivo en el descriptor de archivo 1 (stdout) antes de ejecutar printf.

Ahora /dev/console, al menos en Linux, es el archivo de dispositivo tty el que está destinado a recibir mensajes del sistema. /dev/consolenormalmente redirige a otro dispositivo tty. En la PC, de forma predeterminada, eso es /dev/tty0lo que apunta a la terminal virtual actualmente activa, pero eso se puede cambiar en el momento del arranque usando el console=/dev/anythingparámetro del kernel (por ejemplo, console=/dev/ttyS0para convertirlo en el primer dispositivo serie), e incluso se puede cambiar (para la salida parte) más adelante, utilizando el TIOCCONS ioctl()(ver xterm -C).

En cualquier caso, será un terminal que normalmente está conectado a la propia máquina. Entonces, generar un BEL allí tiene como objetivo alertar al administrador de esa máquina ya que está usando el canal utilizado para enviar mensajes del sistema al usuario.

Para escribir un mensaje a todos los usuarios que han iniciado sesión, también puede utilizar la wallaplicación, o la writeaplicación a un solo usuario (un dispositivo terminal), siempre que esos usuarios no hayan desactivado esas notificaciones (con mesg n)