Sorry, Paul, but I have to vehemently disagree here. You are mixing two different questions: (A) What is the best behaviour for a kernel? (B) What is the best behaviour for a program?
About (A): > We should encourage platforms like HP-UX that try to work around the > trouble The question is: Is it better for a kernel to be minimalist, hence exec() does nothing special with the file descriptors? Or is it better for a kernel to avoid pitfalls for programs, by protecting the first 3 file descriptors? It is similar to the question: In the case of a signal delivery, should a read() or write() system call return with a partial result or EINTR, or should the kernel protect the programs from this knowledge and programming overhead? This question was extensively discussed under the title "worse is better", see https://www.jwz.org/doc/worse-is-better.html https://en.wikipedia.org/wiki/Worse_is_better I have no personal opinion on this question. About (B): > I'd rather think of this as a bug in the test case, not a bug in 'diff'. Here I disagree. * The majority of the uses of 'diff' and coreutils is through shell scripts. * <&- and >&- are POSIX-standardized syntaxes in shell scripts for a long time. * It is a goal to make the same shell script work the same way on different platforms. The user gains nothing if you tell them "your shell script works differently on Linux than on HP-UX because the kernel behaves slightly differently". * Therefore the gnulib modules dirent-safer fcntl-safer fopen-safer freopen-safer openat-safer pipe2-safer popen-safer stdlib-safer tmpfile-safer unistd-safer serve a good purpose. They make programs running on Linux and programs running on HP-UX behave more similarly, which is a good thing. > This is because 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". That's indeed how some programs behaved around 1992: 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. Same here. Bruno
