On 1/4/19 3:30 PM, Bruno Haible wrote:
the test case assumes more about the shell's "<&-"
construct than what POSIX requires.
It is like saying that it would be OK for a program, when interrupted
through Ctrl-Z and restarted through 'fg', to stop processing and exit
with a message "read: Interrupted system call".
I don't see the analogy at all. Currently diffutils has a test shell
script that is not portable POSIX code. Although we've worked around the
problem with HP-UX by hacking on 'diff' itself, there are plausible
POSIX platforms where our current hack will not work. It's not
unreasonable to expect that test scripts should limit themselves to
POSIX features so that they are as portable as reasonably possible.
POSIX allowed the kernel to return from a
read() system call with errno = EINTR. But users don't want this. So it
was seen as a bug in the program, and fixed.
If by "users" you mean "programs that make system calls", then many
users *do* want that. Certainly Emacs does, and I imagine many other
programs do too. If you meant something else by "users" then I'm not
sure I'm following the analogy.
For the stdin-is-closed situation, the users and developers of many (I
would say most) applications do not want 'open' to hijack stdin.
Although the HP-UX solution to this problem may not be best, it's better
than the traditional behavior as it is a simple change to the kernel
that fixes the issue for all applications, as opposed to the
more-complicated dances we do in openat-safer and friends.
After thinking about this a bit more, the message that I'm getting from
all this is that we should change diffutils to no longer rely on the
"feature" that stdin is closed, and remove the test cases that attempt
to test for this "feature". The feature is not portable to POSIX
platforms. Besides, I doubt whether anybody is using the feature anyway.
I put the feature in many years ago, so I can take the blame for
introducing the misguided feature and the responsibility for taking it out.
