[clisp-list] Re: Annoying pipe stream behavior.

[Bruno H. <br...@cl...>]

Kaz Kylheku wrote:
> > If you run an external process with MAKE-PIPE-INPUT-STREAM, and that
> > process, or a child thereof, wants input from the terminal---such as a
> > password---it doesn't work.
> >
> > For example
> >
> >    (make-pipe-input-stream "ssh me@remote.host ls")
> >
> > SSH prompts for password. You type, but characters are echoed to the
> > terminal and are not going into ssh!

For me, something different happens: I see an endless stream of
  Enter passphrase for RSA key '/home/haible/.ssh/identity':
prompts. That's because ssh has done open("/dev/tty") and attempts
to read() from it. The read() call is interrupted with SIGTTIN and
returns with errno == EINTR, ssh thinks it was interrupted with Ctrl-Z
and then restarted, and redisplays the prompts and tries to read again...
So it's really the SIGTTIN which is the problem, and yes it comes from
the setpgrp() or setsid() call.

> > Why would you want to do that for a pipe coprocess?  That's useful for
> > a background process such as a daemon which runs without a controlling
> > terminal (and probably must use O_NOCTTY when opening tty devices to
> > avoid acquiring one).

I think the reason was the Ctrl-C handling: If subprocesses spawned via
RUN-PROGRAM and MAKE-PIPE-*-STREAM are launched in the same process group,
then they are killed when the user presses Ctrl-C. But the user's intention
when he presses Ctrl-C is to abort the current Lisp computation or even
more simply to correct a typo in a preceding input line. If it makes
subprocesses die, this is perceived as a bug.

Blocking SIGINT while doing the fork(), so that the child starts with
SIGINT blocked, is not a solution because 1. whether the child then
really starts with SIGINT blocked is system dependent, 2. POSIX recommends
against this.

Any idea how to resolve this conflict?

Bruno