Conforme visto, o
konsole é um simulador de terminais burros oriundo do sistema gráfico KDE. A linha de comunicação com cada instância de pseudoterminal aberta pelo konsole é representada por um "arquivo de dispositivo" situado dentro do diretório /dev/pts/ ; nomeado seguindo-se sequência numérica à medida que se abrem janelas terminais.
Atenção aqui recai sobre a natureza destes (pseudo)terminais: com as devidas ressalvas, cada um deles apenas coloca na tela (especificamente, em sua janela) o que lhe é enviado via respectivo arquivo de dispositivo, ou transmite à aplicação que se conecta a este arquivo o que lhe é passado (via teclado). Para que algo efetivamente ocorra na janela terminal, uma instância de algum programa de processamento deve se responsabilizar por isso. Usualmente este programa é um shell; aqui em consideração o bash. [Ref.: 36]
O bash, acrônimo par a Bourne Again Shell, é um interpretador de comandos, uma evolução muito mais interativa do Bourne Shell (sh) que, no modelo em estudo, roda junto ao "servidor", enviando e recebendo dados aos terminais aos quais se atrela (no caso um pseudoterminal do konsole) através de escritas e leituras em arquivos de dispositivo referenciados internamente em nível de instâncias do software via ponteiros conhecidos como descritores de arquivo. Um shell é um programa que intermedeia a comunicação entre o usuário e o núcleo (kernel) do sistema operacional, permitindo ao usuário dizer ao sistema o que fazer, e saber o que foi feito. Há vários shell distintos, como o csh, ksh, dash, tcsh, zsh, cada qual com sua linguagem própria. O bash é o shell padrão na maioria das distribuições
Linux atuais, a "língua franca" entre os shells por assim se dizer. [Ref.: 9]
Talvez seja de relevância antes ressaltar aqui que os terminais burros não eram todos de todo tão burros assim. Vários eram capazes de reconhecer certos comandos que, a exemplo, facilitavam a movimentação e o posicionamento do cursor pela tela, limpavam a tela, ou ativavam ou não impressoras a eles conectados para impressão de dados recebidos. Podia-se via comandos habilitar ou não a função "echo" nos terminais, mediante a qual os dados do teclado eram diretamente exibidos na tela e posteriormente enviados pela linha de comunicação, evitando que o sistema tivesse que processar e retornar o caractere digitado ao terminal para exibição (eco local e não remoto). Exibição de caracteres em cores e tonalidades de cinza também eram configuráveis via comandos enviados do sistema aos terminais. Como cada fabricante tinha seu próprio conjunto de comandos embutidos em seus terminais, o sistema operacional necessitava conhecer cada modelo de terminal com o qual se comunicava. [Ref.: 8]
Alguns conjuntos de comandos para controle de terminais, conhecidos como caracteres de escape, se padronizaram, a exemplo aquele usado nos terminais VT100 da DEC, e os definidos pela American National Standard Institue (ANSI). Banco de dados com informações de modelos de terminais e seus comandos de controle foram construídos, a saber o termcap e o terminfo (ainda usado), e controles através de sequências de escape padronizadas estão presentes até hoje na maioria dos sistemas similares ao Unix modernos, incluindo-se o Linux. [Ref.: 10 | 11]
Em resumo, para estabelecer uma comunicação com um terminal, o programa que o controla deve saber com qual tipo de terminal se comunica, e não apenas o arquivo de dispositivo a usar para fazer tal comunicação; o que se aplica também ao bash.
FIGURA 03: quatro instâncias de pseudoterminal abertas, e a listagem dos diretórios /dev/fd/ e /dev/pts/, revelando os descritores de arquivos associados à janela em particular e os quatro arquivos de dispositivos cada qual associado a uma das janelas. Tanto os arquivos descritores quanto os pseudoterminais são nomeados usando-se dígitos, com as devidas limitações, em sequência numérica. [Ref.: 12]
Voltando ao ponto, para estabelecer comunicação com o mundo externo o bash, e grande parte para não dizer todos os programas no mundo Linux, possuem internamente no mínimo três ponteiros para arquivos, três descritores de arquivos, usualmente redirecionáveis. O primeiro deles, chamado de entrada padrão (stdin - standard input) aponta para o arquivo de dispositivo que proverá a entrada de dados ao programa; o segundo, nomeado stdout (standard output), aponta para o arquivo de dispositivo que receberá a saída de dados da instância, e o terceiro, stderr (standard error), aponta para o (arquivo de) dispositivo que receberá alertas e informações produzidas pela própria instância do bash ou rotina em execução.
Seguindo a regra, cada instância do bash mantém internamente uma tabela com vários descritores de arquivos, cada qual numericamente nomeado. Ao inicializar, por padrão, stdin será conectado ao arquivo apontado pelo descritor "0"; stdout será conectado ao arquivo indicado no descritor "1" e stderr àquele indicado no descritor "2" da tabela de descritores, ou seja, stdin é o arquivo referenciado no descritor 0; stdout o referenciado no descritor 1, e stderr é direcionado ao arquivo referenciado no descritor 2. [Ref.: 9 |13]
A tabela de descritores pode aumentar ou diminuir dinamicamente, ou por vontade do usuário via comandos destinados a tal fim ou por necessidade em execução de rotinas, a exemplo quando coprocessos são gerados pelo bash. Os canais stdin, stdout e stderr também podem ser redirecionados a outros arquivos, transferindo a entrada e saídas da instância a arquivos diferentes dos originais. [Ref.: 9]