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

CHAPTER 16 ■ TELNET AND SSH
tabify2.py
test.py
So what does all of this have to do with network programming?
Well, these two behaviors that we have seen—the fact that programs tend to display prompts if
connected to a terminal, but omit them and run silently if they are reading from a file or from the output
of another command—also occur at the remote end of the shell protocols that we are considering in this
chapter.
A program running behind Telnet, for example, always thinks it is talking to a terminal; so your
scripts or programs must always expect to see a prompt each time the shell is ready for input, and so
forth. But when you make a connection over the more sophisticated SSH protocol, you will actually have
your choice of whether the program thinks that its input is a terminal or just a plain pipe or file. You can
test this easily from the command line if there is another computer you can connect to:
$ ssh -t asaph
asaph$ echo "Here we are, at a prompt."
Here we are, at a prompt.
asaph$ exit
$ ssh -T asaph
echo "The shell here on asaph sees no terminal; so, no prompt."
The shell here on asaph sees no terminal; so, no prompt.
exit
$
So when you spawn a command through a modern protocol like SSH, you need to consider whether
you want the program on the remote end thinking that you are a person typing at it through a terminal,
or whether it had best think it is talking to raw data coming in through a file or pipe.
Programs are not actually required to act any differently when talking to a terminal; it is just for our
convenience that they vary their behavior. They do so by calling the equivalent of the Python isatty()
call (“is this a teletype?”) that you saw in the foregoing example session, and then having “if” statements
everywhere that vary their behavior depending on what this call returns. Here are some common ways
that they behave differently:
• Programs that are often used interactively will present a human-readable prompt
when they are talking to a terminal. But when they think input is coming from a
file, they avoid printing a prompt, because otherwise your screen would become
littered with hundreds of successive prompts as you ran a long shell script or
Python program!
• Sophisticated interactive programs, these days, usually turn on command-line
editing when their input is a TTY. This makes many control characters special,
because they are used to access the command-line history and perform editing
commands. When they are not under the control of a terminal, these same
programs turn command-line editing off and absorb control characters as normal
parts of their input stream.
• Many programs read only one line of input at a time when listening to a terminal,
because humans like to get an immediate response to every command they type.
But when reading from a pipe or file, these same programs will wait until
thousands of characters have arrived before they try to interpret their first batch of
input. As we just saw, bash stays in line-at-a-time mode even if its input is a file,
but Python decided it wanted to read a whole Python script from its input before
trying to execute even its first line.
272