bug#33050: 27.0.50; [macOS] Problem with process input with process-connection-type nil

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> This may be the clue to the problem:
>
> man termios(4):
>
>    If a process is in the foreground process group of its controlling termi-
>    nal, read operations are allowed.  Any attempts by a process in a back-
>    ground process group to read from its controlling terminal causes a
>    SIGTTIN signal to be sent to the process's group unless one of the fol-
>    lowing special cases apply:  If the reading process is ignoring or block-
>    ing the SIGTTIN signal, or if the process group of the reading process is
>    orphaned, the read(2) returns -1 with errno set to EIO and no signal is
>    sent.  The default action of the SIGTTIN signal is to stop the process to
>    which it is sent.
>
> I output the process-attributes of the started process, and note tpgid
> (ID of foreground process group on the process’s tty) and tty:
>
> - p-c-t t
>
>   attrs=((etime 0 0 7080 0) (start 23504 29912 167367 0) (nice . 0)
>   (tpgid . 16419) (tty . ttys001) (pgrp . 16419) (ppid . 98669) (state
>   . R) (comm . ldapsearch) (group . staff) (egid . 20) (user . fgunbin)
>   (euid . 501))
>
>  ldapsearch's pgrp=16419, it is using ttys001 for r/w, and it's in
>  foreground process group on that tty (tpgid . 16419)
>
> - p-c-t nil
>
>   attrs=((etime 0 0 6177 0) (start 23504 29897 662718 0) (nice . 0)
>   (tpgid . 98669) (tty . ttys000) (pgrp . 16416) (ppid . 98669) (state
>   . R) (comm . ldapsearch) (group . staff) (egid . 20) (user . fgunbin)
>   (euid . 501))
>
>   ldapsearch's pgrp=16416, it is using ttys000 for r/w (??), and it is
>   NOT in foreground process group on that tty - (tpgid . 98669).  98669
>   is emacs, and emacs is in foreground - this is ok.
>
> So the question is - why the process in the second case thinks that it
> has a tty?  When it tries to use it, it receives SIGTTIN and is stopped,
> as termios man page says.  My test case with p-c-t nil results in the
> processed being stopped, indeed.

Try the test case again but with the command "/usr/bin/tty" (with no
arguments).

For me (GNU/Linux, x86_64):

- p-c-t t

  /dev/pts/51

  Process my-process<4> finished

- p-c-t nil

  not a tty

  Process my-process<4> exited abnormally with code 1

(Meanwhile the test case hangs looking for the expected string until I
Ctrl-g it.)

Thomas