Module Name: src
Committed By: kre
Date: Mon Nov 11 22:57:42 UTC 2024
Modified Files:
src/bin/sh: eval.c redir.c redir.h sh.1 show.c
Log Message:
This commit is intended to be what was intended to happen in the
commit of Sun Nov 10 01:22:24 UTC 2024, see:
http://mail-index.netbsd.org/source-changes/2024/11/10/msg154310.html
The commit message for that applies to this one (wholly). I believe that
the problem with that version which caused it to be reverted has been found
and fixed in this version (a necessary change was made as part of one of
the fixes, but the side-effect implications of that were missed -- bad bad me.)
In addition, I found some more issues with setting close-on-exec on other
command lines
With:
func 3>whatever
fd 3 (anything > 2) got close on exec set. That makes no difference
to the function itself (nothing gets exec'd therefore nothing gets closed)
but does to any exec that might happen running a command within the function.
I believe that if this is done (just as if "func" was a regular command,
and not a function) such open fds should be passed through to anything
they exec - unless the function (or other command) takes care to close the
fd passed to it, or explicitly turn on close-on exec.
I expect this usage to be quite rare, and not make much practical difference.
The same applies do builtin commands, but is even less relevant there, eg:
printf 3>whatever
would have set close-on-exec on fd 3 for printf. This is generally
completely immaterial, as printf - and most other built-in commands -
neither uses any fd other than (some of) 0 1 & 2, nor do they exec anything.
That is, except for the "exec" built-in which was the focus of the original
fix (mentioned above) and which should remain fixed here, and for the "."
command.
Because of that last one (".") close-on-exec should not be set on built-in
commands (any of them) for redirections on the command line. This will
almost never make a difference - any such redirections last only as long
as the built-in command lasts (same with functions) and so will generally
never care about the state of close-on-exec, and I have never seen a use
of the "." command with any redirections other than stderr (which is unaffected
here, fd's <= 2 never get close-on-exec set). That's probably why no-one
ever noticed.
There are still "fd issues" when running a (non #!) shell script, that
are hard to fix, which we should probably handle the way most other shells
have, by simply abandoning the optimisation of not exec'ing a whole new
shell (#! scripts do that exec) and just doing it that way. Issues solved!
One day.
To generate a diff of this commit:
cvs rdiff -u -r1.196 -r1.197 src/bin/sh/eval.c
cvs rdiff -u -r1.75 -r1.76 src/bin/sh/redir.c
cvs rdiff -u -r1.28 -r1.29 src/bin/sh/redir.h
cvs rdiff -u -r1.269 -r1.270 src/bin/sh/sh.1
cvs rdiff -u -r1.58 -r1.59 src/bin/sh/show.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
