2024年2月24日(土) 15:32 Emanuele Torre <torreemanue...@gmail.com>: > On Sat, Feb 24, 2024 at 02:11:25PM +0900, Koichi Murase wrote: > > I have a question. Maybe it's not technically a bug as fd > 9 is > > involved, but the resulting behavior appears to be strange. I > > received some reports from users in my project and tried to find out > > what is happening. This is a reduced case: > > Thank you for bringing this up; I have also noticed weird behaviour with > redirections of cloexec file descriptors a couple months ago.
Thank you for your additional information. > Bash seems to check for the CLOEXEC flag in the source file descriptor, > and preserves it in the destination file descriptor when performing a > n<&m redirection. Ah, I have to confess that I'm already relying on this specific behavior of copying CLOEXEC, so if it is changed now, I might have to consider removing some features from my project. You might expect the redirections would be essentially implemented by a single syscall, but in reality, the shell redirections are more complicated. For example, we need to save and restore original streams associated with the file descriptor. In that sense, it's not surprising to me that the shell performs extra operations (even if it is not so obvious to the users), but I'm neutral about whether the current behavior is better or worse. ---- Anyway, as far as I look at the source code, the behavior of copying CLOEXEC is an intentional design and is not a random side effect of some other processing. In this sense, the strange behavior you observe is a design issue. Meanwhile, the behavior that `exec 50>2.txt' does not have an effect does not seem to be the intentional design. It seems to be just a side effect of the manipulation of the saved fds. In this sense, the strange behavior I observe is the one that Chet did not primarily intend, I guess. But it's just my naive guess. -- Koichi
