Re: exec redirection is undone if fd (>9) has O_CLOEXEC

[Koichi Murase]

2024年2月24日(土) 15:32 Emanuele Torre <torreemanuele6@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