API para emulação de terminais

Acho que, no seu caso, o jeito é montar um “frame buffer” em memória e filtrar os caracteres e controle do VT100 (ou o terminal que vc. optar por emular). Algo parecido com que um cliente VNC faz, mas modo texto apenas.

Para descobrir o que emular, os seguintes comandos serão úteis:

man 5 terminfo --> Descrição dos campos de um descritor de terminal
infocmp vt100 --> Gera listagem “human readable” do descritor de um modelo de terminal (vt100 no caso).

Outra opção, caso disponível, é o usar o expect do para automatizar o programa remoto.

É exatamente o que eu não quero fazer no braço. Se só existisse o VT100 essa seria realmente uma boa opção, mas existem diversos tipos de terminais. Nessas horas é bom contar com uma API com caras que tenham como único objetivo na vida emular terminais. :lol:

São comandos de linux, certo? Vou dar uma checada.

Não entendi.

Para scripting basta suportar um só. Se vc. passar no environment de conexão a informação de que vc. é VT100 o aplicativo deve usá-lo (a menos que vc. queira usar alguma função avançada de terminal ). Na verdade, vc poderia até criar sua própria de definição de terminal com o mínimo que a aplicação precisa para operar (posicionamento de cursor,pex) e forçar o uso desta definição em seu teste.

Sim, são comandos (Li|U)nix., assim como o expect (man expect deve mostrar o que vc tem disponível).

Deve usa-lo desde que o suporte. O que acontece é que comunicamos com um hardware e, por ter recursos limitados, muitas vezes eles limitam os tipos de terminal disponíveis. Até hoje, sempre fomos capazes de solicitar um terminal “dumb” e ele nos atendia. Para aplicações o dumb é o mais adequado, já que só trata de bytes brutos. Nada de sequencias de escape ou códigos ascii. Sö dessa vez ele não reconheceu o comando e disse que o tipo de terminal era desconhecido. “Sorry, no cake for you”.

Também não posso afirmar que o SSH da outra ponta está rodando sobre um Linux, embora em boa parte dos casos isso seja verdade.

psevestre:

Na verdade, vc poderia até criar sua própria de definição de terminal com o mínimo que a aplicação precisa para operar (posicionamento de cursor,pex) e forçar o uso desta definição em seu teste.

Não tenho qualquer controle sobre o hardware. Só posso força-lo desde que ele suporte os terminais e, caso ele se limite a “xterm” por exemplo, eu deverei saber interpretar x-term do lado de cá.

Não sei se você entendeu, mas estou rodando comandos de SSH num script do cliente. E o que preciso é analisar a resposta do SSH. Mas já tô vendo que não vai ter jeito mesmo. Simular isso, no braço, não é uma solução viável, nem em termos de custos, não é uma atividade foco do desenvolvimento e ainda precisaríamos dar suporte disso nas versões futuras.

De qualquer forma, obrigado aí pela ajuda.

Talvez mexendo no JTA e talvez integrá-lo com o ExpectJ?

Legal o JTA. Já tinha visto essa sigla por aqui, mas ainda não conhecia o projeto.

ViniGodoy:

Legal o JTA. Já tinha visto essa sigla por aqui, mas ainda não conhecia o projeto.

Em geral, o confundem com o outro JTA

Essa aqui não é free, mas é bem completa na parte de scripting. Tive que implementar algo parecido há algum tempo, para coleta de dados via telnet. O tipo de terminal não era problema, acabei implementando na mão, da forma sugerida pelo psevestre.

Meio atrasado, mas achei mais um:

http://www.angryredplanet.com/~hackbod/java/WebTerm/download.html