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

From: Kaz Kylheku <[email-masked]>
Date: Fri Jan 9 08:56:03 2004

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 [email-masked] ls")

SSH prompts for password. You type, but characters are echoed to the
terminal and are not going into ssh!

This is not the subordinate program's fault, because you can redirect
its output from the shell without running into this problem, e.g.

   ssh [email-masked] ls | some-program
   # ssh prompts for password, you can enter it

I haven't done enough investigation to know what the exact issue is;
but it's likely because of the SETSID() call in create_input_pipe().

The setsid() function creates a new job control session with no
controlling tty.

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).

Note how the shell does not create new sessions for commands:

$ ps -o sess,pid,command

 SESS   PID COMMAND
17457 17457 -bash
17457 18145 /bin/bash -c (ps -o sess,pid,command) >/tmp/v683723/3 2>&1
17457 18146 ps -o sess,pid,command

See? The ps process is in the same session as the shell. Not in a new
session.  The shell is the session leader: its PID and session ID are
the same.

---

From: Sam Steingold <[email-masked]>
Date: Fri Jan 9 09:42:01 2004

I don't know enough about pipes, setsid &c to fix this.
Patches are welcome.

> * Kaz Kylheku <[email-masked]> [2004-01-09 08:55:49 -0800]:
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Don't use force -- get a bigger hammer.

---

From: Bruno Haible <[email-masked]>
Date: Fri Jan 9 13:38:03 2004

> > 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.

> > terminal (and probably must use O_NOCTTY when opening tty devices to

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

---

From: Kaz Kylheku <[email-masked]>
Date: Fri Jan 9 14:30:01 2004

> Any idea how to resolve this conflict?

Under POSIX job control, doesn't the tty subsystem only generate Ctrl-C
SIGINT for processes that are in the foreground process group?

I'm afraid that to fix this well, CLISP will have to become more
shell-like by doing a POSIX job control.

Imagine how the shell works. If you background a process with & you
are back at the prompt. If you type Ctrl-C, it does not disturb the
background process; any SIGINT goes to the shell (or in a totally
modernized shell, the tty is put into character mode for editing, and
the Ctrl-C arrives as ASCII character 3).

When you foreground the process, its group becomes the foreground
process group, and now receives the SIGINT. Meanwhile, the shell is in
the background. It can detect a change in the job using some
combination of wait() and SIGCHLD.