Chapter 16 ■ telnet and SSh297$ ls
sftp.py ssh_commands.py ssh_simple.txt telnet_codes.py
shell.py ssh_simple.py ssh_threads.py telnet_login.py
$ ls | cat
sftp.py
shell.py
ssh_commands.py
ssh_simple.py
ssh_simple.txt
ssh_threads.py
telnet_codes.py
telnet_login.py
So, what does all of this have to do with network programming? Well, the two behaviors you 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 you are
considering in this chapter.
A program running behind Telnet, for example, always thinks it is talking to a terminal. Thus, your scripts or
programs must always expect to see a prompt each time the shell is ready for input, and so forth. However, 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 to which you can connect.
$ 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
$
Thus, 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 vary their behavior depending on what this call returns. Here
are some common ways they behave differently:
• Programs that are often used interactively will present a human-readable prompt when they
are talking to a terminal. However, 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!• Nowadays, sophisticated interactive programs usually turn on command-line editing when
their input is a TTY. This makes many control characters special because they are used to
accessing the command-line history and performing 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.