Eu uso < /dev/console quando executo programas Cobol da Micro-Focus em tarefas agendadas em segundo plano em vez de < /dev/null , porque então não recebemos um aviso sobre o arquivo de entrada que não suporta ioctl. O aviso sobre o arquivo de entrada não suportando ioctl significa que o script não é capaz de diferenciar entre este e um erro real, pois o programa retorna o mesmo valor.
Geralmente (em muitos servidores AIX diferentes) eu configuro esses jobs para serem executados como root porque outros usuários não têm permissões para ler /dev/console .
Ao longo de vários anos, tive vários problemas que simplesmente não entendi, e pesquisar na internet por muitas horas não ajudou. Por exemplo,
um servidor foi alterado, sem motivo aparente, de onde apenas o root poderia usar < /dev/console para onde apenas um usuário não-root poderia usar < /dev/console
um servidor em que um usuário não raiz pôde usar < /dev/console alterado após a reinicialização, para que somente o root pudesse usar < /dev/console
O segundo exemplo é o meu caso mais recente.
lscons mostra que o console está atribuído a /dev/tty0 e você pode efetuar login em /dev/tty0 fine.
Eu não acho que alguém tenha usado swcons ou chcons para reatribuir o console antes da reinicialização.
Eu tentei alterar as permissões em /dev/console & /dev/tty0 to 666 mas ainda apenas o root pode fazer, sem erro:
echo TEST < /dev/console
Alguém entende o que está acontecendo ou sabe como alterá-lo para que usuários não-root possam ler /dev/console ?
Alguma sugestão para outro dispositivo que suporte ioctl e pode ser usada como um stdin falso por usuários não-root?
(Eu suspeito que o programa cobol só abre stdin, mas não o lê realmente quando está em segundo plano).
Permissões agora:
crw-rw-rw- 1 sistema radicular 4, 0 20 de agosto 1999 / dev / console
crw-rw-rw- 1 root system 16, 0 Aug 09 13:39 / dev / tty0
Antes de eu: chmod 666 :
crw - w - w - 1 sistema radicular 4, 0 20 de agosto 1999 / dev / console
crw ------- 1 root system 16, 0 Aug 09 13:39 / dev / tty0