bug#66186: "make lisp/eshell/esh-proc-tests" fails intermittently since 7e50861ca7ed3f620fe62ac6572f6e88b3600ece

[Jens Schmidt]

Jim Porter <jporterbugs@gmail.com> writes:

> On 9/24/2023 11:47 PM, Eli Zaretskii wrote:
>
>> That's always a good thing, thanks.
>
> ... I've also done this. Now the regression tests should just
> avoid the possibility of a SIGPIPE, which will hopefully resolve
> this bug.
>
> Jens, could you try this version out to make sure the tests pass
> reliably for you?

They do pass reliably now, thanks.

TBH, I initially didn't read your commit message and, hence, failed to
understand that `printnl' without parameters prints nothing - I thought
it would print at least a newline, which seemed to me like pushing the
race condition just further down the line.

So how about using something that more explicitly does not print
anything?  Like, for example `(ignore)', which also seems to generate no
output?

(Actually, I also tested a variant where that shell statement simply
slurps its stdin, like generated by this function:

(defun esh-proc-test--detect-pty-cmd (&optional read-input)
  "Generate a shell command that prints the standard stream status.
The generated shell command prints the standard streams which are
connected as TTYs.  If READ-INPUT is present and non-nil and
Emacs is in batch mode the generated command gobbles up stdin to
avoid SIGPIPE errors."
  (concat "sh -c '"
          "if [ -t 0 ]; then echo stdin; fi; "
          "if [ -t 1 ]; then echo stdout; fi; "
          "if [ -t 2 ]; then echo stderr; fi; "
          (when (and read-input noninteractive)
            ;; Read stdin using only shell built-ins.
            "while read dummy; do :; done; ")
          "'"))

But simply not printing to the pipe is of course, well, simpler.)