Primeiro, cat grava na saída padrão, que não é necessariamente um terminal, mesmo que cat tenha sido digitado como parte de um comando em um shell interativo. Se você realmente precisa de algo para gravar no terminal mesmo quando a saída padrão é redirecionada, isso não é tão fácil (você precisa especificar qual terminal, e pode não haver um se o comando for executado a partir de um script), embora poderia (ab) usar a saída de erro padrão se o comando for meramente uma parte de um pipeline. Mas desde que você indicou que cat realmente faz o trabalho, eu suponho que você não estava perguntando sobre tal situação.
Se o seu propósito fosse enviar o que está escrito para a saída padrão em um pipeline, então usar cat seria elegível para o Uso inútil do Cat Award , já que cat file | pipeline (onde pipeline representa qualquer pipeline) pode ser feito com mais eficiência como <file pipeline . Mas, novamente, a partir do seu texto, deduzo que essa não era sua intenção.
Portanto, não é tão claro com o que você está se preocupando. Se você achar cat muito longo para digitar, você pode definir um alias de um ou dois caracteres (ainda existem alguns nomes que permanecem sem uso no Unix padrão). Se no entanto você está se preocupando
que cat está gastando ciclos inúteis, você não deveria.
Se houvesse um programa null que não aceita argumentos e apenas copia a entrada padrão para a saída padrão (o objeto neutro para pipelines), você poderia fazer o que quiser com <file null . Não existe tal programa, embora seja fácil escrever (um programa C com apenas uma função main de uma linha pode fazer o trabalho), mas chamando cat sem argumentos (ou cat - se você gosta de ser explícito) faz exatamente isso.
Se houvesse um programa nocat que pegasse exatamente um argumento de nome de arquivo, tentasse abrir o arquivo, reclamasse se não pudesse e continuasse copiando do arquivo para a saída padrão, então seria exatamente o que você é pedindo por. É apenas um pouco mais difícil de escrever do que null , o trabalho principal é abrir o arquivo, testar e possivelmente reclamar (se você for meticuloso, também pode incluir um teste que exija apenas um argumento e queixar-se do contrário) . Mas novamente cat , agora fornecido com um único argumento, faz exatamente isso, então não há necessidade de nenhum programa nocat .
Uma vez que você tenha conseguido escrever o programa nocat , por que parar em um único argumento? Embrulhar o código em um loop for(;*argp!=NULL;++argp) não é realmente nenhum esforço, adiciona no máximo duas instruções de máquina ao binário e evita ter que reclamar de um número errado de argumentos (o que poupa muito mais instruções). Voilà uma versão primitiva de cat , concatenando arquivos. (Para ser honesto, você precisa ajustá-lo um pouco para que, sem argumentos, ele se comporte como null .)
Claro que no programa cat real, eles adicionaram alguns sinos e assobios, porque eles sempre fazem. Mas a essência é que o aspecto de "concatenação" de cat não custa realmente nenhum esforço, nem para o programador nem para a máquina que o executa. O fato de cat incluir null e nocat explica a inexistência de tais programas. Evite usar cat com um único argumento se o resultado entrar em um pipeline, mas se for usado apenas para exibir o conteúdo do arquivo no terminal, até mesmo a página que eu associei para admitir que esse é um uso útil de cat , não hesite.
Você pode testar que cat é realmente implementado por um simples loop em torno de uma funcionalidade nocat , chamando cat com vários nomes de arquivos, entre eles um nome inválido, não na primeira posição: em vez de reclamar direito embora esse arquivo não exista, cat primeiro copia os arquivos válidos anteriores e depois reclama do arquivo inválido (pelo menos é assim que meu gato se comporta).