It's clear another way is needed to deal with these unfinished lines. As a possibility the dd command can be used instead of cat. In circle the dd will send data character by character to the grep. I mean the following construction, which is shown in the example of already working expect.sh script:
#!/bin/sh while :; do dd if=out.fifo bs=1b count=1 2>/dev/null | grep $1 if [ $? -eq 0 ]; then # Match found echo "$2" > in.fifo exit 0 fi # Match not found, let's play again done
The script can be started in this way (files in.fifo and out.fifo should be already created):
$ ./expect.sh "request" "answer"
So the time has come to gather everything together in one script to make our traditional telnet-session work automatically:
#!/bin/sh mkfifo out.fifo in.fifo telnet -K localhost 1> out.fifo 0< in.fifo & cat > in.fifo & cat out.fifo > out.fifo & pid=`jobid` ./expect.sh "ogin" "luser" ./expect.sh "word" "TopSecret" sleep 1 echo 'who am i > /tmp/test.txt' > in.fifo sleep 1 echo "exit" > in.fifo rm out.fifo in.fifo kill $pid
After executing this script we may get, in the case of success, the following output:
$ ./test_2.sh login: Password: Connection closed by foreign host.
And as the war trophy there will appear a file /tmp/test.txt to confirm the succeeding of our experiment:
$ cat /tmp/test.txt luser ttyp3 May 10 16:39 (localhost)
But if something was wrong, the command kill may be used for each process left after the failed experiment.
Unfortunately, this script is quite unstable: it very much depends on the value of the sleep parameter and the reply speed of the telnet-server. So the data don't always come in time to be properly filtered by dd and grep it causes script hang-ups. And you must kill these processes. It's also clear that such a construction doesn't work everywhere, for example, on Linux I didn't got any acceptable results. So maybe the adepts of Linux will succeed in it.
As for me
I decided to go on and try to find a tool, which can be used as an expect-substitute for the pure shell without any superstructure as TCL, Perl or Python. I realized it must be written in C and ported for as many operating systems as possible. Well, let's google! And after some time such a program is found. It's pty-4.0 written by Daniel J. Bernstein in 1992. But as far as I can see it haven't been developed after this release.
After a while I even succeeded to compile the source code of pty-4.0 into binary executable. And some parts of it began to run. But by that moment I have realized that it's much easier to write my own program than to sort out the old one.
And why not to write? So I set about studying the problem more carefully. Before long I found out that the most convenient way to communicate with interactive applications was really to imitate a terminal for them. And the place of pseudoterminals in the structure of the future program was determined clearly enough, in spite of the contradictive mumbling of specialists from Internet about expect and PTY-sessions. Next, it also because clear that it makes everything easy to start applications under the control of the PTY-sessions inside some kind of shell, for example TCL, Perl and others. Though nothing prevent us from using C and pure sh interpreter.
As a result of all this in a couple of weeks I had a working version of empty (http://www.sourceforge.net/projects/empty) which allows to start interactive programs and communicate with them using FIFO-files. For example, the FreeBSD telnet-session in the sh-script for empty will look like that:
#!/bin/sh empty -f -i in.fifo -o out.fifo telnet -K localhost empty -w -i out.fifo -o in.fifo -t 5 "ogin:" "luser" empty -w -i out.fifo -o in.fifo -t 5 "assword:" "TopSecret" empty -s -o in.fifo 'who am i > /tmp/test.txt' empty -s -o in.fifo 'exit'
Well, it's much shorter then the buggy test_2.sh script and works quite stable on BSD, Linux and Solaris. Besides, it doesn't require TCL, Perl or Python. I admit there aren't so many functions in the program yet as there are in other expect-like tools, but I hope everything is still ahead.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.