Re: Inserir quebra de linha a cada N repetições de um padrão.

[itamarnet]

Rodrigo,

Mais uma vez me intrometo, mas me permita fazer algumas considerações.

Eu também tenho muito trabalho com interfaces em sistemas heterogêneos, legados e de SO diferentes que geram inúmeros problemas por isso sou meio calejado.

As dicas em SED são ótimas, mas pecam por não prever uma inconstância no formato da informação, da maneira como foi colocada. Até acredito que levando em consideração isso possam atender plenamente a solicitação.

Com relação a demora o SED usa o conceito de "PATTERN SPACE", que é como carregar em memória cada linha antes de tratar, assim como existe também o "HOLD SAPCE" e nisso acho que o Júlio pode explicar com maior desenvoltura.

Lembra-se que na primeira dica deixei em aberto mudar a quantidade de registros a ser agrupada (i%5==0 por i%3==0 por exemplo)? Nesse caso é que eu já considerava a não uniformidade dos registros originais, dando-le a liberdade de mudar.

Mas vamos considerar o último código sed:

$ sed -r "s/[^\(]*(([^\)]+\),){5})/INSERT INTO 'TABLE' VALUES \1;\n/g; s/,;/;/g" teste_sp.sql

Com esse código, o problema que vc viu no último registro está se repetindo em todos os registros, mesmo os que tem múltiplos de 5. E porque disso?

A explicação está nesse bloco: [^\(]*(([^\)]+\),){5})

Em resumo esse bloco seleciona um conjunto de 5 registros seguido de vírgula(,). E sob essa ótica não seleciona os registros finais, pois terminam com ponto-e-vírgula(;)

Se acaso o bloco fosse alterado para:  [^\(]*(([^\)]+\)[,;]){5})

Ainda assim ia falhar, pois apenas atenderia as linha com registros múltiplos de 5.

Por isso apareceram linhas com registros, mas sem a instrução "insert" no começo.

Pode verificar, que existem mais linhas, não apenas a final, com essa ocorrência.

Se acaso mudar para:  [^\(]*(([^\)]+\)[,;]){1,5}) não sei se o efeito seria bom, pois poderia haver repetição de registros. Esse é um caso que fico em dúvida, e precisaria testar e verificar mais.

Obs. 1: Essa última construção sem pipe possibilitou ver onde a substituição ocorria. Quando era com o pipe a instrução "insert" era colocada em todos e esses problemas não ocorrem. Então acho que no caso a melhor opção é usar um segundo SED.

Obs 2: A última linha gerada apenas com "insert", na versão com pipe, é porque há uma linha final em branco e o segundo sed coloca para todas as linhas resultantes, mesmo linhas vazias

Já o código em AWK, prevê essa variação da quantidade de campos em cada registro original e onde não há campos simplesmente não "printa".

Desculpe o longo e-mail, apenas quis destrinchar o problema. Não sei se foi a melhor abordagem e nem sei se está 100% certo, então qualquer observação ou correção é bem vinda sempre.

[]'s

Itamar