Stéphane Chazelas's questions

Ao escrever esta resposta para outra pergunta e resposta aqui , percebi que o tempo na solução zsh que usa select()para dormir por um determinado número de centissegundos estava errado em uma quantidade maior do que eu esperava.

Parece que está select()no meu sistema, cujo tempo limite parece ter um desvio consistente, como se seus segundos valessem 1.001 segundos normais.

$ strace -qqTe /select zsh -c 'zmodload zsh/zselect; zselect -t 6000'
pselect6(0, 0x7ffcee6a9f60, 0x7ffcee6a9fe0, 0x7ffcee6aa060, {tv_sec=60, tv_nsec=0}, NULL) = 0 (Timeout) <60.058930>
$ strace -qqTe /select zsh -c 'zmodload zsh/zselect; zselect -t 600'
pselect6(0, 0x7ffcf2042b70, 0x7ffcf2042bf0, 0x7ffcf2042c70, {tv_sec=6, tv_nsec=0}, NULL) = 0 (Timeout) <6.006212>

$ uname -rs
Linux 6.7.12-amd64

Veja como leva 6,006 segundos com um tempo limite de 6 segundos e 60,06 para um tempo limite de 60 segundos.

Observo o mesmo em hardware diferente e no Ubuntu 22.04 com Linux 6.5.0.

O mesmo com perlem vez de zsh:

$ strace -qqTe /select perl -e 'select undef,undef,undef,60'
pselect6(0, NULL, NULL, NULL, {tv_sec=60, tv_nsec=0}, NULL) = 0 (Timeout) <60.060218>

E o mesmo com poll() em vez de select():

$ strace -qqTe /poll perl -MIO::Poll -e 'IO::Poll->new()->poll(6)'
poll([], 0, 6000)                       = 0 (Timeout) <6.006215>
$ strace -qqTe /poll perl -MIO::Poll -e 'IO::Poll->new()->poll(60)'
poll([], 0, 60000)                      = 0 (Timeout) <60.060214>

Isso não parece se aplicar a clock_nanosleep()or alarm().

Esse é um problema conhecido? Isso é possivelmente intencional?

Estou acompanhando a configuração de algum sistema no formato JSON em um sistema de controle de revisão.

Infelizmente, essa configuração é recuperada usando algum comando proprietário de código fechado, e a saída muda de uma execução para a próxima, pois a ordem nos objetos e matrizes é mais ou menos aleatória.

Uma vez, ele produzirá:

{
  "fru": [
    {
      "name": "foo",
      "attr": [
         {"name": "colour", "value": "blue"},
         {"name": "length", "value": 12}
      ]
    },
    {
      "name": "bar",
      "attr": [
         {"name": "colour", "value": "red"},
         {"name": "length", "value": 1}
      ]
    }
  ],
  "tags": ["x", "y"]
}

E da próxima vez:

{
  "tags": ["y", "x"],
  "fru": [
    {
      "name": "bar",
      "attr": [
         {"name": "length", "value": 1},
         {"name": "colour", "value": "red"}
      ]
    },
    {
      "name": "foo",
      "attr": [
         {"name": "colour", "value": "blue"},
         {"name": "length", "value": 12}
      ]
    }
  ]
}

Isso significa que, do ponto de vista de git diff, tudo muda de uma execução para outra, mesmo que seja exatamente o mesmo sistema.

Em todas as matrizes, a ordem não é relevante. A ordem também não importa nos atributos dos objetos. Então, se eu pudesse pós-processar essa saída para que os objetos e arrays tivessem seus atributos e membros em uma ordem consistente, eu garantiria que a saída não mudaria quando o sistema não mudasse e as mudanças vistas por git diffseriam mais provavelmente refletirá as mudanças no sistema.

jq -Sme ajuda bastante:

• classificando atributos dentro de objetos
• colocar atributos de objetos separados e membros da matriz em linhas separadas ( git diffé baseado em linhas).

Para o exemplo acima, isso me dá:

{
  "fru": [
    {
      "attr": [
        {
          "name": "colour",
          "value": "blue"
        },
        {
          "name": "length",
          "value": 12
        }
      ],
      "name": "foo"
    },
    {
      "attr": [
        {
          "name": "colour",
          "value": "red"
        },
        {
          "name": "length",
          "value": 1
        }
      ],
      "name": "bar"
    }
  ],
  "tags": [
    "x",
    "y"
  ]
}

E:

{
  "fru": [
    {
      "attr": [
        {
          "name": "length",
          "value": 1
        },
        {
          "name": "colour",
          "value": "red"
        }
      ],
      "name": "bar"
    },
    {
      "attr": [
        {
          "name": "colour",
          "value": "blue"
        },
        {
          "name": "length",
          "value": 12
        }
      ],
      "name": "foo"
    }
  ],
  "tags": [
    "y",
    "x"
  ]
}

Isso é melhor, mas ainda não está lá, pois os arrays não estão classificados (compreensivelmente).

Observe que o arquivo da vida real é mais complexo com arrays contendo outros arrays de objetos contendo mais arrays...

Meu pensamento para resolver isso é classificar todas as matrizes, começando pelas mais profundas com base na representação da string JSON dos valores, por exemplo, .fru[0].attrclassificada com {"name": "colour", "value": "blue"}antes {"name": "length", "value": 12}porque a {"name":"colour","value":"blue"}string é classificada antes do comprimento um e, em seguida, a .frumatriz classificada com fooantes barporque {"attr":[..."blue"...(com o attratributo movido antes nameem ordem alfabética) é classificado antes {"attr":[..."red"....

Posso obter os caminhos de todos os arrays, primeiro a profundidade com:

$ jq -c '[paths(arrays)]|reverse' a
[["tags"],["fru",1,"attr"],["fru",0,"attr"],["fru"]]

Posso classificar uma matriz com base na representação da string JSON de seus membros com:

jq '.array|=sort_by(tojson)'

Mas como combinar os dois para aplicar o segundo a todos os arrays retornados pelo primeiro?

Ou existe uma maneira melhor de pós-processar esse JSON para que o pedido permaneça consistente?

Se jqnão for a melhor ferramenta para isso, ficarei feliz em considerar os módulos perldo JSONou os equivalentes Ruby/python.

$ seq 10 | unbuffer -p od -vtc
0000000   1  \n   2  \n   3  \n   4  \n   5  \n   6  \n   7  \n   8  \n

Para onde foi 9e 10foi?

$ printf '\r' | unbuffer -p od -An -w1 -vtc
  \n

Por que foi \ralterado para \n?

$ : | unbuffer -p printf '\n' | od -An -w1 -vtc
  \r
  \n
$ unbuffer -p printf '\n' | od -An -w1 -vtc
  \r
      \n

O que é isso?

$ printf foo | unbuffer -p cat
$

Por que nenhuma saída (e um atraso de um segundo)?

$ printf '\1\2\3foo bar\n'  | unbuffer -p od -An -w1 -vtc
$

Por que não há saída?

$ (printf '\23'; seq 10000) | unbuffer -p cat

Por que ele trava sem saída?

$ unbuffer -p sleep 10

Por que não consigo ver o que digito (e por que é descartado mesmo sleepsem ter lido)?

Aliás, também:

$ echo test | unbuffer -p grep foo && echo found foo
found foo

Como foi grepencontrado foo, mas não imprimiu as linhas que o contêm?

$ unbuffer -p ls /x 2> /dev/null
ls: cannot access '/x': No such file or directory

Por que o erro não foi para /dev/null?

Veja também Unbuffer convertendo todos os caracteres em sino?

$ echo ${(l[10000][foo])} | unbuffer -p cat | wc -c
4095

Isso é com:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux trixie/sid
Release:        n/a
Codename:       trixie
$ uname -rsm
Linux 6.5.0-3-amd64 x86_64
$ expect -c 'puts "expect [package require Expect] tcl [info patchlevel]"'
expect 5.45.4 tcl 8.6.13
$ /proc/self/exe --version
zsh 5.9 (x86_64-debian-linux-gnu)

O mesmo no Ubuntu 22.04 ou no FreeBSD 12.4-RELEASE-p5 (exceto que os odcomandos precisam ser adaptados lá, e eu recebo 2321 (todos os caracteres BEL lá) em vez de 4095 acima).