Re: why does </proc/self/environ not work in bash?

[Koichi Murase]

2024年2月13日(火) 5:56 Christoph Anton Mitterer <calestyo@scientia.org>:
> On Mon, 2024-02-12 at 10:06 +0900, Koichi Murase wrote:
> > I quickly checked XCU 2.9.1, but it doesn't seem to specify when the
> > fork (or in other words, the preparation of a separate execution
> > environment) should be performed.
>
> Well it says: [...]
>
> So independent of any optimisations, I would interpret this as
> redirections should behave as if they were done by the shell.
>
> And whether this is then done in a subshell, forked process, etc. pp.
> I would at least expect the shell's environment to be present and the
> command name be something that is not the program about to be executed.

Yes, the redirections are performed in the shell contexts, but it's
trivial that the processing of the redirections are performed in the
shell because it's a shell's feature. And, it's consistent with Bash's
implementation. It's unrelated to whether the redirection should be
performed before the fork or after the fork.

I was wondering why you are talking about the timing of the
determination of the command name and trying to relate it to the fork,
but maybe you misunderstand the fork? A fork just creates another
shell process which is a copy of the original. After the fork, it's
still the shell and the redirections can be set up there.

> But same here, [...]the check whether the command name is a special built-in
> or function, can only be made by the shell, not by the program to be
> executed.
> And that whole item comes well after "Redirections shall be performed
> as described in Redirection."
>
> 2.7 also says
> "A failure to open or create a file shall cause a redirection to fail."
> which I'd interpret that at the "Redirection" step. the file is
> actually opened/created (how could it fail, if it were not).

I don't see the point of all those discussions. Your long argument
seems to tell only a trivial thing that the command name determination
and the redirections are performed by the shell.

> I would have anyway thought that the swapping clause doesn't apply to
> our case, as in our case a command name *does* result, so the swapping
> is *not* allowed.

Ah, OK. Since you mentioned it in your previous reply, the swapping
may apply to the present case. Anyway, what I wanted to carry is that
a separate execution environment already exists in step 4.

> As I've said... though same time OTOH, if one follows the order given
> by 2.9.1. then in my understanding the standard would say, that (in our
> case) the redirections (with actually opening the files) should happen
> at step 3, and at least from my arguing above I'd say that's
> conceptually still considered to be done within/by the shell.

The redirections do happen at step 3 in Bash.

> >
> > See this reply:
> >
> > https://lists.gnu.org/archive/html/help-bash/2024-02/msg00026.html
>
> What I meant is not:
> How does it technically happen, that the env is empty.

It's closely related to the reason that the environment cannot be read
through the opened file descriptor. Actually, I believe it should be
empty. Performing exec means that the environment is re-initialized.
Given that the redirections are performed in the forked shell, the old
environment that the opened stream references already has disappeared
when the exec'd program reads the stream.

> I rather meant:
> Why would that be allowed by POSIX (or be reasonably expected by
> users)?
>
> It's fine if implementations do optimisations, but it doesn't seem to
> me that e.g. 2.9.1 would reasonably allow that at some step in there
> the environment of the shell is suddenly gone.

The environment of the shell is gone because the shell is gone i.e.
replaced by a program with exec. I don't think POSIX requires the
ability to read the environment of an already disappearing program.
What you are requesting is to make it possible to read the environment
of a program that doesn't exist anymore.