Propor descritor de arquivo adicional “stdmeta” [closed]

Question

Eu sei que é possível definir descritores de arquivos adicionais para uso ad-hoc. No entanto, vejo o uso real de um descritor de arquivo "stdmeta" que seria suportado por ferramentas comuns de CLI. Este descritor de arquivo teria linhas de saída que não fazem parte dos dados e ainda são não erros . Como alguém poderia propor tal adição ao Unix ou ao Linux?

Um exemplo de uso seria a saída dos cabeçalhos de comandos como ps:

$ ps
  PID TTY          TIME CMD
 6394 pts/15   00:00:00 bash
10294 pts/15   00:00:00 ps
10295 pts/15   00:00:00 bash

Se alguém quisesse classificar, grep ou filtrar essa saída, seria necessário perder o cabeçalho ou misturá-lo nos dados. Isso pode ser contornado por redirecionando a primeira linha para o stderr , ou um miríade de diferentes soluções criativas , mas é óbvio que todas são desajeitadas ad-hoc e difíceis de lembrar de soluções alternativas para o fato de que não há um descritor de arquivo stdmeta dedicado.

Outro exemplo é a saída de curl . Curva canaliza metadados para o stderr para que possa informar os humanos sobre o progresso sem adicionar complexidade às aplicações para as quais pode ser canalizada sua saída. Novamente, este é o uso de stderr como um substituto para o stdmeta ausente.

Devo apenas escrever para o LKML e declarar meu caso? Como isso quebraria a compatibilidade com alguns aplicativos herdados do Unix, deveria direcionar meu caso para um corpo mais Unixy?

    

Answer 1

Sua proposta de captura de metadados em stdmeta parece ser simplesmente para que você possa descartá-la em favor de dados "reais" que aparecem em stdout de maneira consistente. (Não necessariamente um requisito ruim em uma situação de campo verde.)

Em um nível prático, os programas são codificados para lidar com stdout e stderr . Se você fosse criar um novo stdmeta que fizesse parte dos dados normalmente enviados para um dos descritores existentes, você poderia facilmente quebrar muitas coisas mal. Considere sua proposta com ps -ef e código herdado que fez algo como ps -ef | sed 1d | ... . Se você não enviar mais o cabeçalho por meio de stdout , mas enviá-lo para stdmeta , esse código se comportará incorretamente.

Parece-me que você seria melhor com um sinalizador -q (para saída silenciosa) disponível em todos os utilitários. Mas mesmo isso está repleto de dificuldades quando você considera que praticamente todos os scripts que entendiam seus utilitários poderiam usar -q teriam que lidar com versões mais antigas desses mesmos utilitários que não o faziam.