Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

BOLO: Possible shell issues in HEAD



Please be on the lookout for any weirdness that might be caused
by /bin/sh in NetBSD -current (HEAD).

The changes made to "fix" PR bin/48875 were reverted several hours
ago (that's a safe change - other than that it brings back the PR issue).

I have just committed a different set of changes - these have the
effect of (apparently) fixing the PR, but don't really, they just reduce
the chances that it will be observed.   The PR is not really describing
a bug, more a "wish the world did not have to be like this" situation
(which a forthcoming sh.1 man page update will clarify.)

Today's changes (internal to how sh operates) improve its operating
characteristics - they're essentially performance improvements.
It just happens that by doing less work, the situation described in
the PR is less likely to be observed.

You will easily observe (some of) the changes if you do:

	( ( ( ( (  ps -T ) ) ) ) )       ; # see footnote[*] below

in /bin/sh before these changes, and after - in the before case you will
see one waiting sh process for each indicated sub-shell (so 5 of them),
after the changes, the ps process will be a direct child of the shell in
which this command was entered, the sub-shells accomplish nothing,
so they are omitted.

And yes, even in

	( ( ( ( ( cd /; ps -T ) ) ) ) )

the "ps" will be a direct child of the invoking shell - the shell forks, 
changes directory, and then exec's ps.

Obviously in cases where a sub-shell waiting is needed, one will be
present:

	( ( ( ( ( ps -T; ps -T ) ) ) ) )

the first ps will run as a child of a forked sub-shell, when it is done,
the second will simply be exec'd and be a child of the invoking shell.
(nb: this direct exec is never guaranteed - never rely upon it, and it
is possible to make slight changes to the input which will prevent it.)

There are other changes which are straight out bug fixes (to bugs
which rarely occur it is true, but which are bugs and needed fixing
anyway.)

This message is a request for everyone to watch out for any strange
behaviour that may occur as a result of these changes.   If you see
something that seems to not be like it should be, and you believe, or
even just suspect, that the sh changes might be related, please let me
know (or file a PR).

The changes (largely) come more or less directly from FreeBSD's sh,
and have been applied there for years there now, so I do have a
reasonably high expectation that there will be no problems (and I have
been doing quite a bit of testing since the code for this was completed.)

kre

Footnote[*]:  in our sh the only space needed in:
	( ( ( ( (  ps -T ) ) ) ) )	
is that between "ps" and "-T", but to be conforming, the sequence '(('
(with no intervening space) is only permitted (unquoted) as part of "$((".
Some shells use (( as a different operator, so it is best to always leave a
space between unquoted consecutive opening parentheses.  The spaces in
the  ) )  sequence are just to make it look prettier, they're never needed,
nor are those between '(' and 'ps' or '-T' and ')'.   Of course, if you're
just typing this into our /bin/sh as a test then "(((((ps -T)))))" is fine!



Home | Main Index | Thread Index | Old Index