Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/unix/volume22/pty/part04/QUESTIONS

Text File | 1990-10-09 | 4KB | 103 lines

I selected the questions below from articles posted to the USENET
newsgroup comp.unix.questions. All the questions are reasonably easy to
answer with pty and not too easy to answer with other widely available
tools. So I hope this file is useful, and I hope other software authors
adopt the QUESTIONS idea.

Organization: question, one-sentence answer, further details of
answer, why the question normally poses a problem, and why the answer
given solves the problem.


1. How to redirect telnet's input?

Run pty telnet instead of telnet. Caveat: telnet stupidly flushes its
input at connect time, so be careful not to flood it; instead do
something like % (sleep 5;echo help;echo quit) | pty telnet whatever 25.
(Try it!) The five-second pause should be enough. For a more
sophisticated (and reliable) technique, see #4 below.

The problem here is that telnet wants to take its input from a terminal.
Most other interactive applications (e.g., editors) feel the same way
about stdin, stdout, and stderr. pty solves this by setting input,
output, and error all to the pseudo-terminal.


2. How to redirect su's input?

pty su < input, of course. (I certainly don't recommend putting your
password in plaintext to be fed to su, but it can be done!) Note that
some su's flush their input; solve this as in #1 above or #4 below.

The problem is that su opens /dev/tty for its input. Many other programs
use /dev/tty explicitly for input and output; how do you redirect them?
pty solves this because a program under a pseudo-terminal refers to that
terminal when it opens /dev/tty.


3. How to make sed 's/foo/bar/g' | more work?

pty -0 sed 's/foo/bar/g' | more. You can abbreviate pty -0 as condom.

The problem is that sed uses stdio. stdio checks whether its output is a
terminal; if not, it buffers a block of data inside the program. To see
this in action, try the original % sed 's/foo/bar/g' | more; unless you
type a lot of input, sed will keep buffering its output, so you'll never
see anything.

pty solves the stdio buffer problem because a program under stdio does
have a terminal (the pseudo-terminal) as output. So stdio buffers only a
line at a time.


4. How to start a program, respond to its prompts, give the correct
   replies, and catch the output?

On a machine with named pipes created by mknod foo p:

  #!/bin/sh
  # Generic reader-writer.
  (umask 077;mknod input p;mknod output p)
  pty -0 program args < input | pty -0 tee record > output &
  exec 4>input 5<output
  # Now read prompts from <&5 and write replies to >&4.
  # A transcript is kept in record.

Another solution is to create two (unnamed) pipes, then stick pty
between them as above. This requires C code but is more portable.

The problems here are just the problems in #1-#3 above.


5. How to fool rn into processing KILL files in the background?

pty -T rn &. This does have one deficiency: control characters like ^C,
^Z, and so on affect pty rather than rn. (That's what -T does.) This
doesn't matter for rn, but pty -T vi verylongfile definitely doesn't
work the right way. To pass control characters through, start with

  % pty -s sh -c 'sessname;disconnect;pty vi verylongfile'

(pty -s can be abbreviated as sess.) Then watch the vi process with ps
or by typing pty -sT reconnect xx, watching, then pressing ^C, where xx
is the session name (pty extension). When you want to reconnect and pass
control characters to vi, type % pty -s reconnect xx. From that point
it'll feel just like a normal vi.

The problem is that rn---like all character-based interactive
applications---wants to change the tty mode to read one character at a
time instead of one line at a time. The tty driver doesn't let it do
this in the background. pty -T rn solves this because rn is really in
the foreground under the pty.


6. How to get terminal speed from shell script?

"`pty stty speed`", assuming fd 0 or fd 2 is the tty.

The problem is that a straight `stty speed` pipes stty's output away
from your terminal and back into your shell. Many versions of stty
assume that their output points to the terminal, so they blow up. pty
solves this because it copies information from the real terminal to the
pseudo-terminal.