View source for Expect remote commands


= Remote Execution with TCL and Expect =

== Preamble ==

Ok, so the title is a little ambiguous. And, it needs a better home on this wiki.

Before going further, "expect" is an application written in the Tcl language. If that's not what your looking for, go away now!

I looked around the net (since re-inventing the wheel is rarely
a good use of time) for what I wanted: to have expect log onto a remote machine (or router) and execute commands there, driven from a file containing a list of commands
on the host that is running expect.
I didn't find it. Bummed, I realized I would need to write it myself. And quickly.

The scrap of code below can certainly be embellished to do all sorts of cool things,
with a modicum of understanding of Tcl. This can possibly violate local security policy. Be careful.

This is one of the reasons I set up this wiki... to be able to post cookbook stuff
for my own benefit that might also benefit others... so here it is...

== The Code ==

<pre>
#!/usr/bin/expect
#
# Read a local list of commands and execute them on remote host
#
# WA2IAC 3/9/2015
#

spawn ssh -l username hostname
expect "ord\\: "
send "password\r"
set handle [ open commands.txt r ]
while { ! [eof $handle] } {
        gets $handle buf
        #puts $buf
        expect "\\~\\#"
        #puts $buf
        send "$buf\r"
        }
interact

</pre>

== Gotchas ==
Of course, the content of the list of commands is crucial. Here is a simple example.

<pre>
ls -l /usr/bin
who
uptime
uname -a
</pre>

No biggies there. You'll get into problems, however, if you use characters that are special to tcl, like '{', '}', and even '#'. So, you've been warned.

== My Two Cents ==

It's a lot easier to do this using "rsh", however, with today's security paranoia, the "r" commands are disabled by default. This is silly when you're operating on a protected LAN, especially if it's solo. Do you suffer from multiple personality disorder (MPD)? If so, is one of your personalities a terrorist threatening to attack America? If not, then it might be OK to enable those "r" commands.

The *nix operating system was hatched in an open, acedemic environment. You know, the kind
that develops nuclear weapons and other high-tech implements of destruction for the
government. Good, safe, clean, wholesome stuff. It was in that environment that the 'r'
commands (rsh, rlogin, rcp, etc.) and other relatively insecure stuff like NFS flourished
and made the lives of users more tolerable. Your environment might benefit from these
light-weight and powerful tools, if transmitting data on your LAN is unlikely to be
intercepted by terrorist threats.

Security for security's sake is not good security, and it's usually bad for business.
Unless you thrive on paranoia and spending lots of time on it, you might want to take
a look around and question what all the crazyness is about. Security can be,
and many times is, a good thing. Other times, not so much.
is a good thing and necessary. Especially when it makes you reinvent the wheel for
no good reason.