CVS log for src/bin/sh/main.c

Up to [cvs.NetBSD.org] / src / bin / sh

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

The great shell trailing whitespace cleanup of 2023...
Inspired by private e-mail comments from mouse@

NFCI.

Add the -l option (aka -o login): be a login shell.   Meaningful only on
the command line (with both - and + forms) - overrides the presence (or
otherwise) of a '-' as argv[0][0].

Since this allows any shell to be a login shell (which simply means that
it runs /etc/profile and ~/.profile at shell startup - there are no other
side effects) add a new, always set at startup, variable NBSH_INVOCATION
which has a char string as its value, where each char has a meaning,
more or less related to how the shell was started.   See sh(1).
This is intended to allow those startup scripts to tailor their behaviour
to the nature of this particular login shell (it is possible to detect
whether a shell is a login shell merely because of -l, or whether it would
have been anyway, before the -l option was added - and more).   The
var could also be used to set different values for $ENV for different
uses of the shell.

Pull up following revision(s) (requested by kre in ticket #1371):

	bin/sh/main.c: revision 1.87
	bin/sh/main.c: revision 1.88
	bin/sh/memalloc.h: revision 1.20
	bin/sh/sh.1: revision 1.235
	bin/sh/memalloc.c: revision 1.34
	bin/sh/memalloc.c: revision 1.35
	bin/sh/memalloc.h: revision 1.19
	bin/sh/shell.h: revision 1.31
	bin/sh/options.c: revision 1.56

PR bin/56464

After almost 30 years, finally do the right thing and read $HOME/.profile
rather than .profile in the initial directory (it was that way in version
1.1 ...)   All other ash descendants seem to have fixed this long ago.
While here, copy a feature from FreeBSD which allows "set +p" (if a
shell run by a setuid process with the -p flag is privileged) to reset
the privileges.  Once done (the set +p) it cannot be undone (a later
set -p sets the 'p' flag, but that's all it does) - that just becomes a
one bit storage location.

We do this, as (also copying from FreeBSD, and because it is the right
thing to do) we don't run .profile in a privileged shell - FreeBSD run
/etc/suid_profile in that case (not a good name, it also applies to setgid
shells) but I see no real need for that, we run /etc/profile in any case,
anything that would go in /etc/suid_profile can just go in /etc/profile
instead (with suitable guards so the commands only run in priv'd shells).

One or two minor DEBUG mode changes (notably having priv'd shells identify
themselves in the DEBUG trace) and sh.1 changes with doc of the "set +p"
change, the effect that has on $PSc and a few other wording tweaks.

XXX pullup -9   (not -8, this isn't worth it for the short lifetime
that has left - if it took 28+ years for anyone to notice this, it
cannot be having all that much effect).

Use a type-correct end marker for strstrcat() rather than NULL, as
for a function with unknown number & types of args, the compiler isn't
able to automatically convert to the correct type.   Issue pointed out
in off list e-mail by Rolland Illig ... Thanks.

The first arg (pointer to where to put length of result) is of a known
type, so doesn't have the same issue - we can keep using NULL for that
one when the length isn't needed.
Also, make sure to return a correctly null terminated null string in
the (absurd) case that there are no non-null args to strstrcat() (though
there are much better ways to generate "" on the stack).  Since there is
currently just one call in the code, and it has real string args, this
isn't an issue for now, but who knows, some day.

NFCI - if there is any real change, then it is a change that is required.

XXX pullup -9 (together with the previous changes)

Use a type-correct end marker for strstrcat() rather than NULL, as
for a function with unknown number & types of args, the compiler isn't
able to automatically convert to the correct type.   Issue pointed out
in off list e-mail by Rolland Illig ... Thanks.

The first arg (pointer to where to put length of result) is of a known
type, so doesn't have the same issue - we can keep using NULL for that
one when the length isn't needed.

Also, make sure to return a correctly null terminated null string in
the (absurd) case that there are no non-null args to strstrcat() (though
there are much better ways to generate "" on the stack).  Since there is
currently just one call in the code, and it has real string args, this
isn't an issue for now, but who knows, some day.

NFCI - if there is any real change, then it is a change that is required.

XXX pullup -9 (together with the previous changes)

PR bin/56464

After almost 30 years, finally do the right thing and read $HOME/.profile
rather than .profile in the initial directory (it was that way in version
1.1 ...)   All other ash descendants seem to have fixed this long ago.

While here, copy a feature from FreeBSD which allows "set +p" (if a
shell run by a setuid process with the -p flag is privileged) to reset
the privileges.  Once done (the set +p) it cannot be undone (a later
set -p sets the 'p' flag, but that's all it does) - that just becomes a
one bit storage location.

We do this, as (also copying from FreeBSD, and because it is the right
thing to do) we don't run .profile in a privileged shell - FreeBSD run
/etc/suid_profile in that case (not a good name, it also applies to setgid
shells) but I see no real need for that, we run /etc/profile in any case,
anything that would go in /etc/suid_profile can just go in /etc/profile
instead (with suitable guards so the commands only run in priv'd shells).

One or two minor DEBUG mode changes (notably having priv'd shells identify
themselves in the DEBUG trace) and sh.1 changes with doc of the "set +p"
change, the effect that has on $PSc and a few other wording tweaks.

XXX pullup -9   (not -8, this isn't worth it for the short lifetime
that has left - if it took 28+ years for anyone to notice this, it
cannot be having all that much effect).

Improve the solution for the 2nd access to a fd which shouldn't
be available ("13") issue reported by Jan Schaumann on netbsd-users.

This fixes a bug in the earlier fix (a day or so ago) which could allow the
shell's idea of which fd range was in use by the script to get wildly
incorrect, but now also actually looks to see which fd's are in use as
renamed other user fd's during the lifetime of a redirection which needs
to be able to be undone (most redirections occur after a fork and are
permanent in the child process).   Attempting to access such a fd (as with
attempts to access a fd in use by the shell for its own purposes) is treated
as an attempt to access a closed fd (EBADF).  Attempting to reuse the fd
for some other purpose (which should be rare, even for scripts attempting
to cause problems, since the shell generally knows which fds the script
wants to use, and avoids them) will cause the renamed (renumbered) fd
to be renamed again (moved aside to some other available fd), just as
happens with the shell's private fds.

Also, when a generic fd is required, don't give up because of EMFILE
or similar unless there are no available fds at all (we might prefer >10
or bigger, but if there are none there, use anything).  This avoids
redirection errors when ulimit -n has been set small, and all the fds >10
that are available have been used, but we need somewhere to park the old
user of a fd while we reuse that fd for the redirection.

Ooops, restore accidently removed files from merge mishap

Sync with HEAD

Merge changes from current as of 20200406

Pull up following revision(s) (requested by kre in ticket #684):

	bin/sh/jobs.c: revision 1.107
	bin/sh/main.c: revision 1.83
	bin/sh/main.c: revision 1.84
	bin/sh/main.c: revision 1.85

If we are invoked with SIGCHLD ignored, we fail badly, as we assume
that we can always wait(2) for our children, and an ignored SIGCHLD
prevents that.   Recent versions of bash can be convinced (due to a
bug most likely) to invoke us that way.   Always return SIGCHLD to
SIG_DFL during init - we already prevent scripts from fiddling it.

All ash derived shells apparently have this problem (observed by
Martijn Dekker, and notified on the bash-bug list).  Actual issue
diagnosed by Harald van Dijk (same list).

Actually, the issue with bash (in previous) is more likely that the
SIGCHLD is blocked rather than ignored.   We want neither.   Make sure
SIGCHLD is unblocked as well as SIG_DFL.

XXX pullup -9

bin/sh: Fixes -Werror=shadow causing build breaks.
Conflicting variable name, sigset_t sigs has been renamed to sigset_t mask

Reviewed by: kamil@

Avoid a core dump if a child process that is not one of our
children happens to exit while we are waiting for another child
to exit.

This can happen with code like
	sh -c '
		sleep 5 &
		exec sh -c "sleep 10 & wait !$"
	      '

when the inner "sh" is waiting for the 10 second sleep to be
done, the 5 second sleep started earlier terminates.   It is
a child of our process, as the inner shell is the same process
as the outer one, but not a known child (the inner shell has no
idea what the outer one did before it started).

This was observed in the wild by Martijn Dekker (where the outer
shell was bash but that's irrelevant).

XXX pullup -9

bin/sh: Fixes -Werror=shadow causing build breaks.

Conflicting variable name, sigset_t sigs has been renamed to sigset_t mask

Reviewed by: kamil@

Actually, the issue with bash (in previous) is more likely that the
SIGCHLD is blocked rather than ignored.   We want neither.   Make sure
SIGCHLD is unblocked as well as SIG_DFL.

XXX pullup -9

If we are invoked with SIGCHLD ignored, we fail badly, as we assume
that we can always wait(2) for our children, and an ignored SIGCHLD
prevents that.   Recent versions of bash can be convinced (due to a
bug most likely) to invoke us that way.   Always return SIGCHLD to
SIG_DFL during init - we already prevent scripts from fiddling it.

All ash derived shells apparently have this problem (observed by
Martijn Dekker, and notified on the bash-bug list).  Actual issue
diagnosed by Harald van Dijk (same list).

Sync with HEAD

When an interactive shell exits due to an EOF on stdin, send a newline
to stderr (to follow the previous prompt) and cleanup more nicely.

PR bin/53919

Suppress shell error messages while expanding $ENV (which also causes
errors while expanding $PS1 $PS2 and $PS4 to be suppressed as well).

This allows any random garbage that happens to be in ENV to not
cause noise when the shell starts (which is effectively all it did).

On a parse error (for any of those vars) we also use "" as the result,
which will be a null prompt, and avoid attempting to open any file for ENV.

This does not in any way change what happens for a correctly parsed command
substitution (either when it is executed when permitted for one of the
prompts, or when it is not (which is always for ENV)) and commands run
from those can still produce error output (but shell errors remain suppressed).

Sync with HEAD

When we exit from running off the end of the input file (which
includes typing ^D) make sure LINENO is set to indicate the last
(actually one past last) line in the input file, rather than
whatever it was set to by the last command that was actually
executed (which could be some line in a function defined in
some other file).

No effect on exit via an explicit exit command - that would already
set the line number correctly.

Sync with HEAD, resolve a few conflicts

PR standards/42829

Implement parameter and arithmetic expansion of $ENV
before using it as the name of a file from which to
read startup commands for the shell.   This continues
to happen for all interactive shells, and non-interactive
shells for which the posix option is not set (-o posix).

On any actual error, or if an attempt is made to use
command substitution, then the value of ENV is used
unchanged as the file name.

The expansion complies with POSIX XCU 2.5.3, though that
only requires parameter expansion - arithmetic expansion
is an extension (but for us, it is much easier to do, than
not to do, and it allows some weird stuff, if you're so
inclined....)   Note that there is no ~ expansion (use $HOME).

Cleanup traps a bit - attempt to handle weird uses in traps, such
as traps that issue break/continue/return to cause the loop/function
executing when the trap occurred to break/continue/return, and
generating the correct exit code from the shell including when a
signal is caught, but the trap handler for it exits.

All that from FreeBSD.

Also make
	T=$(trap)
work as it is supposed to (also trap -p).

For now this is handled by the same technique as $(jobs) - rather
than clearing the traps in subshells, just mark them invalid, and
then whenever they're invalid, clear them before executing anything
other than the special blessed "trap" command.   Eventually we will
handle these using non-subshell command substitution instead (not
creating a subshell environ when the commands in a command-sub alter
nothing in the environment).

When forking a child shell, arrange for errors/exit to always unwind
to the main handler, rather than wherever the parent shell would go.

nb: not needed for vfork(), after vfork() we never go that path - which
is good or we'd be corrupting the parent's handler.

This allows the child to always exit (when it should) rather than being
caught up doing something else (and while it would eventually exit, the
status would be incorrect in some cases).

One test is:
	sh -c 'trap "(! :) && echo BUG || echo nobug" EXIT'
from Martijn Dekker

Fix from FreeBSD (missed earlier).

XXX - 2b part of the 48875 pullup to -8

Sync with HEAD

Resolve a couple of conflicts (result of the uimin/uimax changes)

Pull up following revision(s) (requested by kre in ticket #983):

	bin/sh/eval.c: revision 1.158
	bin/sh/eval.h: revision 1.21
	bin/sh/main.c: revision 1.74

PR bin/48875

Revert the changes that were made 19 May 2016 (principally eval.c 1.125)
and the bug fixes in subsequent days (eval.c 1.126 and 1.127) and also
update some newer code that was added more recently which acted in
accordance with those changes (make that code be as it would have been
if the changes now being reverted had never been made).

While the changes made did solve the problem, in a sense, they were
never correct (see the PR for some discussion) and it had always been
intended that they be reverted.   However, in practical sh code, no
issues were reported - until just recently - so nothing was done,
until now...

After this commit, the validate_fn_redirects test case of the sh ATF
test t_redir will fail.   In particular, the subtest of that test
case which is described in the source (of the test) as:

	This one is the real test for PR bin/48875

will fail.

Alternative changes, not to "fix" the problem in the PR, but to
often avoid it will be coming very soon - after which that ATF
test will succeed again.

XXX pullup-8

Fix (hopefully) the problem reported on current-users by Patrick Welche.
we had incorrect usage of setstackmark()/popstackmark()

There was an ancient idiom (imported from CSRG in 1993) where code
can do:
	setstackmark(&smark); loop until whatever condition {
		/* do lots of code */ popstackmark(&smark);
	} popstackmark(&smark);

The 1st (inner) popstackmark() resets the stack, conserving memory,
The 2nd one is needed just in case the "whatever condition" was never
true, and the first one was never executed.

This is (was) safe as all popstackmark() did was reset the stack.
That could be done over and over again with no harm.

That is, until 2000 when a fix from FreeBSD for another problem was
imported.  That connected all the stack marks as a list (so they can be
located).  That caused the problem, as the idiom was not changed, now
there is this list of marks, and popstackmark() was removing an entry.

It rarely (never?) caused any problems as the idiom was rarely used
(the shell used to do loops like above, mostly, without the inner
popstackmark()).  Further, the stack mark list is only ever used when
a memory block is realloc'd.

That is, until last weekend - with the recent set of changes.

Part of that copied code from FreeBSD introduced the idiom above
into more functions - functions used much more, and with a greater
possibility of stack marks being set on blocks that are realloc'd
and so cause the problem.   In the FreeBSD code, they changed the idiom,
and always do a setstackmark() immediately after the inner popstackmark().
But not for reasons related to a list of stack marks, as in the
intervening period, FreeBSD deleted that, but for another reason.

We do not have their issue, and I did not believe that their
updated idiom was needed (I did some analysis of exactly this issue -
just missed the important part!), and just continued using the old one.
Hence Patrick's core dump....

The solution used here is to split popstackmark() into 2 halves,
popstackmark() continues to do what it has (recently) done,
but is now implemented as a call of (a new func) rststackmark()
which does all the original work of popstackmark - but not removing
the entry from the stack mark list (which remains in popstackmark()).
Then in the idiom above, the inner popstackmark() turns into a call of
rststackmark() so the stack is reset, but the stack mark list is
unchanged.  Tail recursion elimination makes this essentially free.

PR bin/48875 (is related, and ameliorated, but not exactly "fixed")

Import a whole set of tree evaluation enhancements from FreeBSD.

With these, before forking, the shell predicts (often) when all it will
have to do after forking (in the parent) is wait for the child and then
exit with the status from the child, and in such a case simply does not
fork, but rather allows the child to take over the parent's role.

This turns out to handle the particular test case from PR bin/48875 in
such a way that it works as hoped, rather than as it did (the delay there
was caused by an extra copy of the shell hanging around waiting for the
background child to complete ... and keeping the command substitution
stdout open, so the "real" parent had to wait in case more output appeared).

As part of doing this, redirection processing for compound commands gets
moved out of evalsubshell() and into a new evalredir(), which allows us
to properly handle errors occurring while performing those redirects,
and not mishandle (as in simply forget) fd's which had been moved out
of the way temporarily.

evaltree() has its degree of recursion reduced by making it loop to
handle the subsequent operation: that is instead of (for any binop
like ';' '&&' (etc)) where it used to
	evaltree(node->left);
	evaltree(node->right);
	return;
it now does (kind of)
	next = node;
	while ((node = next) != NULL) {
		next = NULL;

		if (node is a binary op) {
			evaltree(node->left);
			if appropriate /* if && test for success, etc */
				next = node->right;
			continue;
		}
		/* similar for loops, etc */
	}
which can be a good saving, as while the left side (now) tends to be
(usually) a simple (or simpleish) command, the right side can be many
commands (in a command sequence like a; b; c; d; ...  the node at the
top of the tree will now have "a" as its left node, and the tree for
b; c; d; ... as its right node - until now everything was evaluated
recursively so it made no difference, and the tree was constructed
the other way).

if/while/... statements are done similarly, recurse to evaluate the
condition, then if the (or one of the) body parts is to be evaluated,
set next to that, and loop (previously it recursed).

There is more to do in this area (particularly in the way that case
statements are processed - we can avoid recursion there as well) but
that can wait for another day.

While doing all of this we keep much better track of when the shell is
just going to exit once the current tree is evaluated (with a new
predicate at_eof() to tell us that we have, for sure, reached the end
of the input stream, that is, this shell will, for certain, not be reading
more command input) and use that info to avoid unneeded forks.   For that
we also need another new predicate (have_traps()) to determine of there
are any caught traps which might occur - if there are, we need to remain
to (potentially) handle them, so these optimisations will not occur (to
make the issue in PR 48875 appear again, run the same code, but with a
trap set to execute some code when a signal (or EXIT) occurs - note that
the trap must be set in the appropriate level of sub-shell to have this
effect, any caught traps are cleared in a subshell whenever one is created).

There is still work to be done to handle traps properly, whatever
weirdness they do (some of which is related to some of this.)

These changes do not need man page updates, but 48875 does - an update
to sh.1 will be forthcoming once it is decided what it should say...

Once again, all the heavy lifting for this set of changes comes directly
(with thanks) from the FreeBSD shell.

XXX pullup-8 (but not very soon)

PR bin/48875

Revert the changes that were made 19 May 2016 (principally eval.c 1.125)
and the bug fixes in subsequent days (eval.c 1.126 and 1.127) and also
update some newer code that was added more recently which acted in
accordance with those changes (make that code be as it would have been
if the changes now being reverted had never been made).

While the changes made did solve the problem, in a sense, they were
never correct (see the PR for some discussion) and it had always been
intended that they be reverted.   However, in practical sh code, no
issues were reported - until just recently - so nothing was done,
until now...

After this commit, the validate_fn_redirects test case of the sh ATF
test t_redir will fail.   In particular, the subtest of that test
case which is described in the source (of the test) as:
	This one is the real test for PR bin/48875
will fail.

Alternative changes, not to "fix" the problem in the PR, but to
often avoid it will be coming very soon - after which that ATF
test will succeed again.

XXX pullup-8

drop main() prototype

Pull up following revision(s) (requested by kre in ticket #103):
	bin/kill/kill.c: 1.28
	bin/sh/Makefile: 1.111-1.113
	bin/sh/arith_token.c: 1.5
	bin/sh/arith_tokens.h: 1.2
	bin/sh/arithmetic.c: 1.3
	bin/sh/arithmetic.h: 1.2
	bin/sh/bltin/bltin.h: 1.15
	bin/sh/cd.c: 1.49-1.50
	bin/sh/error.c: 1.40
	bin/sh/eval.c: 1.142-1.151
	bin/sh/exec.c: 1.49-1.51
	bin/sh/exec.h: 1.26
	bin/sh/expand.c: 1.113-1.119
	bin/sh/expand.h: 1.23
	bin/sh/histedit.c: 1.49-1.52
	bin/sh/input.c: 1.57-1.60
	bin/sh/input.h: 1.19-1.20
	bin/sh/jobs.c: 1.86-1.87
	bin/sh/main.c: 1.71-1.72
	bin/sh/memalloc.c: 1.30
	bin/sh/memalloc.h: 1.17
	bin/sh/mknodenames.sh: 1.4
	bin/sh/mkoptions.sh: 1.3-1.4
	bin/sh/myhistedit.h: 1.12-1.13
	bin/sh/nodetypes: 1.16-1.18
	bin/sh/option.list: 1.3-1.5
	bin/sh/parser.c: 1.133-1.141
	bin/sh/parser.h: 1.22-1.23
	bin/sh/redir.c: 1.58
	bin/sh/redir.h: 1.24
	bin/sh/sh.1: 1.149-1.159
	bin/sh/shell.h: 1.24
	bin/sh/show.c: 1.43-1.47
	bin/sh/show.h: 1.11
	bin/sh/syntax.c: 1.4
	bin/sh/syntax.h: 1.8
	bin/sh/trap.c: 1.41
	bin/sh/var.c: 1.56-1.65
	bin/sh/var.h: 1.29-1.35
An initial attempt at implementing LINENO to meet the specs.
Aside from one problem (not too hard to fix if it was ever needed) this version
does about as well as most other shell implementations when expanding
$((LINENO)) and better for ${LINENO} as it retains the "LINENO hack" for the
latter, and that is very accurate.
Unfortunately that means that ${LINENO} and $((LINENO)) do not always produce
the same value when used on the same line (a defect that other shells do not
share - aside from the FreeBSD sh as it is today, where only the LINENO hack
exists and so (like for us before this commit) $((LINENO)) is always either
0, or at least whatever value was last set, perhaps by
	LINENO=${LINENO}
which does actually work ... for that one line...)
This could be corrected by simply removing the LINENO hack (look for the string
LINENO in parser.c) in which case ${LINENO} and $((LINENO)) would give the
same (not perfectly accurate) values, as do most other shells.
POSIX requires that LINENO be set before each command, and this implementation
does that fairly literally - except that we only bother before the commands
which actually expand words (for, case and simple commands).   Unfortunately
this forgot that expansions also occur in redirects, and the other compound
commands can also have redirects, so if a redirect on one of the other compound
commands wants to use the value of $((LINENO)) as a part of a generated file
name, then it will get an incorrect value.  This is the "one problem" above.
(Because the LINENO hack is still enabled, using ${LINENO} works.)
This could be fixed, but as this version of the LINENO implementation is just
for reference purposes (it will be superseded within minutes by a better one)
I won't bother.  However should anyone else decide that this is a better choice
(it is probably a smaller implementation, in terms of code & data space then
the replacement, but also I would expect, slower, and definitely less accurate)
this defect is something to bear in mind, and fix.
This version retains the *BSD historical practice that line numbers in functions
(all functions) count from 1 from the start of the function, and elsewhere,
start from 1 from where the shell started reading the input file/stream in
question.  In an "eval" expression the line number starts at the line of the
"eval" (and then increases if the input is a multi-line string).
Note: this version is not documented (beyond as much as LINENO was before)
hence this slightly longer than usual commit message.
A better LINENO implementation.   This version deletes (well, #if 0's out)
the LINENO hack, and uses the LINENO var for both ${LINENO} and $((LINENO)).
(Code to invert the LINENO hack when required, like when de-compiling the
execution tree to provide the "jobs" command strings, is still included,
that can be deleted when the LINENO hack is completely removed - look for
refs to VSLINENO throughout the code.  The var funclinno in parser.c can
also be removed, it is used only for the LINENO hack.)
This version produces accurate results: $((LINENO)) was made as accurate
as the LINENO hack made ${LINENO} which is very good.  That's why the
LINENO hack is not yet completely removed, so it can be easily re-enabled.
If you can tell the difference when it is in use, or not in use, then
something has broken (or I managed to miss a case somewhere.)
The way that LINENO works is documented in its own (new) section in the
man page, so nothing more about that, or the new options, etc, here.
This version introduces the possibility of having a "reference" function
associated with a variable, which gets called whenever the value of the
variable is required (that's what implements LINENO).  There is just
one function pointer however, so any particular variable gets at most
one of the set function (as used for PATH, etc) or the reference function.
The VFUNCREF bit in the var flags indicates which func the variable in
question uses (if any - the func ptr, as before, can be NULL).
I would not call the results of this perfect yet, but it is close.
Unbreak (at least) i386 build .... I have no idea why this built for me on
amd64 (problem was missing prototype for snprintf witout <stdio.h>)
While here, add some (DEBUG mode only) tracing that proved useful in
solving another problem.
Set the line number before expanding args, not after.   As the line_number
would have usually been set earlier, this change is mostly an effective
no-op, but it is better this way (just in case) - not observed to have
caused any problems.
Undo some over agressive fixes for a (pre-commit) bug that did not
need these changes to be fixed - and these cause problems in another
absurd use case.   Either of these issues is unlikely to be seen by
anyone who isn't an idiot masochist...
PR bin/52280
removescapes_nl in expari() even when not quoted,
CRTNONL's appear regardless of quoting (unlike CTLESC).
New sentence, new line. Whitespace.
Improve the (new) LINENO section, markup changes (with thanks to wiz@ for
assistace) and some better wording in a few placed.
I am an idiot...  revert the previous unintended commit.
Remove some left over baggage from the LINENO v1 implementation that
didn't get removed with v2, and should have.   This would have had
(I think, without having tested it) one very minor effect on the way
LINENO worked in the v2 implementation, but my guess is it would have
taken a long time before anyone noticed...
Correct spelling in comments of DEBUG only code...
(Perhaps) temporary fix to pkgtools (cwrappers) build (configure).
Expanding  `` containing \ \n sequences looks to have been giving
problems.   I don't think this is the correct fix, but it will do
no worse harm than (perhaps) incorrectly calculating LINENO in this
kind of (rare) circumstance.   I'll look and see if there should be
a better fix later.
s/volatile/const/ -- wonderful how opposites attract like this.
NFC (normal use) - DEBUG only change, when showing empty arg list don't
omit terminating \n.
Free stack memory in a couple of obscure cases where it wasn't
being done (one in probably dead code that is never compiled, the other
in a very rare error case.)   Since it is stack memory it wasn't lost
in any case, just held longer than needed.
Many internal memory management type fixes.
PR bin/52302   (core dump with interactive shell, here doc and error
on same line) is fixed.   (An old bug.)
echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )"
consistently prints 1002 lines (x, 1000 empty ones, then y) as it should
(And you don't want to know what it did before, or why.) (Another old one.)
(Recently added) Problems with ~ expansion fixed (mem management related).
Proper fix for the cwrappers configure problem (which includes the quick
fix that was done earlier, but extends upon that to be correct). (This was
another newly added problem.)
And the really devious (and rare) old bug - if STACKSTRNUL() needs to
allocate a new buffer in which to store the \0, calculate the size of
the string space remaining correctly, unlike when SPUTC() grows the
buffer, there is no actual data being stored in the STACKSTRNUL()
case - the string space remaining was calculated as one byte too few.
That would be harmless, unless the next buffer also filled, in which
case it was assumed that it was really full, not one byte less, meaning
one junk char (a nul, or anything) was being copied into the next (even
bigger buffer) corrupting the data.
Consistent use of stalloc() to allocate a new block of (stack) memory,
and grabstackstr() to claim a block of (stack) memory that had already
been occupied but not claimed as in use.  Since grabstackstr is implemented
as just a call to stalloc() this is a no-op change in practice, but makes
it much easier to comprehend what is really happening.  Previous code
sometimes used stalloc() when the use case was really for grabstackstr().
Change grabstackstr() to actually use the arg passed to it, instead of
(not much better than) guessing how much space to claim,
More care when using unstalloc()/ungrabstackstr() to return space, and in
particular when the stack must be returned to its previous state, rather than
just returning no-longer needed space, neither of those work.  They also don't
work properly if there have been (really, even might have been) any stack mem
allocations since the last stalloc()/grabstackstr().   (If we know there
cannot have been then the alloc/release sequence is kind of pointless.)
To work correctly in general we must use setstackmark()/popstackmark() so
do that when needed.  Have those also save/restore the top of stack string
space remaining.
	[Aside: for those reading this, the "stack" mentioned is not
	in any way related to the thing used for maintaining the C
	function call state, ie: the "stack segment" of the program,
	but the shell's internal memory management strategy.]
More comments to better explain what is happening in some cases.
Also cleaned up some hopelessly broken DEBUG mode data that were
recently added (no effect on anyone but the poor semi-human attempting
to make sense of it...).
User visible changes:
Proper counting of line numbers when a here document is delimited
by a multi-line end-delimiter, as in
	cat << 'REALLY
	END'
	here doc line 1
	here doc line 2
	REALLY
	END
(which is an obscure case, but nothing says should not work.)  The \n
in the end-delimiter of the here doc (the last one) was not incrementing
the line number, which from that point on in the script would be 1 too
low (or more, for end-delimiters with more than one \n in them.)
With tilde expansion:
	unset HOME; echo ~
changed to return getpwuid(getuid())->pw_home instead of failing (returning ~)
POSIX says this is unspecified, which makes it difficult for a script to
compensate for being run without HOME set (as in env -i sh script), so
while not able to be used portably, this seems like a useful extension
(and is implemented the same way by some other shells).
Further, with
	HOME=; printf %s ~
we now write nothing (which is required by POSIX - which requires ~ to
expand to the value of $HOME if it is set) previously if $HOME (in this
case) or a user's directory in the passwd file (for ~user) were a null
STRING, We failed the ~ expansion and left behind '~' or '~user'.
Changed the long name for the -L option from lineno_fn_relative
to local_lineno as the latter seemed to be marginally more popular,
and perhaps more importantly, is the same length as the peviously
existing quietprofile option, which means the man page indentation
for the list of options can return to (about) what it was before...
(That is, less indented, which means more data/line, which means less
lines of man page - a good thing!)
Cosmetic changes to variable flags - make their values more suited
to my delicate sensibilities...  (NFC).
Arrange not to barf (ever) if some turkey makes _ readonly.  Do this
by adding a VNOERROR flag that causes errors in var setting to be
ignored (intended use is only for internal shell var setting, like of "_").
(nb: invalid var name errors ignore this flag, but those should never
occur on a var set by the shell itself.)
From FreeBSD: don't simply discard memory if a variable is not set for
any reason (including because it is readonly) if the var's value had
been malloc'd.  Free it instead...
NFC - DEBUG changes, update this to new TRACE method.
KNF - white space and comment formatting.
NFC - DEBUG mode only change - convert this to the new TRACE() format.
NFC - DEBUG mode only change - complete a change made earlier (marking
the line number when included in the trace line tag to show whether it
comes from the parser, or the elsewhere as they tend to be quite different).
Initially only one case was changed, while I pondered whether I liked it
or not.  Now it is all done...   Also when there is a line tag at all,
always include the root/sub-shell indicator character, not only when the
pid is included.
NFC: DEBUG related comment change - catch up with reality.
NFC: DEBUG mode only change.  Fix botched cleanup of one TRACE().
"b" more forgiving when sorting options to allow reasonable (and intended)
flexibility in option.list format.   Changes nothing for current option.list.
Now that excessive use of STACKSTRNUL has served its purpose (well, accidental
purpose) in exposing the bug in its implementation, go back to not using
it when not needed for DEBUG TRACE purposes.   This change should have no
practical effect on either a DEBUG shell (where the STACKSTRNUL() calls
remain) or a non DEBUG shell where they are not needed.
Correct the initial line number used for processing -c arg strings.
(It was inheriting the value from end of profile file processing) - I didn't
notice before as I usually test with empty or no profile files to avoid
complications.   Trivial change which should have very limited impact.
Fix from FreeBSD (applied there in July 2008...)
Don't dump core with input like sh -c 'x=; echo >&$x' - that is where
the word after a >& or <& redirect expands to nothing at all.
Another fix from FreeBSD (this one from April 2009).
When processing a string (as in eval, trap, or sh -c) don't allow
trailing \n's to destroy the exit status of the last command executed.
That is:
	sh -c 'false
	'
	echo $?
should produce 1, not 0.
It is amazing what nonsense appears to work sometimes... (all my nonsense too!)
Two bugs here, one benign because of the way the script is used.
The other hidden by NetBSD's sort being stable, and the data not really
requiring sorting at all...
So as it happens these fixes change nothing, but they are needed anyway.
(The contents of the generated file are only used in DEBUG shells, so
this is really even less important than it seems.)
Another ancient (highly improbable) bug bites the dust.   This one
caused by incorrect macro usage (ie: using the wrong one) which has
been in the sources since version 1.1 (ie: forever).
Like the previous (STACKSTRNUL) bug, the probability of this one
actually occurring has been infinitesimal but the LINENO code increases
that to infinitesimal and a smidgen... (or a few, depending upon usage).
Still, apparently that was enough, Kamil Rytarowski discovered that the
zsh configure script (damn competition!) managed to trigger this problem.
source .editrc after we initialize so that commands persist!
Make arg parsing in kill POSIX compatible with POSIX (XBD 2.12) by
parsing the way getopt(3) would, if only it could handle the (required)
-signumber and -signame options.  This adds two "features" to kill,
-ssigname and -lstatus now work (ie: one word with all of the '-', the
option letter, and its value) and "--" also now works (kill -- -pid1 pid2
will not attempt to send the pid1 signal to pid2, but rather SIGTERM
to the pid1 process group and pid2).  It is still the case that (apart
from --) at most 1 option is permitted (-l, -s, -signame, or -signumber.)
Note that we now have an ambiguity, -sname might mean "-s name" or
send the signal "sname" - if one of those turns out to be valid, that
will be accepted, otherwise the error message will indicate that "sname"
is not a valid signal name, not that "name" is not.   Keeping the "-s"
and signal name as separate words avoids this issue.
Also caution: should someone be weird enough to define a new signal
name (as in the part after SIG) which is almost the same name as an
existing name that starts with 'S' by adding an extra 'S' prepended
(eg: adding a SIGSSYS) then the ambiguity problem becomes much worse.
In that case "kill -ssys" will be resolved in favour of the "-s"
flag being used (the more modern syntax) and would send a SIGSYS, rather
that a SIGSSYS.    So don't do that.
While here, switch to using signalname(3) (bye bye NSIG, et. al.), add
some constipation, and show a little pride in formatting the signal names
for "kill -l" (and in the usage when appropriate -- same routine.)   Respect
COLUMNS (POSIX XBD 8.3) as primary specification of the width (terminal width,
not number of columns to print) for kill -l, a very small value for COLUMNS
will cause kill -l output to list signals one per line, a very large
value will cause them all to be listed on one line.) (eg: "COLUMNS=1 kill -l")
TODO: the signal printing for "trap -l" and that for "kill -l"
should be switched to use a common routine (for the sh builtin versions.)
All changes of relevance here are to bin/kill - the (minor) changes to bin/sh
are only to properly expose the builtin version of getenv(3) so the builtin
version of kill can use it (ie: make its prototype available.)
Properly support EDITRC - use it as (naming) the file when setting
up libedit, and re-do the config whenever EDITRC is set.
Get rid of workarounds for ancient groff html backend.
Simplify macro usage.
Make one example more like a real world possibility (it still isn't, but
is closer) - though the actual content is irrelevant to the point being made.
Add literal prompt support this allows one to do:
CA="$(printf '\1')"
PS1="${CA}$(tput bold)${CA}\$${CA}$(tput sgr0)${CA} "
Now libedit supports embedded mode switch sequence, improve sh
support for them (adds PSlit variable to set the magic character).
NFC: DEBUG only change - provide an externally visible (to the DEBUG sh
internals) interface to one of the internal (private to trace code) functions
Include redirections in trace output from "set -x"
Implement PS1, PS2 and PS4 expansions (variable expansions, arithmetic
expansions, and if enabled by the promptcmds option, command substitutions.)
Implement a bunch of new shell environment variables. many mostly useful
in prompts when expanded at prompt time, but all available for general use.
Many of the new ones are not available in SMALL shells (they work as normal
if assigned, but the shell does not set or use them - and there is no magic
in a SMALL shell (usually for install media.))
Omnibus manual update for prompt expansions and new variables.  Throw in
some random cleanups as a bonus.
Correct a markup typo (why did I not see this before the prev commit??)
Sort options (our default is 0..9AaBbZz).
Fix markup problems and a typo.
Make $- list flags in the same order they appear in sh(1)
Do a better job of detecting the error in pkgsrc/devel/libbson-1.6.3's
configure script, ie: $(( which is intended to be a sub-shell in a
command substitution, but is an arith subst instead, it needs to be
written $( ( to do as intended.   Instead of just blindly carrying on to
find the missing )) somewhere, anywhere, give up as soon as we have seen
an unbalanced ')' that isn't immediately followed by another ')' which
in a valid arith subst it always would be.
While here, there has been a comment in the code for quite a while noting a
difference in the standard between the text descr & grammar when it comes to
the syntax of case statements.   Add more comments to explain why parsing it
as we do is in fact definitely the correct way (ie: the grammar wins arguments
like this...).
DEBUG and white space changes only.   Convert TRACE() calls for DEBUg mode
to the new style.   NFC (when not debugging sh).
Mostly DEBUG and white space changes.   Convert DEEBUG TRACE() calls to
the new format.   Also #if 0 a function definition that is used nowhere.
While here, change the function of pushfile() slightly - it now sets
the buf pointer in the top (new) input descriptor to NULL, instead of
simply leaving it - code that needs a buffer always (before and after)
must malloc() one and assign it after the call.  But code which does not
(which will be reading from a string or similar) now does not have to
explicitly set it to NULL (cleaner interface.)   NFC intended (or observed.)
DEBUG changes: convert DEBUG TRACE() calls to new format.
ALso, cause exec failures to always cause the shell to exit with
status 126 or 127, whatever the cause.  127 is intended for lookup
failures (and is used that way), 126 is used for anything else that
goes wrong (as in several other shells.)  We no longer use 2 (more easily
confused with an exit status of the command exec'd) for shell exec failures.
DEBUG only changes.  Convert the TRACE() calls in the remaining files
that still used it to the new format.   NFC.
Fix a reference after free (and consequent nonsense diagnostic for
attempts to set readonly variables) I added in 1.60 by incompletely
copying the FreeBSD fix for the lost memory issue.

DEBUG only changes.  Convert the TRACE() calls in the remaining files
that still used it to the new format.   NFC.

Correct the initial line number used for processing -c arg strings.

(It was inheriting the value from end of profile file processing) - I didn't
notice before as I usually test with empty or no profile files to avoid
complications.   Trivial change which should have very limited impact.

More DEBUG mode changes.   As usual, read the source if you care.

Resolve conflicts from previous merge (all resulting from $NetBSD
keywork expansion)

NFC: added a minor comment (and enev then, in DEBUG code only)

Sync with HEAD

Keep track of the biggest fd used by, or available to, the user/script
and use that to control which fd's are examined by a (bare) fdflags
(with no fd args).

Usually this will mean that fdflags will no longer show the shell's
internal use fds, only user fds.

This is only a partial fix however, a user can easily discover the
shell's fd usage (eg: using fstat) and can then still use fdflags to
manipulate those fds (or even send output to them).

The shell needs to monitor its own fd usage better, and keep out of
the way of user fds - coming sometime later...

PR bin/48875 - avoid holding (replaced) file descriptors open when running a
command in the current shell (so they can be restored for the next command)
in cases where it is obvious that there is not going to be a following
command to use them.   This fixes the problem reported in the PR (though
there are still plenty of situations where a FD could be closed but isn't,
we do not do full fd flow eveluation to determine whether a fd will be
used or not).

This is the change that was just committed and then backed out again...

OK christos@

Revert previous.   These changes are intended to get made (and will
be in a minute or two) but not as part of that commit...   The log
entry certainly does not apply.

Finish the fd reassignment fixes from 1.43 and 1.45 ... if we are moving
a fd to an unspecified high fd number, we certainly do not want to hand
that high fd off to other processes after an exec, so always set close-on-exec
on the result (even if lack of fd's means no fd alteration happens.)
This will (eventually) allow some other code that sets close-on-exec to
be removed, but for now, doing it twice won't hurt.   Also, in a N>&M
type redirection, do not set close-on-exec if we don't want it.

OK christos@

Implement the NETBSD_SHELL readonly unexportable unimportable
variable (with its current value set at 20160401) as discussed on
current-users and tech-userlevel. This also includes the necessary
support to implement it properly (particularly the unexportable
part) and adds options to the export command to support unexportable
variables. Also implement the "posix" option (no single letter
equivalent) which gets its default value from whether or not
POSIXLY_CORRECT is set in the environment when the shell starts
(but can be changed just like any other option using -o and +o on
the command line, or the set builtin command.) While there, fix
all uses of options so it is possible to have options that have a
short (one char) name, and no long name, just as it has been possible
to have options with a long name and no short name, though there
are currently none (with no long name).  For now, the only use of
the posix option is to control whether ${ENV} is read at startup
by a non-interactive shell, so changing it with set is not usful
- that might change in the future. (from kre@)

General KNF and source code cleanups, avoid scattering the
magic string " \t\n" all over the place, slightly improved
syntax error messages, restructured some of the code for
clarity, don't allow IFS to be imported through the environment,
and remove the (never) conditionally compiled ATTY option.
Apart from one or two syntax error messages, and ignoring IFS
if present in the environment, this is intended to have no
user visible changes. (from kre@)

Fix wrong condition in previous causing bogus 'Use "exit" to leave
shell.' messages (from kre)

Complete implementation of the noexec option (-n) including
disabling noexec, if the shell is interactive, each time that
a new command is about to be read.  Also correct the -I
(ignoreeof) option so that it only applies to interactive shells,
as required by posix. (from kre)

Improve debugging, from kre (I hooked it to the build).

Drop privileges when executed set{u,g}id unless -p is specified like other
shells do to avoid system() and popen() abuse.

Rebase to HEAD as of a few days ago.

Rebase.

PR/48843: Jarmo Jaakkola: dot commands mess up scope nesting tracking

Evaluation of commands goes completely haywire if a file containing
a break/continue/return command outside its "intended" scope is sourced
using a dot command inside its "intended" scope.  The main symptom is
not exiting from the sourced file when supposed to, leading to evaluation
of commands that were not supposed to be evaluated.  A secondary symptom
is that these extra commands are not evaluated correctly, as some of them
are skipped.  Some examples are listed in the How-To-Repeat section.

According to the POSIX standard, this is how it should work:
    dot:
        The shell shall execute commands from the file in the current
        environment.
    break:
        The break utility shall exit from the smallest enclosing for, while,
        or until loop, [...]
    continue:
        The continue utility shall return to the top of the smallest
        enclosing for, while, or until loop, [...]
    return:
        The return utility shall cause the shell to stop executing
        the current function or dot script.  If the shell is not currently
        executing a function or dot script, the results are unspecified.

It is clear that return should return from a sourced file, which
it does not do.  Whether break and continue should work from the sourced
file might be debatable.  Because the dot command says "in the current
environment", I'd say yes.  In any case, it should not fail in weird
ways like it does now!

The problems occur with return (a) and break/continue (b) because:
    1)  dotcmd() does not record the function nesting level prior to
        sourcing the file nor does it touch the loopnest variable,
        leading to either
    2   a) returncmd() being unable to detect that it should not set
           evalskip to SKIPFUNC but SKIPFILE, or
        b) breakcmd() setting evalskip to SKIPCONT or SKIPBREAK,
        leading to
    3)  cmdloop() not detecting that it should skip the rest of
        the file, due to only checking for SKIPFILE.
The result is that cmdloop() keeps executing lines from the file
whilst evalskip is set, which is the main symptom.  Because
evalskip is checked in multiple places in eval.c, the secondary
symptom appears.
>How-To-Repeat:
Run the following script:

    printf "break\necho break1; echo break2" >break
    printf "continue\necho continue1; echo continue2" >continue
    printf "return\necho return1; echo return2" >return

    while true; do . ./break; done

    for i in 1 2; do . ./continue; done

    func() {
        . ./return
    }
    func

No output should be produced, but instead this is the result:
    break1
    continue1
    continue1
    return1

The main symptom is evident from the unexpected output and the secondary
one from the fact that there are no lines with '2' in them.
>Fix:
Here is patch to src/bin/sh to fix the above problems.  It keeps
track of the function nesting level at the beginning of a dot command
to enable the return command to work properly.

I also changed the undefined-by-standard functionality of the return
command when it's not in a dot command or function from (indirectly)
exiting the shell to being silently ignored.  This was done because
the previous way has at least one bug: the shell exits without asking
for confirmation when there are stopped jobs.

Because I read the standard to mean that break and continue should have
an effect outside the sourced file, that's how I implemented it.  For what
it's worth, this also seems to be what bash does.  Also laziness, because
this way required no changes to loopnesting tracking.  If this is not
wanted, it might make sense to move the nesting tracking to the inputfile
stack.

The patch also does some clean-up to reduce the amount of global
variables by moving the dotcmd() and the find_dot_file() functions from
main.c to eval.c and making in_function() a proper function.

Catchup with rmind-uvmplock merge.

PR/45069: Henning Petersen: Use prototypes from builtins.h .

fix faulty logic in previous change.

default to the original behavior for $ENV unless POSIXLY_CORRECT is set.

PR/42828: Richard Hansen: Don't evaluate ${ENV} if not interactive.
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03

fix -Wsign-compare issues

Remove unused global variables

Sync with wrstuden-revivesa-base-2.

Remove the \n and tabs from the __COPYRIGHT() strings.

PR/31548:  Alexander Rigbo: $PWD not set when shell starts up, before pwd
or cd get executed.

Only do certain actions when we are trully interactive, not just when we
are connected to a tty:
	1. enable editor
	2. print directory on directory change.
	3. print job messages

Fix crash when DEBUG=2, by opening the log file ASAP.  Reviewed by simonb@.

Move UCB-licensed code from 4-clause to 3-clause licence.

Patches provided by Joel Baker in PR 22249, verified by myself.

PR/19453: Christopher Richards: Call setlocale() in /bin/sh

Fixes from David Laight:
- ansification
- format of output of jobs command (etc)
- job identiers %+, %- etc
- $? and $(...)
- correct quoting of output of set, export -p and readonly -p
- differentiation between nornal and 'posix special' builtins
- correct behaviour (posix) for errors on builtins and special builtins
- builtin printf and kill
- set -o debug (if compiled with DEBUG)
- cd src obj (as ksh - too useful to do without)
- unset -e name, remove non-readonly variable from export list.
  (so I could unset -e PS1 before running the test shell...)

Revert previous change. No need to save rootshell. It is only affecting
the non-vfork case. Having said that, it would be nice if pipelines of
simple commands were vforked too. Right now they are not.
Explain that setpgid() might fail because we are doing it both in the
parent and the child case, because we don't know which one will come
first.
Suspending a pipeline prints %1 Suspended n times where n is the number
of processes, but that was there before. It is easy to fix, but I'll
leave the code alone for now.

Deal with rootshell not being maintained correctly in the vfork() case.
Propagate isroot, throughout the eval process and maintain it properly.
Fixes sleep 10 | cat^C not exiting because sleep and cat ended up in
their own process groups, because wasroot was always true in the children.

VFork()ing shell: From elric@netbsd.org:
Plus my changes:
	- walking process group fix in foregrounding a job.
	- reset of process group in parent shell if interrupted before the wait.
	- move INTON lower in the dowait so that the job structure is
	  consistent.
	- error check all setpgid(), tcsetpgrp() calls.
	- eliminate unneeded strpgid() call.
	- check that we don't belong in the process group before we try to
	  set it.

Doing the vfork work on ash on a branch to try to shake out the
problems before I expose everyone to them.  This checkin represents
a merge of the prior work, which I backed out a while ago, to the
HEAD only and does not incorporate any additional bugfixes.  The
additional bugfixes and code-cleanup will occur in later checkins.

For reference the patches that were used are:
cvs diff -kk -r1.51 -r1.55 eval.c  | patch
cvs diff -kk -r1.27 -r1.28 exec.c  | patch
cvs diff -kk -r1.15 -r1.16 exec.h  | patch
cvs diff -kk -r1.32 -r1.33 input.c | patch
cvs diff -kk -r1.10 -r1.11 input.h | patch
cvs diff -kk -r1.32 -r1.35 jobs.c  | patch
cvs diff -kk -r1.9  -r1.11 jobs.h  | patch
cvs diff -kk -r1.36 -r1.37 main.c  | patch
cvs diff -kk -r1.20 -r1.21 redir.c | patch
cvs diff -kk -r1.10 -r1.11 redir.h | patch
cvs diff -kk -r1.10 -r1.12 shell.h | patch
cvs diff -kk -r1.22 -r1.23 trap.c  | patch
cvs diff -kk -r1.12 -r1.13 trap.h  | patch
cvs diff -kk -r1.23 -r1.24 var.c   | patch
cvs diff -kk -r1.16 -r1.17 var.h   | patch

All other changes were simply the resolution of the resulting
conflicts, which occured only in the merge of jobs.c.

Begins to address PR: bin/5475

Fix various misspellings of compatible/compatibility.

remove redundant declarations and nexted externs.

Pullup 1.39 [hubertf]:
Fixes PR 11283.

PR/11283: Hubert Feyrer: random memory corruption executing commands:
Fix from FreeBSD:

    growstackblock() sometimes relocates a stack_block considered empty
    without properly relocating stack marks referencing that block.
    The first call to popstackmark() with the unrelocated stack mark
    as argument then causes sh to abort.

    Relocating the relevant stack marks seems to solve this problem.

    The patch changes the semantics of popstackmark() somewhat.  It can
    only be called once after a call to setstackmark(), thus cmdloop() in
    main.c needs an extra call to setstackmark().

Back out previous vfork changes.

Now we use vfork(2) instead of fork(2) when we can.

Include <errno.h> instead of using "extern int errno;".

Fix bin/9184, bin/9194, bin/9265, bin/9266
Exitcode and negation problems (From Martin Husemann)

compile with WARNS = 2

When we execute commands from a shell script, make sure that the signals
are being caught (reported by Alexis Rosen), similar to the -c case.

#!/bin/sh
vi "$@"

^C when the script is running...

Fix the -c problem differently. We cannot just ignore SIGINT etc, otherwise
we cannot interrupt sh -c <command>

PR/1788: Shinya Taniguchi: sh -c does not setup signals properly.
[Reminded to me by Alexis Rosen -- thx!]

Add -q option, which when used with -v and/or -x, turns off the tracing
during the execution of /etc/profile, .profile and $ENV.

The builtin . (dot) command no longer sees the current working directory
even if the specified file is not in the PATH.
This change enforces security and makes it conform to POSIX.

Closes PR #6794.
I thought Christos committed this but not appeared yet. :)

The setstackmark()/popstackmark() pair in dotcmd(), used for freeing
stack storage possibly allocated by find_dot_file(), is redundant for now
since dotcmd() is surrounded by another pair in evalcommand().
This redundancy, however, may help future modifications
(suggested by Christos).

Be more retentive about use of NOTREACHED and noreturn.

Delint.

Fix compiler warnings.

Don't call getpwd() because if that fails the shell cannot start. (from scott)

Update /bin/sh from trunk per request of Christos Zoulas.  Fixes
many bugs.

PR/287: Shell does not exit with 126/127 when permission denied/
	command not found. Add extra exception type and generalize
	error handling routines to take that exception type. Use
	a global variable exerrno to keep the last exec error.

Fix PR/1760, where 'cd -' before any other command could cause a reference
to an uninitialized pointer. Use getcwd() to get the current working directory,
instead of forking /bin/pwd [per Scott's suggestion]

Fix return builtin to work like it does in ksh:
When not in a function, it skips the rest of the current input file.
Instances of `return' outside function definitions were previously ignored.
What does joe posix have to say about this?
[fixes PR/1444]

Fix bin/1240, from Dennis Ferguson. the exit builtin with no arguments
should return the exitcode of the previous command but it always returned 0.

Fixed bug where
$ cat foo
echo $FOO

$ FOO=1 . ./foo
$ echo $FOO

Did not echo 1 at all. Now variable assignments before sourced scripts
are honored during and after the execution of the script.

Changed so that syntax errors (EXERROR) set the exit status to 2,
and commands that are not found set the exit status to 1 like all
other bourne shells.
[It used to be 0 and 2 respectively]

Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0
bug.

convert to new RCS id conventions.

clean up further.  more patches from Jim Jegers

from James Jegers <jimj@miller.cs.uwm.edu>: quiet -Wall, and squelch
some of the worst style errors.

update from trunk

from trunk.

Don't source the file specified by $ENV if either the real and effective
user IDs or the real and effective group IDs of the process are different.
Thanks to Mark Weaver who pointed this out in PR 262.

Add RCS ids.

Include appropriate header files to bring function prototypes into scope.

forgot some include files

integrate NetBSD's path searching for dot files

sync with 4.4lite

44lite code

Removed theo's change to check S_ISLNK() for dot commands.  This is
unnecessary, since stat() allready resolves symlinks (and fails, if
the link is broken).

source/$PATH thing for symbolic links too, reportedly

but don't try that for absolute or relative paths

make . (source) command search $PATH as it should. from dkionka@Cadence.COM (Daniel P. Kionka)  and fixed by me

Add RCS identifiers.

changed "Id" to "Header" for rcsids

added rcs ids to all files

initial import of 386bsd-0.1 sources

Initial revision