Depois de redirecionar o stdin de tty1 para o arquivo, o processo ainda aceita a entrada de tty1

Question

command < file é usado para redirecionar o conteúdo de um arquivo para um comando.

No terminal virtual 1 (/ dev / tty1), executo less < file . Em seguida, em outro terminal virtual, corro lsof -p <pid of the less process> e vejo a saída (aparada):

FD    name
----------------
0r    /root/file
1u    /dev/tty1
2u    /dev/tty1
3r    /dev/tty

Eu interpreto isso como:

1. stdin é / root / file. O processo só pode ler de / root / file.
2. stdout é / dev / tty1. O processo pode ler e gravar em / dev / tty1 (embora eu não saiba por que o processo precisa ler de sua própria saída ...)
3. stderr é / dev / tty1. O processo pode ler e gravar em / dev / tty1 (mais uma vez, por que o processo precisa da permissão para ler dos logs de erros que ele gera?)
4. A última linha é um fluxo não padrão. Eu não sei para que serve, mas o processo só pode ler a partir dele.

A pergunta: Mesmo que o stdin seja / root / file, ainda posso interagir com o processo less (por exemplo, digitando '/' para entrar no modo de busca e procurar por uma palavra). Isso significa que o processo ainda aceita entrada do atual terminal virtual (/ dev / tty1). Eu pensei que desde que o stdin não é / dev / tty1, eu não deveria ser capaz de interagir com o processo less por digitar no teclado?

    

Answer 1

stdin is /root/file. The process can only read from /root/file.

stdout is /dev/tty1. The process can read from and write to /dev/tty1 (though I don't know why the process needs to read from its own output...)

stderr is /dev/tty1. The process can read from and write to /dev/tty1 (again, why does the process needs the permission to read from the error logs that it outputs?)

Tanto "stdout" quanto "stderr" apontam para o mesmo objeto de arquivo, o mesmo "stdin" estava apontando antes de ser redirecionado de /root/file , a saber, /dev/tty1 . Eles foram todos obtidos por dup (2) o mesmo descritor de arquivo, e compartilhar todos suas propriedades (modos: O_RDWR , ponteiro de arquivo, etc). Você deve pensar em descritores de arquivo como índices em uma matriz de ponteiros (referência contada), onde mais de um pode apontar para a mesma estrutura. O shell não se preocupou em alterar os modos de acesso de "stdout" e "stderr" com fcntl(fd, F_SETFL, O_WRONLY) quando redirecionou stdin de file - isso seria inútil.

The last line is a non-standard stream. I don't know what it is for, but the process can only read from it.

Esse é o% que oless está usando para interação do usuário.

The question: Even though the stdin is /root/file, I can still interact with the less process (ex. typing '/' to enter search mode and search for a word). This means the process still accepts input from the current virtual terinal (/dev/tty1). I thought that since the stdin is not /dev/tty1, I should not be able to interact with the less process via typing on the keyboard?

/dev/tty é um caminho mágico que sempre abrirá o terminal de controle; no seu caso, /dev/tty e /dev/tty1 referem-se ao mesmo dispositivo (que pode ser um dispositivo virtual - um pseudo-terminal)

    

Answer 2

Você está mostrando uma situação especial. Enquanto less trabalha em um fluxo de entrada em fd 0, ele precisa de um canal de entrada para interagir com o usuário. Então ele abre outro arquivo, aqui fd 3, para ler do teclado. Isso definitivamente em não stdin. Aparte (memórias ...): No OpenVMS por DEC eles - por padrão - diferenciaram entre SYS $ INPUT e SYS $ COMMAND, que meio que reflete a situação apresentada ...