Com screen rola, você pode até jogar a saida para o syslog *.* /dev/device
2009/4/22 Fernando Gottlieb <[email protected]> > > > Olá Reinaldo. > Agradeço imensamente sua explicação. > Posso concluir que, infelizmente, shell não será a melhor solução. > Estou encerrando este tópico para não se tornar off e não prejudicar o > andamento da lista. > Entrarei em contato com vc diretamente para dar continuidade ao assunto. > > Abraços > > Fernando A. Gottlieb > > 2009/4/21 Reinaldo de Carvalho <[email protected]<reinaldoc%40gmail.com> > >: > > > > > > > 2009/4/20 Alain M. <[email protected] <alainm%40pobox.com>>: > > > >> provavelmente você abortou o picocom e deixou o lock... > >> > >> A a maioria dos recursos no Linux têm travamentos assim, enm sempre é > >> muito fácil descobrir onde os arquivos lock ficam para poder eliminálos > >> nos scripts... > >> > >> a maneira correta de sair so picocom é Control+A Ctrl+X, onde Ctrl+A é > >> chamado de Escape-char, ou seja caracter de comando, e X para Exit. pode > >> também usar picicom com --nolock > >> > >> Todos os terminais tem comandos assim.. não tem jeito porque é para > >> evitar conflito com a aplicação. > >> > >> Alain > >> > > > > Na minha opinião pode não ser questão de lock, mas de entender que um > > hardware tem estados, basicamente "lendo" e "escrevendo" sobre um > > buffer. E enquanto a operação não é concluida, ele fica ocioso. > > > > Normalmente quando o aplicativo do usuário escreve no device (no > > buffer) o hardware processa isto, e devolve uma informação ao buffer, > > ao qual pode ser lido. > > > > Mas vamos imaginar o primeiro passo, de escrita no buffer via device, > > a questão é "quando" o hardware vai processar, pode ser de caracter a > > caracter, de quebra de linha a quebra de linha, isto depende da > > especificação do hardware, e enquando esta 'trigger' não disparada o > > hardware não processará e pode não ser possível efetuar a operação de > > leitura (via cat). > > > > A questão é enquanto uma operação esta sendo realizada, o hardware > > esta aguardando uma situação que ativa o processamento. > > > > É provavel que um simples "echo > /dev/ttyUSB0" dispare o > > processamento do hardware, e possa novamente ser acesso pelo "cat", > > mas se isso não funcionar, a especificação da comunicação deve ajudar. > > > > O shell não tem recursos de alto nível para comunição com hardware, por > > exemplo: > > > > - muitos protocolos necessitam sequencias binárias, o que daria > > trabalho a mais com o 'echo'. > > > > - o cat não suporte a 'timeout' o que é necessário para identificar > > que o hardware não esta respondendo, provavelmente pois o > > processamento do buffer ainda não foi disparado, levando a escrita da > > mais códigos para esse controle > > > > Uma simulação de timeout... > > > > cat /dev/ttyUSB0 & > > bg > > i=0 > > while true; do > > jobs | grep -q cat || break > > let i++ > > if [ "$i" -eq 10 ] ; then > > killall -9 cat >/dev/null 2>&1 > > echo 'Nao pude ler do device.' > > break > > fi > > sleep 1 > > done > > > > Nesse caso, não havia nada no buffer do hardware ou o hardware não > > permitiu a leitura, tendo que tentar disparar o processado do hardware > > sobre o conteudo do buffer, que como disse, dependendo do hardware > > pode ser "echo > /dev/ttyUSB0". > > > > Na minha opinião, usar shell para interagir com hardware é muito mais > > trabalhoso do que outras linguagens que possuem funções/métodos > > disponíveis para acesso ao hardware, como python. > > > > Ps: o Júlio leu minha mente quando eu me referi ao "ps -ef". ;) > > > > -- > > Reinaldo de Carvalho > > http://korreio.sf.net > > http://python-cyrus.sf.net > > > > -- " Eu quero saber como renomear um arquivo " ele diz. Por favor, é dia de pagamento, não é?! Mas eu estou de bom humor. " Claro. Basta dar 'rm' e o nome do arquivo " " Obrigado " [As partes desta mensagem que não continham texto foram removidas]
