Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 16 ■ TELNET AND SSH
You will see that this awkward session bears all of the scars of a program operating over a terminal.
Instead of being able to neatly encapsulate each command and separate its arguments in Python, it has
to use spaces and carriage returns and trust the remote shell to divide things back up properly.
■ Note All of the commands in this section simply connect to the localhost IP address, 127.0.0.1, and thus
should work fine if you are on a Linux or Mac with an SSH server installed, and you have copied your SSH identity
public key into your authorized-keys file. If, instead, you want to use these scripts to connect to a remote SSH
server, simply change the host given in the connect() call.
Also, if you actually run this command, you will see that the commands you type are actually echoed
to you twice, and that there is no obvious way to separate these command echoes from the actual
command output:
Ubuntu 10.04.1 LTS
Last login: Mon Sep 6 01:10:36 2010 from 127.0.0.9
echo Hello, world
exit
test@guinness:~$ echo Hello, world
Hello, world
test@guinness:~$ exit
logout
Do you see what has happened? Because we did not wait for a shell prompt before issuing our echo
and exit commands (which would have required a loop doing repeated read() calls), our command text
made it to the remote host while it was still in the middle of issuing its welcome messages. Because the
Unix terminal is by default in a “cooked” state, where it echoes the user's keystrokes, the commands got
printed back to us, just beneath the “Last login” line.
Then the actual bash shell started up, set the terminal to “raw” mode because it likes to offer its own
command-line editing interface, and then started reading your commands character by character. And,
because it assumes that you want to see what you are typing (even though you are actually finished
typing and it is just reading the characters from a buffer that is several milliseconds old), it echoes each
command back to the screen a second time.
And, of course, without a good bit of parsing and intelligence, we would have a hard time writing a
Python routine that could pick out the actual command output—the words Hello, world—from the rest
of the output we are receiving back over the SSH connection.
Because of all of these quirky, terminal-dependent behaviors, you should generally avoid ever using
invoke_shell() unless you are actually writing an interactive terminal program where you let a live user
type commands.
A much better option for running remote commands is to use exec_command(), which, instead of
starting up a whole shell session, just runs a single command, giving you control of its standard input,
output, and error streams just as though you had run it using the subprocess module in the Standard
Library. A script demonstrating its use is shown in Listing 16–6. The difference between exec_command()
and a local subprocess (besides, of course, the fact that the command runs over on the remote machine!)
is that you do not get the chance to pass command-line arguments as separate strings; instead, you have
to pass a whole command line for interpretation by the shell on the remote end.
284