Foundations of Python Network Programming

Chapter 16 ■ telnet and SSh

291

As made obvious by this example, the rules by which modern shells interpret the special characters in your
command line have become quite complex. The manual page for the bash shell currently runs a total of 5,375 lines, or
223 screens full of text in a standard 80×24 terminal window! Obviously, it would lead this chapter far astray if I were to
explore even a fraction of the possible ways that a shell can mangle a command that you type.
Instead, to help you use the command line effectively, you will focus in the next sections on just two key points:

•    Special characters are interpreted as special by the shell you are using, like bash. They do not

mean anything special to the operating system itself.

•    When passing commands to a shell either locally or, as will be more common in this chapter,

across the network, you need to escape the special characters you use so that they are not

expanded into unintended values on the remote system.

I will now tackle each of these points in their own section. Keep in mind that I am talking about common server
operating systems like Linux and OS X, not more primitive ones like Windows, which I will discuss in its own section.

Unix Command Arguments Can Include (Almost) Any Character

The pure, low-level Unix command line has no special or reserved characters. This is an important fact for you to
grasp. If you have used a shell like bash for any length of time, you may have come to view your system command line
as being something like a minefield. On one hand, all of the special characters make it easy to, say, name all the files
in the current directory as arguments to a command. However, on the other hand, it can be difficult to echo a message
to the screen that does something as simple as mix single with double quotes, and it can be hard to learn which
characters are safe and which are among the many that the shell considers special.
The simple lesson of this section is that the whole set of conventions regarding the special characters of the
shell has nothing to do with your operating system. They are simply and entirely a behavior of the bash shell, or
of whichever of the other popular (or arcane) shells you are using. It does not matter how familiar the rules seem
or how difficult it is for you to imagine using a Unix-like system without them. If you take the shell away, then the
phenomenon of special characters vanishes.
You can observe this quite simply by launching a process yourself and trying to throw some special characters at
a familiar command.

import subprocess
args = ['echo', 'Sometimes', '', 'is just an asterisk']
subprocess.call(args)
Sometimes is just an asterisk

Here you are opting to launch a new process with arguments without asking a shell to get involved. The
process—in this case the echo command—is getting exactly those characters, instead of having the * turned into
a list of file names first.
Though the asterisk wildcard character is used frequently, the shell’s most common special character is one
that you use all the time: the space character. Each space is interpreted as a delimiter separating arguments. This
results in endless hours of entertainment when people include spaces in Unix file names and then try to move the file
somewhere else.

$ mv Smith Contract.txt ~/Documents
mv: cannot stat Smith': No such file or directory mv: cannot statContract.txt': No such file or directory