Like it or not, but sooner or later you realize that you'll have to write shell-scripts to administer UNIX. And among these scripts there certainly will be those to cooperate with interactive applications such as telnet, ftp, su, password, ssh. But it means the end of the admin's quiet life because while dealing with interactive programs one often come across numerous hidden traps which doesn't usually happen with ordinary sh-scripts. Though fortunately or may be not, but most of these problems generally
turn up within first five minutes of the work under the script. The symptoms typically look like that author can't pass the authentication from the script. At first you feel confused because usual pipe constructions such as:
Post a Comment
Really informative article. I love pieces like this. kudos.
I didn't read the whole article, but there is autoexpect!
Yes, autoexpect is a good tool, but it is used just to automatically create TCL-expect scripts, by watching for user. So it's can be equal to writing expect-scripts by hand. The article just shows several ways to interact with programs using various languages so it doesn't go deep inside TCL or PHP or any additionl tool, like autoexpect.
Apart from some dodgy English ('let's don't' for example), it was a very well written article that helped me understand quite a big problem. One question, isn't it easy for someone to find out a password being used?
I run ssh-agent and the box that is to run the unattended script and then, in the script itself:
#!/bin/sh
. ~/bin/ssh-command
scp blah blah user@remotehost:remotedir
or
ssh remotehost command
I use this to scp my daily backups to an off-site server. Works like a charm. Of course I've only allowed RSA auth since 2002 or so. Passwords I don't trust at all.
The return of the assword!@ yay!
(Yes, I wrote too many modem chat scripts as a kid)
Well, expect has helped me a lot, especially when I have to do telnet to Ericsson PBX and get the alarm list, and process it, and put it into DB, and get it via web based app 
obviously the author mentioned avoiding perl/sh/python, but just _incase_ you are scripting in python, check out - http://pexpect.sourceforge.net/
Wow, an informative, interesting and non-inflammatory article on osnews? Whatever is the world coming to...
A nice overview of all the option available to solve the problem of automating interactive commands. I agree with the author that a sollution other than perl/python/tcl should be found because most companies just won't let you install all that just for automation.
So even though I can't use these techniques at work I've bookmarked the article for personal use.
Good to hear expect praised, right good stuff and a real buttsaver, but to fully exploit the true power of expect use TCL to manipulate it as an object, take it to the next level.
Discussing automating FTP and leave out the .netrc file?
Either you're omitting the explanation/solution on purpose, or you still have a lot to learn about shell scripting.
$ echo luser && echo TopSecret | telnet foo.bar.com
Of course this doesn't work - duh. The pipe only applies to the latter of the two echo's. Try this:
$ (echo luser && echo TopSecret) | telnet foo.bar.com
Or:
$ telnet foo.bar.com << EOF
luser
TopSecret
EOF
I absolutely agree with Anonymous (IP: ---.upc.chello.be).
The article was nice yeah, I never heard of expect before.
But the imho easiest solution he oversaw...
> $ telnet foo.bar.com << EOF
>luser
>TopSecret
>EOF
This can't work properly with almost all "telnets". Why? It was explained in the article.
> $ echo luser && echo TopSecret | telnet foo.bar.com
An error in this line has been admitted intentionally because it does not play any role. Because you example:
> $ (echo luser && echo TopSecret) | telnet foo.bar.co
taken from classical FAQ, can hardly be played on modern telnet servers. See explanation above.
Heh, You have read through the article not so closely 
You do realize that it's a bad thing (tm) to have passwords on the command line, right? They can easily be seen by any other user on the system by doing a simple process list.
It would be better to read this sensitive information from a file; ie. give 'empty' an option to read the response from a file instead of requiring it to be a command line argument.
note: having empty read the response from STDIN would also work of course; people can then just do:
cat pwdfile | empty ...
But that might make people do things like:
echo "password" | empty ...
which is equally bad of course
Good idea to hide passwords, I'll think about it.
Excellent article, interesting and well-written.
I mostly use kermit for this kind of scripts but I'll try out empty as soon as I get the chance
I guess 'chat' is a better alternative to your home-grown solution with such an empty meaning of its name.
Other than the lessons you can get about using IO redirection and FIFOs, what you are teaching here boils down to bad habits.
The only time FTP and Telnet should ever be scripted [with the ftp/telnet commands] is when there are absolutely no other options. In this day an age, there are always other options. In my opinion (and, yes, I know what an opinion is), a script should never, EVER contain password information.
Ok, there are always other options
Of course you must not use plain-text passwords and place them directly into scripts. You even must not use telnet protocol at all. And avoid ftp, too. I needn't say why you should use ssh, instead, need I? And you also must not plug your fingers into 220 voltage AC-output.
Telnet was chosen for examples as less harmless alternative, because it's getting rare in real life, but it can show all basic functions of expect-like tools, even abilities to send passwords.
BUT, you can use "Expect and Co" to do other things, I just show the direction.