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

CHAPTER 16 ■ TELNET AND SSH
As we will see, there does exist a very primitive network protocol—the ancient Telnet protocol—that
also sends command lines simply as text, like Windows does, so that your program will have to do some
kind of escaping if it sends arguments with spaces or special characters in them. But if you are using any
sort of modern remote protocol like SSH that lets you send arguments as a list of strings, rather than as a
single string, then be aware that on Windows systems all that SSH can do is paste your carefully
constructed command line back together and hope that the Windows command can figure it out.
When sending commands to Windows, you might want to take advantage of the list2cmdline()
routine offered by the Python subprocess module. It takes a list of arguments like you would use for a
Unix command, and attempts to paste them together—using double-quotes and backslashes when
necessary—so that “normal” Windows programs will parse the command line back into exactly the same
arguments:
>>> from subprocess import list2cmdline
>>> args = ['rename', 'salary "Smith".xls', 'salary-smith.xls']
>>> print list2cmdline(args)
rename "salary \"Smith\".xls" salary-smith.xls
Some quick experimentation with your network library and remote-shell protocol of choice (after
all, the network library might do Windows quoting for you instead of making you do it yourself) should
help you figure out what Windows needs in your situation. For the rest of this chapter, we will make the
simplifying assumption that you are connecting to servers that use a modern Unix-like operating system
and can keep command-line arguments straight without quoting.
Things Are Different in a Terminal
You will probably talk to more programs than just the shell over your Python-powered remote-shell
connection, of course. You will often want to watch the incoming data stream for the information and
errors printed out by the commands you are running. And sometimes you will even want to send data
back, either to provide the remote programs with input, or to respond to questions and prompts that
they present.
When performing tasks like this, you might be surprised to find that programs hang indefinitely
without ever finishing the output that you are waiting on, or that data you send seems to not be getting
through. To help you through situations like this, a brief discussion of Unix terminals is in order.
A terminal typically names a device into which a user types text, and on whose screen the
computer's response can be displayed. If a Unix machine has physical serial ports that could possibly
host a physical terminal, then the device directory will contain entries like /dev/ttyS1 with which
programs can send and receive strings to that device. But most terminals these days are, in reality, other
programs: an xterm terminal, or a Gnome or KDE terminal program, or a PuTTY client on a Windows
machine that has connected via a remote-shell protocol of the kind we will discuss in this chapter.
But the programs running inside the terminal on your laptop or desktop machine still need to know
that they are talking to a person—they still need to feel like they are talking through the mechanism of a
terminal device connected to a display. So the Unix operating system provides a set of “pseudoterminal”
devices (which might have less confusingly been named “virtual” terminals) with names like
/dev/tty42. When someone brings up an xterm or connects through SSH, the xterm or SSH daemon
grabs a fresh pseudo-terminal, configures it, and runs the user's shell behind it. The shell examines its
standard input, sees that it is a terminal, and presents a prompt since it believes itself to be talking to a
person.
270