Por que você deve evitar formatos de entrada "estritamente colunares"?

Question

Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say at the time [McIlroy78]:

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

Dados estritamente colunares soam bem para mim, então eu provavelmente não entendo o que ele quis dizer.

O que significa e por que é ruim?

    

Answer 1

Eu suponho que ele quis dizer colunas alinhadas , não dados colunares em geral. É assim que eu entenderia o rigorosamente mesmo assim. Por exemplo:

Ruim:

1    200 3
100  3   400

Bom:

1 200 3
100 3 400

Em outras palavras, crie arquivos que sejam fáceis para os computadores lerem, não para humanos. Adicionar espaços para alinhar as coisas torna-as bonitas e fáceis para você e para mim, mas pode confundir programas que precisam analisá-las.

Por exemplo, se eu usasse cut para obter o segundo campo de cada um dos exemplos acima, ele falharia no primeiro:

$ cut -d' ' -f 2 bad


$ cut -d' ' -f 2 good 
200
3

Por causa dos espaços extras, o segundo campo do arquivo bad é um espaço. No entanto, ele funciona como esperado no arquivo good .

    

Answer 2

Estreitamente Columnar

fixed with e ordered columns vs dynamic width e headers

Exemplo

Largura fixa

nome (7 bytes) [espaço] idade (2 bytes) [espaço] altura (5 bytes)

alice   10 150cm 
bob     20 160cm
carol   30 170cm

se eu precisar adicionar agora Alexander age 40 height 180cm

alice   10 150cm 
bob     20 160cm
carol   30 170cm
Alexa~1 40 180cm

ele não se encaixa na estrutura estritamente colunar, você fica sem espaço se você usa uma estrutura colunar mais flexível

Valores separados por espaço

essa dor pode ser evitada com valores separados por espaço

alice 10 150cm 
bob 20 160cm
carol 30 170cm
Alexander 40 180cm

Space (s) Separated Values

ou um formato que divide colunas com 1 ou mais espaço

alice     10 150cm 
bob       20 160cm
carol     30 170cm
Alexander 40 180cm

como o número de espaços não importa, podemos formatar para a legibilidade humana ou para a densidade de arquivos conforme as nossas necessidades melhor ainda, aos olhos da filosofia Unix, é um formato que não força a ordem ou a presença de colunas se a primeira linha for os nomes das colunas e, em seguida, o arquivo delimitado por espaço (s) de dados

Name      Age Height
alice     10  150cm 
bob       20  160cm
carol     30  170cm
Alexander 40  180cm

com

Age Height Name      
10  150cm  alice
20  160cm  bob
30  170cm  carol
40  180cm  Alexander

tão válido quanto o primeiro Se tivermos colunas extras, não nos importamos se os cabeçalhos nos dão mais flexibilidade

Age Height t_shirt_size Name      
10  150cm  S            alice
20  160cm  M            bob
30  170cm  L            carol
40  180cm  XL           Alexander

ainda podemos ler os Name , Age e Height e simplesmente ignorar as colunas que têm cabeçalhos com os quais não nos importamos. ainda carrega no objeto

[{"Name":"alice",    "Age":10, "Height":"150cm"},
 {"Name":"bob",      "Age":20, "Height":"160cm"},
 {"Name":"carol",    "Age":30, "Height":"170cm"},
 {"Name":"Alexander","Age":40, "Height":"180cm"}]

Essas regras levam a um formato de arquivo como o CSV link

Age,Height,t shirt size,Name      
10,150 cm,S,alice
20,160 cm,M,bob
30,170 cm,L,carol
40,180 cm,XL,Alexander

evitando stringently columnar data , tornamos mais provável que o programa, ainda desconhecido, esperamos que a saída se torne a entrada para trabalhar com nosso programa não modificado.

Se meu programa coloca dados em CSV, ele pode ser lido e representado graficamente por inúmeros programas que nem sei que existem.