posted by Mikhail E. Zakharov on Tue 21st Jun 2005 17:26 UTC

"Unix scripts, Page 3/4"

To avoid it and return telnet its traditional behavior let's start telnet with the -K option:

$ telnet -K localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.

FreeBSD/i386 (unity) (ttyp1)

login:				<-- server waits for login, no new-line printed by server

So let our first script ( consist of the following lines:


mkfifo in.fifo
mkfifo out.fifo

telnet -K localhost > out.fifo < in.fifo 

After executing the script:

$ ./ &

we can begin our experiments. Pay attention to the & parameter which brings the script to the background. It's done for our possibility to continue working with the same terminal during the experiments. For example, let's try to read something from the out.fifo and to write something in the in.fifo:

$ cat out.fifo &

The & parameter plays the same above-mentioned role. Though, unfortunately the command cat will not show anything on the screen. Perhaps, it is caused by the blocks on reading/writing during the work with the FIFO-files: writing may be blocked till there is no one to read data from FIFO; and reading is blocked too till the other side isn't ready to write in it. May be, the whole process is hampered by our in.fifo, where there is nothing written. Let's check our guess by sending a newline symbol into the input-channel:

$ echo > in.fifo

Either our guess has been correct or the true reason lies somewhere else but the miracle has happened! The long-awaited results of the command cat out.fifo have at last appeared on the terminal:

$ Trying ::1...
Connected to localhost.
Escape character is '^]'.

FreeBSD/i386 (unity) (ttyp1)

login: login:

The only thing that is a little out of the way is the twice-repeated login:. Actually, that was the natural reaction of the telnet server on the newline symbol which was sent by echo > in.fifo command. So let's modify the command echo > in.fifo to avoid the additional newline character:

$ echo -n > in.fifo

May be, it will be even better to use the following combination:

$ cat > in.fifo &

In the future it will prevent the closing of the input stream, which is certainly interpreted by telnet server as the connection breakup.

Well, now we can go on with our research but first we must get rid of all the background processes, which were caused by using &. Now run fg command and then send ^C to finish the process:

$ fg
^C[2]  + Done                          cat out.fifo 

The next step will be an attempt to implement the main functions of expect by filtering the output (out.fifo) to find the necessary data and sending an answer:

expect request {send answer}

At first glance something like this seems suitable:

$ cat out.fifo | grep request && echo answer

Though in our case this chain won't work correctly even at the grep point. The matter is the grep is designed to print strings in accordance with the pattern. So it's quite natural that before comparing every new line with the pattern grep always waits for the end either of line ('\n') or file ('\0'). This particular feature makes it impossible to intercept "login:" with the help of the grep because "login:" isn't followed by the newline ('\n') character (the system still waits for user to enter his login-name on the same line). This is shown above on the example with telnet -K localhost. Thus grep will be waiting till the end of time for the end of line (EOL) and at last on telnet-server timeout it'll see just the end of file (EOF).

Table of contents
  1. "Unix scripts, Page 1/4"
  2. "Unix scripts, Page 2/4"
  3. "Unix scripts, Page 3/4"
  4. "Unix scripts, Page 4/4"
e p (0)    22 Comment(s)

Technology White Papers

See More