Re: [shell-script] redirecionamento ou TMOUT

[Felipe Kellermann]

On Tue, 30 Aug 2005 11:51am  -0700, moysespr wrote:

> Tenho problemas usando o cat lendo filedescriptors com conexões TCP.
> Já consegui reduzir muito o problema lendo o header HTTP com o read do 

Oi Moyses,

Muito legal tua mensagem.

Fiz correcoes na bash3 para casos parecidos. Uso de operacoes bloqueantes 
ou nao, exclusivas ou nao. Teu caso fica mais especificamente no primeiro.
<URL: http://fk.geek42.org/bash-3.0.14-lock.patch>

A shell Bash, infelizmente, nao prove alguns mecanismos de programacao 
relativamente comuns. Veja sobre a possibilidade de usar zsh para esses 
casos. Tu vai poder utilizar inclusive interfaces de select(2), etc.


> Contornei isso há algum tempo usando o read para ler tudo, inclusive 
> arquivos binários. O problema é que o read é uma opção muito mais lenta 
> e agora não é mais adequado devido ao maior número de transferências 
> binárias.

Faz sentido mesmo...


> 1. é possível redirecionar os dados recebidos de um fd para a saída de
> outro, sem usar um programa externo como, cat, dd, head, etc.,
> algo do tipo:  "<&3 >&1".

Depende. Tu ta usando Bash? Precisa ser Bash? Troque de shell, mude para 
zsh, e a resposta vai ser, "sim":

% uname -a > uname
% < uname > sistema
% < sistema
OpenBSD orchid.nyvra.org 3.7 GENERIC#50 i386
%

Adicionalmente:

% uname -a > uname
% exec 3<uname
% exec 4>sistema
% <&3 >&4
% < sistema
OpenBSD orchid.nyvra.org 3.7 GENERIC#50 i386
%


> Isto acho que poderia ser testado com um arquivo:
>  $ <a >b  # ou algo parecido; eu ainda não achei o caminho

Por padrao, shell nao tem essa funcionalidade. Bash nao tem nenhuma opcao 
para permitir isso, infelizmente. Uma funcionalidade basica e fundamental 
quando nos deparamos com esses casos, muito comum, etc.


> 2. considero que solução à questão 1 poderia resolver, pois imagino que
> a variável TMOUT interromperia essa leitura se ela fosse exclusivamente
> via shell, embora talvez à custa da execução do próprio script (tolerável)

Nao consegui interpretar muito bem...


> 3. já pesquisei, mas não percebi como, ou se é possível, usar um trap para
> matar um binário que não mais responde e que foi chamado pelo shell

Se ele nao responde, foi porque bloqueou.
Resolvi os bloqueios na bash com aquela modificacao...


> 4. existe algum programa muito pequeno, ao estilo do cat, que possua 
> timeout?
> 

Muito boa a pergunta. Eu nao conheco.
Vou pesquisar. Talvez algum dd "extended"? Vamos ver...

> Detalhe: o script roda em um 486 com 8MB de memória, e não quero me dar
> ao luxo de ter outro processo para controlar a conclusão dessa tarefa.

Ja pensou em usar BusyBox?
Eu uso um 486 como roteador, com 4 placas de rede, e uso BusyBox/uClibc e 
uso ash como shell e nc quando preciso de sockets simples. O que acha?


> PS.: ocorria um problema parecido com o exec no estabelecimento da conexão
> TCP, mas esse nunca mais apareceu usando o bash 3.x .

Sim, sao bloqueantes.
Aquele meu patch resolve.

-- 
Felipe Kellermann