.png)
Eu aprendi que este comando:
echo -e "\a"
aciona um bipe no sistema local, enquanto este comando:
echo -e "\a" >/dev/console
dispara um bipe em um sistema remoto.
Por que é isso? O que a >/dev/consoleparte está fazendo?
Por que a execução echo -e "\a"em uma máquina remota aciona o bipe localmente e não remotamente?
Por que o comando "echo" não gosta do sudo?
Existe um esquema semelhante ao OSI-Layer? Por favor, forneça-me alguma documentação externa.
Eu tenho apenas um entendimento básico de redirecionar stdout/stderr para um arquivo, não muito mais, mas a questão provavelmente se refere a como o "Gnu/Linux/Kernel" é projetado para exigir o redirecionamento para
" > /dev/console" para que um bipe remoto funcione.
Um controle remoto echo "Hello World"requer um redirecionamento para /dev/console ?
Responder1
echograva sua saída em seu stdout. Esse é o seu descritor de arquivo 1.
Com echo -e '\a', dependendo da echoimplementação, isso irá escrever um caractere BEL (valor de byte 0x7 em ASCII) seguido por LF (também conhecido como nova linha) ou -e \aseguido por LF ou -e seguido por BEL e LF.
Para escrever apenas um caractere BEL, você prefere escrever printf '\a'.
De qualquer forma, isso não faz muita diferença para o cerne desta questão. printf, like echoescreverá o que deve ser escrito em seu stdout.
Se você inserir esse comando no prompt de um shell interativo sem redirecionamento, o stdout será herdado do shell. Se o shell foi iniciado por um emulador de terminal como xtermou screen, o descritor de arquivo 1 terá sido aberto (por xterm) em um /dev/pt<something>arquivo de dispositivo (veja lsof -ad1 -p "$$"ou readlink -f /proc/self/fd/1no Linux). Esse será o lado escravo do par pseudo-terminal.
A única coisa importante a saber aqui é que se trata de uma espécie de canal de comunicação. Um pouco como um cachimbo, exceto que possui mais alguns recursos que ajudam na interação do usuário.
Então, quando printfgrava o BEL naquele arquivo do dispositivo, o que acontece é que ele é transmitido para algo do outro lado. No xtermcaso, é o próprio emulador de terminal. O caractere BEL é um caractere de controle que faz com que o terminal e os emuladores de terminal alertem o usuário de alguma forma ( \aé para alerta). Isso pode ser um bipe audível, um sinal sonoro ou um piscar visual da tela ou ambos. xtermnormalmente usará a XBell()chamada da API X11 para isso ou exibirá sua janela se tiver sido configurada para usar uma campainha visual. screenela própria simplesmente encaminharia o BEL para ohospedarterminal(s) aos quais está conectado e onde essa janela de tela está ativa ou emite um terminalclarãosequência de controle ou "Wuff, Wuff!!" (sic) mensagem dependendo de como foi configurada (ver info screen vbell).
Se você fizer login em um PC rodando Linux fora da sessão gráfica, o fd 1 terá sido aberto (por getty) em um /dev/tty<1-...>dispositivo. Aqui, é o kernel que implementa um emulador de terminal e usa o monitor para saída e teclado(s) para entrada. Mesmo princípio, quando printfescreve aquele BEL ali, o kernel faz o alto-falante do PC apitar.
Quando você executa esse comando no prompt de um shell interativo ssh, fd 1 também será um dispositivo pseudo-terminal ( /dev/pt<something>), desta vez iniciado pelo servidor ssh que iniciou o shell de login do usuário remoto no sistema remoto. Na outra extremidade do par de pseudoterminais está o servidor ssh. Ao receber esse BEL (ou qualquer outra coisa), o servidor ssh envia isso através da conexão criptografada para o cliente ssh, e o cliente ssh grava-o em seu stdout, que eventualmente chegará à janela do terminal em que você está sentado no.
Em
printf '\a' > /dev/console
O shell abre o /dev/consolearquivo no descritor de arquivo 1 (stdout) antes de executar o printf.
Agora /dev/console, pelo menos no Linux, é o arquivo do dispositivo tty destinado a receber mensagens do sistema. /dev/consolenormalmente redireciona para outro dispositivo tty. No PC, por padrão, é isso /dev/tty0que aponta para o terminal virtual atualmente ativo, mas isso pode ser alterado no momento da inicialização usando o console=/dev/anythingparâmetro do kernel (por exemplo, console=/dev/ttyS0para torná-lo o primeiro dispositivo serial), e pode até ser alterado (para a saída parte) mais tarde, usando o TIOCCONS ioctl()(ver xterm -C).
Em qualquer caso, será um terminal normalmente conectado à própria máquina. Portanto, a saída de um BEL serve para alertar o administrador daquela máquina, pois ela está usando o canal usado para enviar mensagens do sistema ao usuário.
Para escrever uma mensagem para todos os usuários logados, você também pode usar o wallaplicativo, ou o writeaplicativo para apenas um usuário (um dispositivo terminal), desde que esses usuários não tenham desabilitado essas notificações (com mesg n)