gawk trava ao usar um regex para RS combinado com a leitura de um fluxo contínuo de stdin

Awk está aguardando a delimitação do registro. Um registro será delimitado quando duas coisas acontecerem: houver uma correspondência para a RSregex ou a entrada terminar.

Você também não forneceu, porque usou cat <file> -, o que significa que cato fluxo de saída continua com a entrada padrão (seu TTY) depois de <file>esgotado.

Você deve usar Ctrl-Duma linha vazia para gerar a condição EOF necessária que o Gawk está procurando.

Editar:

A questão é: por que o último registro não aparece mesmo sendo delimitado pelo final =?

Este comportamento se reproduz exatamente em uma implementação do Awk que escrevi como uma macro em uma linguagem Lisp, lado a lado com o GNU Awk.

$ (echo -n 'AAAA=AAAA;AAAA;AAAA='; cat) | gawk 'BEGIN { RS = "=|;"; } { print $0; fflush(); }'
AAAA
AAAA
AAAA
# hangs here until Ctrl-D, then:
AAAA

Exatamente a mesma coisa:

$ (echo -n 'AAAA=AAAA;AAAA;AAAA='; cat) | txr -e '(awk (:set rs #/=|;/) (t))'
AAAA
AAAA
AAAA
# hangs here until Ctrl-D, then:
AAAA

No caso da segunda implementação do Awk, como escrevi tudo do zero, inclusive o motor regex, posso explicar o comportamento daquilo que forma uma hipótese sobre por que o Gawk é o mesmo.

A leitura delimitada por regex é baseada em uma função escrita em C chamada read_until_matchque é um wrapper para um auxiliar chamado scan_until_common. Esta função funciona alimentando caracteres um por um do fluxo em uma máquina de estado regex, verificando o estado.

É o seguinte. Quando a máquina de estado regex diz "temos uma correspondência!" não podemos parar por aí. A razão é que precisamos encontrar a correspondência mais longa.

A função não sabe que a regex é uma regex trivial de um caractere, para a qual a primeira correspondência já é a correspondência mais longa. Portanto, precisa alimentar mais um caractere da entrada. Nesse ponto, a máquina de estado regex diz “fail!”. A função então sabe que houve uma correspondência bem-sucedida anteriormente. Ele volta a esse ponto, empurrando o personagem extra de volta ao fluxo.

Então, é claro, se não houver nenhum próximo caractere disponível no fluxo, teremos um travamento de bloqueio de E/S.

O motivo pelo qual tem que funcionar dessa maneira é que algumas expressões regulares correspondem com êxito aos prefixos da correspondência mais longa. Um exemplo trivial é: suponha que tenhamos #+como delimitador. Quando um #é visto, combina! Mas quando outro #é visto, isso também combina! Temos que ver todos os #caracteres para obter a correspondência completa, o que significa que temos que ver o primeiro caractere não correspondente que se segue.

O GNU Awk não pode facilmente escapar de fazer algo muito semelhante; a teoria exige isso.

Uma maneira de resolver o problema seria ter uma função maxmatchlen(R)que, para uma regex, Rreportasse o comprimento máximo da correspondência para a regex (possivelmente infinita). maxmatchlen(/.*/)é Inf, mas matchmatchlen(/abc/)é 3. Você entendeu. Com esta função, saberíamos que se acabamos de alimentar os matchmatchlencaracteres regex e a máquina de estado regex está relatando um estado correspondente, terminamos; não precisamos olhar para frente, para o fluxo.

Uma solução alternativa para inserir um loop de leitura do shell no pipeline para dividir a entrada original do awk (a netcatsaída real do OP) em caracteres individuais e, em seguida, alimentá-los para o awk, um de cada vez:

cat example.txt - |
while IFS= read -r -d '' -N1 char; do printf '%s\0' "$char"; done |
awk -v RS='\0' '
    /[;=]/ { if (rec != "") { print rec; fflush() }; rec=""; next }
    { rec=rec $0 }
'
AAAA
AAAA
AAAA
AAAA

Isso requer GNU awk ou algum outro que possa lidar com um NULcaractere como RSse fosse um comportamento não-POSIX. Ele assume que sua entrada não pode conter bytes NUL, ou seja, é um "arquivo" de texto POSIX válido.

Continue lendo para saber como chegamos lá, se estiver interessado...

Achei que havia pelo menos um bug aqui, pois encontrei várias esquisitices (veja abaixo), então abri um relatório de bug em https://lists.gnu.org/archive/html/bug-gawk/2024-07/msg00006. html , mas de acordo com o provedor gawk, Arnold, as diferenças de comportamento neste caso são apenas detalhes de implementação de ter que ler adiante para garantir que o regexp corresponda à string correta.

Parece que há três problemas em jogo aqui, por exemplo, usando GNU awk 5.3.0 no cygwin:

1. Diferentes expressões regulares supostamente equivalentes produzem comportamentos diferentes:

$ printf 'A;B;C;\n' > file

$ cat file - | awk -v RS='(;|=)' '{print NR, $0}'
1 A

$ cat file - | awk -v RS=';|=' '{print NR, $0}'
1 A
2 B

$ cat file - | awk -v RS='[;=]' '{print NR, $0}'
1 A
2 B
3 C

(;|=), ;|=e [;=]devem ser equivalentes, mas claramente não são neste caso.

A boa notícia é que aparentemente você pode contornar esse problema usando uma expressão entre colchetes como no terceiro caso acima, em vez de um "ou".

2. O registro de saída segue o registro de entrada quando o caractere separador de registro é o último na entrada, por exemplo, sem nova linha após o último ;:

$ printf 'A;B;C;' > file

$ cat file - | awk -v RS='(;|=)' '{print $0; fflush()}'

$ cat file - | awk -v RS=';|=' '{print $0; fflush()}'
A

$ cat file - | awk -v RS='[;=]' '{print $0; fflush()}'
A
B

A má notícia é que isso afeta o exemplo dos OPs:

$ printf ';AAAA;BBBB;CCCC;DDDD;' > file

Com um caractere literal RS:

$ cat file - | awk -v RS=';' '{print $0; fflush()}'

AAAA
BBBB
CCCC
DDDD

Com um RS regexp que também deve tornar esse char literal:

$ cat file - | awk -v RS='[;]' '{print $0; fflush()}'

AAAA
BBBB
CCCC

$ printf ';AAAA;BBBB;CCCC;DDDD;x' > file

$ cat file - | awk -v RS='[;]' '{print $0; fflush()}'

AAAA
BBBB
CCCC
DDDD

3. Adicionar caracteres diferentes à expressão entre colchetes RS produz um comportamento inconsistente (deparei com isso por acidente):

$ printf 'A;B;C;\n' > file

$ cat file - | awk -v RS='[;|=]' '{print $0; fflush()}'
A

$ cat file - | awk -v RS='[;a=]' '{print $0; fflush()}'
A
B
C

FWIW, tentei definir um tempo limite:

$ cat file - | awk -v RS='[;]' 'BEGIN{PROCINFO["-", "READ_TIMEOUT"]=100} {print $0; fflush()}'
A
B
awk: cmd. line:1: (FILENAME=- FNR=3) fatal: error reading input file `-': Connection timed out

$ cat file - | awk -v RS='[;]' -v GAWK_READ_TIMEOUT=1 '{print $0; fflush()}'
A
B

e stdbuf para desativar o buffer:

$ cat file - | stdbuf -i0 -o0 -e0 awk -v RS='[;]' '{print $0; fflush()}'
A
B

e combinando todos os caracteres (pensando que poderia usar RT ~ /[=;]/para encontrar o separador):

$ cat file - | awk -v RS='(.)' '{print RT; fflush()}'
A
;
B
;
C

mas nenhum deles me permitiu ler o último separador de registro, então neste momento não sei o que o OP poderia fazer para ler com êxito o último registro de entrada contínua usando um regexp diferente de algo assim:

$ printf 'A;B;C;' > file

$ cat file - |
    while IFS= read -r -d '' -N1 char; do printf '%s\0' "$char"; done |
    awk -v RS='\0' '/[;=]/ { print rec; fflush(); rec=""; next } { rec=rec $0 }'
A
B
C

e usando a entrada de amostra dos OPs, mas com texto diferente por registro para tornar mais claro o mapeamento dos registros de entrada para saída:

$ printf '=AAAA=BBBB;CCCC;DDDD=' > example.txt

$ cat example.txt - |
    while IFS= read -r -d '' -N1 char; do printf '%s\0' "$char"; done |
    awk -v RS='\0' '/[;=]/ { print rec; fflush(); rec=""; next } { rec=rec $0 }'

AAAA
BBBB
CCCC
DDDD

We're using NUL chars as the delimiters and various options above to make the shell read loop robust enough to handle blank lines and other white space in the input, see https://unix.stackexchange.com/a/49585/133219 and https://unix.stackexchange.com/a/169765/133219 for details on those issues. We're additionally using a NUL char for the awk RS so it can distinguish between newlines coming from the original input vs a newline as a terminating character being added by the shell printf, otherwise rec in the awk script could never contain a newline as they'd ALL be consumed by matching the default RS.

We're using a pipe to/from the while-read loop instead of process substitution just to ease clarity since the OP is already using pipes.

Multiple Line (Guia do Usuário GNU Awk) diz que

RS == any single character

Os registros são separados por cada ocorrência do caractere. Múltiplas ocorrências sucessivas delimitam registros vazios. (...)

RS == regexp

Os registros são separados por ocorrências de caracteres que correspondem a regexp. Correspondências iniciais e finais de regexp delimitam registros vazios.(...)

Observe que o início e o fim são mencionados apenas para o último, então suspeito que a fonte dos problemas possa ser como ele é implementado em GNU AWK.

Se você não precisa discernir entre =e ;proponho seguir a solução alternativa

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

que para example.txto conteúdo ser

=AAAA=AAAA;AAAA;AAAA=

dá saída

AAAA
AAAA
AAAA
AAAA

e trava. Explicação: adicionei GNU sedrodando em modo sem buffer ( -u) com um único ycomando que faz

Translitere quaisquer caracteres no espaço padrão que correspondam a qualquer um dos caracteres de origem com o caractere correspondente em caracteres de destino.

Neste substitui ;usando =. Em seguida, alterei RSo gawkcomando para string de um caractere =.

(testado em GNU sed 4.8 e GNU Awk 5.1.0)

A combination of the solutions of @daweo and @EdMorton:
OP wants to have logic based on discern the two delimiters, and might want to use RT for it.
First use Ed's work-around for reading the input one character a time.
When a = is found, add a ; as a delimiter.
In awk, fix the RT when the = is part of the line.

I will print the RT after printing $0.

cat example.txt - | 
while IFS= read -r -d '' -N1 char; do
  if [[ "$char" == '=' ]]; then
    printf "=;"
  else
    printf '%s' "$char"
  fi
done  | awk '
  BEGIN {
    RS = ";"
  }
  /=/ {
        RT="=";
        sub(/=/,"", $0) 
  }
  {
    if ($0 != "") {
        print $0 "(RT=" RT ")";
        fflush();
    }
  }
'

Result:

AAAA(RT==)
AAAA(RT=;)
AAAA(RT=;)
AAAA(RT==)