user12280249's questions

Estou transmitindo dados usando o netcat e canalizando a saída para o gawk. Aqui está um exemplo de sequência de bytes que o gawk receberá:

=AAAA;=BBBB;;CCCC==DDDD;

Os dados incluem quase todos os caracteres arbitrários, mas nunca contêm caracteres NULL, onde =e ;são reservados para serem delimitadores. À medida que pedaços de caracteres arbitrários são escritos, cada pedaço será sempre prefixado por um dos delimitadores e sempre sufixado por um dos delimitadores, mas qualquer um dos delimitadores pode ser usado a qualquer momento: =nem sempre é o prefixo e ;nem sempre é o sufixo. Ele nunca escreverá um pedaço sem escrever também um prefixo e um sufixo apropriados. À medida que os dados são analisados, preciso distinguir qual delimitador foi usado, para que meu código downstream possa interpretar adequadamente essas informações.

Como se trata de um fluxo de rede, o stdin permanece aberto após a leitura dessa sequência, enquanto aguarda dados futuros. Eu gostaria que o gawk lesse até que qualquer delimitador fosse encontrado e, em seguida, executasse o corpo do meu script gawk com todos os dados encontrados, garantindo ao mesmo tempo que ele lida adequadamente com o fluxo contínuo de stdin. Explico isso com mais detalhes abaixo.

Até agora

Aqui está o que tentei até agora (script zsh, usando gawk, no macOS). Para este post, simplifiquei o corpo para apenas imprimir os dados - meu script gawk completo tem um corpo muito mais complicado. Também simplifiquei o fluxo do netcat para apenas catum arquivo (junto com cat'ing stdin para imitar o comportamento do fluxo).

cat example.txt - | gawk '
BEGIN {
    RS = "=|;";
}
{
    if ($0 != "") {
        print $0;
        fflush();
    }
}
'

example.txt

=AAAA;=BBBB;=CCCC;=DDDD;

Minha tentativa lida com êxito com a maioria dos dados... até o registro mais recente. Ele fica esperando por mais dados do stdin e não consegue executar o corpo do meu script para o registro mais recente, apesar de um delimitador apropriado estar claramente disponível no stdin.

Saída atual: (falha ao processar o registro mais recente de DDDD)

AAAA
BBBB
CCCC
[hang here, waiting for future data]

Resultado desejado: (processa com sucesso todos os registros, incluindo o mais recente)

AAAA
BBBB
CCCC
DDDD
[hang here, waiting for future data]

O que exatamente poderia ser a causa desse problema e como posso resolvê-lo? Reconheço que este parece ser um cenário extremo. Muito obrigado a todos pela ajuda!

Editar: consolidação de comentários, esclarecimentos diversos e várias observações/realizações

Aqui estão algumas observações diversas que encontrei durante a depuração, antes e depois de fazer esta postagem originalmente. Essas edições também esclarecem algumas dúvidas que surgiram nos comentários e consolidam as informações espalhadas por vários comentários em um único lugar. Também inclui algumas conclusões que fiz sobre como o gawk funciona internamente, com base nas informações extremamente esclarecedoras dos comentários. As informações nesta edição substituem qualquer informação potencialmente conflitante que possa ter sido discutida nos comentários.

1. Investiguei brevemente se isso poderia ser um problema de buffer de pipe imposto pelo sistema operacional. Depois de mexer na stdbufferramenta para desabilitar todo o buffer de pipe, parece que o buffer não é o problema, pelo menos não no sentido tradicional (veja o item nº 3).

2. Percebi que se o stdin estiver fechado e um regex for usado para RS, nenhum problema ocorrerá. Por outro lado, se stdin permanecer aberto e RS não for uma regex (ou seja, uma string de texto simples), também não ocorrerão problemas. O problema só ocorre se o stdin permanecer aberto e o RS for um regex. Assim, podemos razoavelmente assumir que é algo relacionado a como o regex lida com um fluxo contínuo de stdin.

3. Percebi que se meu RS com regex ( RS = "=|;";) tiver 3 caracteres... e o stdin permanecer aberto... ele para de travar depois que exatamente 3 caracteres adicionais aparecerem no stdin. Se eu ajustar o comprimento do meu regex para 5 caracteres ( RS = "(=|;)"), a quantidade de caracteres adicionais necessários para retornar do travamento será ajustada de acordo. Combinado com a discussão extremamente esclarecedora com Kaz, isso estabelece que o enforcamento é um artefato do próprio mecanismo regex. Como Kaz disse, quando o mecanismo de regex analisa RS = "=|;";, ele acaba tentando ler caracteres adicionais do stdin para ter certeza de que o regex é compatível, apesar dessa leitura adicional não ser estritamente necessária para o regex em questão, o que obviamente causa um espere no stdin. Também tentei adicionar quantificadores preguiçosos ao regex, o que em teoria significa que o mecanismo regex pode retornar imediatamente, mas infelizmente isso não acontece, pois este é um detalhe de implementação do mecanismo regex.

4. Os documentos gawk aqui e aqui afirmam que quando RS é um único caractere, ele é tratado como uma string de texto simples e faz com que RS corresponda sem invocar o mecanismo regex. Por outro lado, se RS tiver 2 ou mais caracteres, ele será tratado como uma regex e o mecanismo de regex será invocado (posteriormente colocando em jogo o problema discutido no item 3). No entanto, isso parece um pouco enganador, o que é um detalhe de implementação do gawk. Eu tentei RS = "xy";(e ajustei meus dados de acordo) e testei novamente meu experimento do nº 3. Nenhum travamento ocorreu e a saída correta foi impressa, o que deve significar que apesar de RS ter 2 caracteres, ele ainda está sendo tratado como uma string de texto simples - o mecanismo regex nunca é invocado e o problema de travamento nunca ocorre. Portanto, parece haver alguma filtragem adicional sobre se o RS é tratado como texto simples ou como regex.

5. Então... agora que descobrimos a causa raiz do problema... o que fazemos a respeito? Uma idéia óbvia seria evitar o uso do mecanismo regex... mas meu script ainda precisa corresponder a qualquer delimitador usando algum tipo de cláusula OR... então isso parece exigir a escrita de um analisador de dados personalizado como um programa C ou de outra forma. Embora eu pudesse fazer isso, e certamente resolveria o problema, mas considerando a tarefa em questão, prefiro não seguir esse caminho de ervas daninhas.

6. Isso nos leva à solução alternativa de Ed Morton, que é provavelmente o melhor caminho a seguir, ou talvez alguma pequena derivada dela. Resumindo sua abordagem abaixo:

Basicamente, use outras ferramentas CLI, ou loops de leitura de shell, ou talvez até mesmo múltiplas invocações de gawk, para fazer uma conversão antecipadamente, antes que os dados sejam fornecidos para a invocação primária do gawk. Como Ed disse, substitua cada delimitador para que todos tenham o sufixo do caractere NULL. Como isso é feito antes que o gawk veja qualquer dado, o gawk pode ser configurado para usar o caractere NULL como RS, o que seria tratado como uma string de texto simples e não como uma regex, o que significa que o problema de suspensão da regex nunca entra em jogo. A partir daí, o delimitador real e o bloco de dados podem ser decodificados e processados ​​da maneira que você desejar.

O próprio gawk pode até ser capaz de fazer conversões antecipadas... desde que cada delimitador em questão possa ser encontrado usando um RS de texto simples e não um RS regex. Tenha cuidado com delimitadores que contenham caracteres especiais para uma regex, pois isso pode fazer com que o gawk o trate como uma regex quando você não esperava.

Embora eu já tenha marcado a resposta de Ed como a solução, acho que minha solução final será um híbrido da abordagem de Ed, do insight de Kaz e de algumas realizações subsequentes que fiz graças a eles. Gostaria de poder marcar duas respostas como soluções! Obrigado a todos pela ajuda, especialmente Ed Morton e Kaz!