Home | History | Annotate | Download | only in sh
History log of /src/bin/sh/var.c
RevisionDateAuthorComments
 1.88  26-Dec-2024  kre Fix a bug from when the ToD variable was added (July 2017) where if
TZ is unset, and ToD_FORMAT contains and strftime() conversions which
need to know the zone, bad things happen.

Amazing that no-one (incl me) ever noticed this.

XXX pullup -9, pullup -10 (and -8 from 8.0_RC1 onwards ... sigh)
 1.87  21-Oct-2024  kre If searching for a variable with no name, bail out faster,
that can never succeed. NFCI.
 1.86  14-Oct-2024  kre Apologies for that commit message ... it should have been the same
as for revision 1.124 of Makefile (and as below).

(This change changes nothing).

Reject nul characters in shell input.

At the request of Thomas Klausner (wiz@) copy an idea from OpenBSD,
and have the shell simply reject any (sh) input containing a \0 (nul)
character. Previously nul characters were simply ignored (removed
from the input before it was examined in any other way).

Note this affects data read by the shell itself only, and has no
impact on other utilities, including those that are built into
the shell (so 'read' can still use -d '' to process output using
\0 as the record separator).

While I have tested that this works, there are so many places
where a nul might appear, that I cannot possibly test them all
(or even imagine all the possible places), so if this change
causes any problems, let me know (if from a script, send me the
script).

To undo this change, simply comment out (or delete) the line
CPPFLAGS+= -DREJECT_NULS
from the Makefile, and build again. Eventually if this causes
no problems, that option (conditional compilation) will probably
just go away, and this change would be permanent.

While the conditional compilation (on or off) persists, the
NETBSD_SHELL variable value will contain the word REJECT_NULLS
so you can easily verify if you are running a shell with this
included or not.

No pullups planned.
 1.85  14-Oct-2024  kre # $NetBSD: Makefile,v 1.123 2023/10/19 04:27:24 mrg Exp $
# @(#)Makefile 8.4 (Berkeley) 5/5/95

.include <bsd.own.mk>

PROG= sh
SHSRCS= alias.c arith_token.c arithmetic.c cd.c echo.c error.c eval.c exec.c \
expand.c histedit.c input.c jobs.c mail.c main.c memalloc.c \
miscbltin.c mystring.c options.c parser.c redir.c show.c trap.c \
output.c var.c test.c kill.c syntax.c
GENSRCS=builtins.c init.c nodes.c
GENHDRS=builtins.h nodes.h token.h nodenames.h optinit.h
SRCS= ${SHSRCS} ${GENSRCS}

DPSRCS+=${GENHDRS}

LDADD+= -ledit -lterminfo
DPADD+= ${LIBEDIT} ${LIBTERMINFO}

# Environment for scripts executed during build.
SCRIPT_ENV= \
AWK=${TOOL_AWK:Q} \
MKTEMP=${TOOL_MKTEMP:Q} \
SED=${TOOL_SED:Q}

CPPFLAGS+=-DSHELL -I. -I${.CURDIR} -I${NETBSDSRCDIR}/lib/libedit
CPPFLAGS+= -DUSE_LRAND48
CPPFLAGS+= -DREJECT_NULS

#XXX: For testing only.
#CPPFLAGS+=-DDEBUG=1
#COPTS+=-g
#CFLAGS+=-funsigned-char
#TARGET_CHARFLAG?= -DTARGET_CHAR="unsigned char" -funsigned-char

# Reproducible build parameters ... export into sh for NETBSD_SHELL setting
.if ${MKREPRO_TIMESTAMP:Uno} != "no"
BUILD_DATE!= ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%Y%m%d%H%M%S"
# These are (should be) equivalent, but the 2nd is easier to understand
#CPPFLAGS+= -DBUILD_DATE='"${BUILD_DATE:C/([^0]0?)(00)*$/\1/}Z"'
CPPFLAGS+= -DBUILD_DATE='"${BUILD_DATE:S/00$//:S/00$//:S/00$//}Z"'
.endif

.ifdef SMALLPROG
CPPFLAGS+=-DSMALL
.endif
.ifdef TINYPROG
CPPFLAGS+=-DTINY
.else
SRCS+=printf.c
.endif

.PATH: ${.CURDIR}/bltin ${NETBSDSRCDIR}/bin/test \
${NETBSDSRCDIR}/usr.bin/printf \
${NETBSDSRCDIR}/bin/kill

CLEANFILES+= ${GENSRCS} ${GENHDRS} sh.html1
CLEANFILES+= trace.*

token.h: mktokens
${_MKTARGET_CREATE}
${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC}

.ORDER: builtins.h builtins.c
builtins.h builtins.c: mkbuiltins shell.h builtins.def
${_MKTARGET_CREATE}
${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC} ${.OBJDIR}
[ -f builtins.h ]

init.c: mkinit.sh ${SHSRCS}
${_MKTARGET_CREATE}
${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC}

.ORDER: nodes.h nodes.c
nodes.c nodes.h: mknodes.sh nodetypes nodes.c.pat
${_MKTARGET_CREATE}
${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC} ${.OBJDIR}
[ -f nodes.h ]

nodenames.h: mknodenames.sh nodes.h
${_MKTARGET_CREATE}
${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC} > ${.TARGET}

optinit.h: mkoptions.sh option.list
${_MKTARGET_CREATE}
${SCRIPT_ENV} ${HOST_SH} ${.ALLSRC} ${.TARGET} ${.OBJDIR}

.if ${USETOOLS} == "yes"
NBCOMPATLIB= -L${TOOLDIR}/lib -lnbcompat
.endif

SUBDIR.roff+=USD.doc

COPTS.printf.c = -Wno-format-nonliteral
COPTS.jobs.c = -Wno-format-nonliteral
COPTS.var.c = -Wno-format-nonliteral

# XXXGCC12 - only on some targets
COPTS.parser.c+= ${${ACTIVE_CC} == "gcc" && ${HAVE_GCC:U0} >= 12:? -Wno-error=clobbered :}

.include <bsd.prog.mk>
.include <bsd.subdir.mk>

${OBJS}: Makefile
 1.84  13-Jul-2024  kre Implement the HISTFILE and HISTAPPEND variables.

See the (newly updated) sh(1) for details.
Also add the -z option to fc (clear history).

None of this exists in SMALL shells.
 1.83  12-Jul-2024  kre Improve safety in var imports from the environment.

Add a new var flag VUNSAFE - set on all vars imported from the environment.

Add setvareqsafe() (which is to setvareq() as setvarsafe() is to setvar())
and use that instead of setvareq() when processing the environment, so
errors don't cause the shell to abort. Use VUNSAFE in that call.

Add flags arguments to all var callback functions which are used when setting
variables, and pass the flags given to the setvar*() functions to those
functions, so they can act differently in different situations (if desired).
Most of them just ignore the flags.

When unsetting a variable, call setvar() to clear things (and call the
callback function) both when the variable had a value which needs to be freed,
and when unsetting a variable which wasn't unset previously, so the VUNSET
flag can be seen by that callback func.

When setting HISTSIZE, use the flags passed to determine whether to ignore
bad values (if VUNSAFE) or treat them as an error. This replaces the
earlier temporary hack to always ignore bad data there (histedit.c 1.68).

Miscellaneous associated minor changes.

These changes should largely be invisible in normal use.
 1.82  18-Sep-2022  kre branches: 1.82.2; 1.82.4;

Oops, somehow managed to commit an older version where NBSH_INVOCATION
start char was '@' rather than '!' (which meant not lexically ordered).
This is how it was intended to be (and is documented).
 1.81  18-Sep-2022  kre 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.
 1.80  09-Aug-2021  kre Fix the fix to a typo in one of the comments.
 1.79  08-Aug-2021  andvar s/varable/variable s/explictly/explicitly/ s/proerly/properly/ in comments.
 1.78  14-Feb-2019  kre branches: 1.78.2;

Add the "specialvar" built-in command. Discussed (well, mentioned
anway) on tech-userlevel with no adverse response.

This allows the magic of vars like HOSTNAME SECONDS, ToD (etc) to be
restored should it be lost - perhaps by having a var of the same name
imported from the environment (which needs to remove the magic in case
a set of scripts are using the env to pass data, and the var name chosen
happens to be one of our magic ones).

No change to SMALL shells (or smaller) - none of the magic vars (except
LINENO, which is exempt from all of this) exist in those, hence such a
shell has no need for this command either.
 1.77  09-Feb-2019  kre DTRT when dynamically generated variables return "unset" instead of
a value. There are none which do that at the minute, so this is a NFCI
change, which is just making the code correct even though nothing
currently triggers any bugs.
 1.76  09-Feb-2019  kre INTON / INTOFF audit and cleanup.

No visible differences expected - there is a remote chance that
some internal lossage may no longer occur in interactive shells
that receive SIGINT (untrapped) at inopportune times, but you would
have had to have been very unlucky to have ever suffered from that.
 1.75  21-Jan-2019  kre Fix an off by one buffer length problem. Fortunately, it was off by
one in the "safe" way (it was ensuring the buffer always ended in 2 \0
characters ... one is enough.) This could affect the expansions of
LINENO RANDOM and SECONDS, though only if they have at least 8 digits
(and then, only sometimes). RANDOM thus is safe, as it never produces
a number with more than 5 digits, you'd need a script with 10000000
lines before there might be an issue with LINENO (and even autoconf
generated scripts don't generally get that bit) and a shell would need
to be running for almost 4 months for SECONDS to climb that high.

Nevertheless: XXX pullup -8.
 1.74  12-Dec-2018  kre Implement:
readonly -q VAR...
readonly -p VAR...
export -q [-x] VAR...
export -p [-x] VAR...

all available only in !SMALL shells - and while here, limit
"export -x" to full sized shells as well.

Also, do a better job of arg checking and validating of the
export and readonly commands (which is really just one built-in)
and of issuing error messages when something bogus is detected.

Since these commands are special builtin commands, any error
causes shell exit (for non-interactive shells).
 1.73  12-Dec-2018  kre Fix a botch made in 1.70 (a bit over a week ago) where
var=foo; readonly var=new
now fails.

If var was already set, an attempt to make it readonly, and assign it
a new value at the same time, failed - the readonly flag was set too soon.

Pointed out by Martijn Dekker (thanks).

Also, while here, add a couple of comments.
 1.72  04-Dec-2018  kre Alter a design botch when magic (self modifying) variables
were added to sh ... in other shells, setting such a variable
(for most of them) causes it to lose its special properties,
and act the same as any other variable. I had assumed that
was just implementor laziness... I was wrong.

From now on the NetBSD shell will act like the others, and if vars
like HOSTNAME (and SECONDS, etc) are used as variables in a script
or whatever, they will act just like normal variables (and unless
this happens when they have been made local, or as a variable-assignment
as a prefix to a command, the special properties they would have had
otherwise are lost for the remainder of the life of the (sub-)shell
in which the variables were set).

Importing a value from the environment counts as setting the
value for this purpose (so if HOSTNAME is set in the environment,
the value there will be the value $HOSTNAME expands to).

The two exceptions to this are LINENO and RANDOM. RANDOM
needs to be able to be set to (re-)set its seed. LINENO needs to
be able to be set (at least in the "local" command) to achieve
the desired functionality. It is unlikely that any (sane) script
is going to want to use those two as normal vars however.

While here, fix a minor bug in popping local vars (fn return) that need
to notify the shell of changes in value (like PATH).

Change sh(1) to reflect this alteration. Also add doc of the
(forgotten) magic var EUSER (which has been there since the others
were added), and add a few more vars (which are documented
in other places in sh(1) - like ENV) into the defined or used
variable list (as well as wherever else they appear).

XXX pullup -8
 1.71  03-Dec-2018  kre Fix "export -x" (and its consequences) to behave as originally
intended (and as documented) rather than how it has been behaving
(which was not very rational.) Since it is unlikely that anyone
is using this, the change should be mostly invisible.

While here, a couple of other minor cleanups:
. One call of geteuid() is enough in choose_ps1()
. Fix a typo in a comment
. Improve appearance (whitspace changes) in find_var()
 1.70  13-Jul-2018  kre Remove atoi()

Mostly use number() (no longer implemented using atoi()) when an
unsigned integer is required, but use strtoXXX() when a conversion
is wanted, without the possibility or error (like setting OPTIND
and RANDOM). Always init OPTIND to 1 when sh starts (overriding
anything in environ.)
 1.69  19-Nov-2017  kre branches: 1.69.2; 1.69.4;
Implement the -X option - an apparent variant of -x which sends all trace
output to the stderr which existed when the -X option was (last) enabled.
It also enables tracing by enabling -x (and when reset, +X, also resets
the 'x' flag (+x)). Note that it is still -x/+x which actually
enables/disables the trace output. Hence "apparent variant" - what -X
actually does (aside from setting -x) is just to lock the trace output,
rather than having it follow wherever stderr is later redirected.
 1.68  28-Oct-2017  kre Extract the variable name validity test from setname() into a
function of its own. It will soon be needed from another source.
 1.67  31-Aug-2017  kre Fix a bug noticed by Soren Jacobsen running the netbsd-6-0 build.sh which
causes a core dump in some exotic circumstances (when restoring local
variables when a function returns). ("build.sh makewrapper" exposed it.)

This was introduced in 1.63 - not as part of the substance of that
change (addition) but as an unrelated "must be the right thing to do"
cleanup, which wasn't...
 1.66  24-Jul-2017  kre NFC: DEBUG mode only change - add a little more tracing.
 1.65  12-Jul-2017  kre 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.
 1.64  05-Jul-2017  kre DEBUG only changes. Convert the TRACE() calls in the remaining files
that still used it to the new format. NFC.
 1.63  30-Jun-2017  kre 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.))
 1.62  28-Jun-2017  kre Now libedit supports embedded mode switch sequence, improve sh
support for them (adds PSlit variable to set the magic character).
 1.61  27-Jun-2017  kre Properly support EDITRC - use it as (naming) the file when setting
up libedit, and re-do the config whenever EDITRC is set.
 1.60  17-Jun-2017  kre 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...
 1.59  17-Jun-2017  kre s/volatile/const/ -- wonderful how opposites attract like this.
 1.58  07-Jun-2017  kre 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.
 1.57  07-Jun-2017  kre 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.
 1.56  07-Jun-2017  kre 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.
 1.55  27-May-2017  kre branches: 1.55.2;
More standard (and saner) implementation of the ! reserved word.
Unless the shell is compiled with the (compilation time) option
BOGUS_NOT_COMMAND (as in CFLAGS+=-DBOGUS_NOT_COMMAND) which it
will not normally be, the ! command (reserved word) will only
be permitted at the start of a pipeline (which includes the
degenerate pipeline with no '|'s in it of course - ie: a simple cmd)
and not in the middle of a pipeline sequence (no "cmd | ! cmd" nonsense.)
If the latter is really required, then "cmd | { ! cmd; }" works as
a standard equivalent.

In POSIX mode, permit only one ! ("! pipeline" is ok. "! ! pipeline" is not).
Again, if needed (and POSIX conformance is wanted) "! { ! pipeline; }"
works as an alternative - and is safer, some shells treat "! ! cmd" as
being identical to "cmd" (this one did until recently.)
 1.54  27-May-2017  kre It turns out that most shells do not do variable value/attribute
inheritance when a variable is declared local, but instead leave
the local var unset (if not given a value) in the function.
Only ash derived shells do inheritance it seems.

So, to compensate for that, and get one step closer to making
"local" part of POSIX, so we can really rely upon it, a compromise
has been suggested, where "local x" is implementation defined
when it comes to this issue, and we add "local -I x" to specify
inheritance, and "local -N x" to specify "not" (something...)
(not inherited, or not set, or whatever you prefer to imagine!)
The option names took a lot of hunting to find something reasonable
that no shell (we know of) had already used for some other purpose...
The I was easy, but 'u' 'U' 'X' ... all in use somewhere.

This implements that (well, semi-) agreement.

While here, add "local -x" (which many other shells already have)
which causes the local variable to be made exported. Not a lot
of gain in that (since "export x" can always be done immediately
after "local x") but it is very cheap to add and allows more other
scripts to work with out shell.

Note that while 'local x="${x}"' always works to specify inheritance
(while making the shell work harder), "local x; unset x" does not
always work to specify the alternative, as some shells have
"re-interpreted" unset of a local variable to mean something that
would best be described as "unlocal" instead - ie: after the unset
you might be back with the variable from the outer scope, rather
than with an unset local variable.

Also add "unset -x" to allow unsetting a variable without removing
any exported status it has.

There are gazillions of other options that are not supported here!
 1.53  14-May-2017  kre Make ${NETBSD_SHELL} value include (a human recognisable form of)
MKREPRO_TIMESTAMP (as an additional word in the value, with a "BUILD:" prefix)
if it is set during the build. (Trailing 00 pairs in the time are removed).

While here, throw in some extra words that list the compilation
options used which alter sh behaviour (mostly by removing stuff.)
Usually that will only be noticed in a SMALL shell compiled for
install media, or similar - none of the others (not that there
are many) are ever changed from the default in a normal build
(default settings are just omitted.) This also allows scripts
to tell if they are running in a DEBUG shell, which can sometimes
make debugging easier.
 1.52  10-May-2017  kre I noticed!

POSIX requires that the output of the "set" command (with no args -- it
gives a list of variables, and their values) be sorted according to
the collating sequence defined by the current locale.

Now I'm not aware of any locale where the collating sequence order of
ascii letters, digits, and '_' are any different than they are in the
C locale (and those are the only characters that can occur in variable
names - unless there is perhaps a locale that defines "dictionary" order
as the sort order) but never mind, that isn't the bug...

What "collating sequence order" does mean however, if not "collating
sequence order, except when we happen to have two variable names, where
one name is a prefix of the other (say X and XY) and the first character
of the 'Y' part of the longer name happens to be a digit..."

"set" is not a frequently used command (particularly in scripts where
it matters - that is, the no args form, nothing here alters anything
about any use of set with args) and is already a bit slow (sluggish...)
because of the sort requirement, so let's make it fractionally even
slower, but correct.
 1.51  03-May-2017  kre Make "export VAR" work correctly ... if VAR was unset before this
command it should remain unset afterwards.

Previouly "export VAR" did much the same as:
export VAR="${VAR}"
(but without the side effects if VAR had previously been VAR='~' or similar)

Also stop unset exported variables from actually making it into the
environment. Previously this was impossible - variables get exported
in just one of 3 ways, by being imported from the environ (which means
the var is set) when -a is set, and a var is given a value (so the var
is set), or using "export" which previously always set a null string
if the var was otheriwse unset.

The same happens for "readonly" (readonly and export use the same mechanism)
- except, once marked readonly, it is no longer possible to set the var, so
(assuming VAR is not already readonly)
unset VAR; readonly VAR
is (now) a way to guarantee that "VAR" can never be set.

This conforms with POISX (though it is not particularly clear on this
point) and with bash and ksh93 (and also with the FreeBSD shell, though
they export unset variables that are marked for export as if set to '')

It s not clear whether
unset VAR; readonly VAR; unset VAR; echo $?
should print 0, or non-0, so for now just leave this as it is (prints 1).
 1.50  29-Apr-2017  kre Fix several problems with the implementation of the "trap" command
(that is, with the command itself, not with the traps that are
executed, if any).

- "trap -- -l" is not rational, permit the (non-std) -l option only
when given as the sole arg (ie: "trap -l").
- "trap --" is the same as just "trap" (and -- is ignored for below)
- "trap action" generates a usage message (there must be at least one condition)
- "trap N [condition...]" (the old form with a numeric first arg, to reset
traps to default, instead of "trap - condition...") is properly detected.
In particular while "trap 1 2 3" resets sighup sigint and siquit handlers
to default, "trap hup int quit" runs the "hup" command on sigint or sigquit
and does nothing to sighup at all.
- actions can start with "-" (as can commands in general) - it may be unusual
or even unwise, but it is not prohibited, and should work
- bad conditions (signal names/numbers) are just a usage error (resulting in
non-zero "exit status" (and a diagnostic on stderr)) they do not cause
the script to abort (as a syntax error in a special builtin would.)
(so says posix, very explicitly.)
- when outputting the trap list ("trap") properly quote null actions
(ignored conditions). This has the side effect of also generating an
explicit null string ('') in other cases where null values are output,
such as when reporting var values ("set") but that's OK, and might be
better (VAR= and VAR='' mean the same, but the latter is more obvious.)

We still do not properly handle traps=$(trap) (ie: it does not work at all,
and should) but that's a different problem that needs fixing in another place.
 1.49  31-Mar-2016  christos branches: 1.49.6;
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@)
 1.48  27-Mar-2016  christos 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@)
 1.47  08-Mar-2016  christos Move the PPID installation to the init() section.
 1.46  08-Mar-2016  christos - don't export $PPID (from kre)
- include <stdio.h>
 1.45  08-Mar-2016  christos Provide $PPID, kill vvers (unused)
 1.44  26-May-2015  christos Drop privileges when executed set{u,g}id unless -p is specified like other
shells do to avoid system() and popen() abuse.
 1.43  01-Nov-2013  christos PR/48312: Dieter Roelands: According to TOG, unset should not return an error
for functions are variables that were not previously set:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
 1.42  13-Dec-2012  christos PR/47317: Henning Petersen: Replace index() with strchr()
 1.41  28-Mar-2012  christos branches: 1.41.2;
include <limits.h> for CHAR_MIN/CHAR_MAX
 1.40  18-Jun-2011  christos branches: 1.40.2; 1.40.4;
PR/45069: Henning Petersen: Use prototypes from builtins.h .
 1.39  16-Oct-2008  dholland branches: 1.39.16;
Use "extern" properly for referencing globals defined in other modules.
Now builds cleanly with -warn-common.
 1.38  18-Dec-2006  christos fix a volatile variable; from Anon Ymous
 1.37  24-Apr-2006  snj It's "its."
 1.36  06-Oct-2004  enami Fix a bug introduced by previous commit. It breaks export command
with multiple arguments if one of them are already set. Fix PR#27155
and probably PR#27143.
 1.35  02-Oct-2004  dsl Save the length of each variable in the name table so that we can
compare the lengths and then use memcmp() in the search code.
Speeds up one of my scripts by a facter of 2.
Increase the size of the variable hash table.
Cuts down time for script to execute from 60 seconds to 10.
Move variable search into a new function to hide the implementation
from most of the code, new version is slightly smaller than old.
 1.34  26-Aug-2003  jmmv Include strings.h, needed for index's prototype.
 1.33  07-Aug-2003  agc Move UCB-licensed code from 4-clause to 3-clause licence.

Patches provided by Joel Baker in PR 22249, verified by myself.
 1.32  22-Jan-2003  dsl Support command -p, -v and -V as posix
Stop temporary PATH assigments messing up hash table
Fix sh -c -e "echo $0 $*" -a x (as posix)
(agreed by christos)
 1.31  25-Nov-2002  agc Make this compile on some of the more esoteric architectures (e.g. those
which are not i386)
 1.30  24-Nov-2002  christos 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...)
 1.29  27-Sep-2002  christos 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.
 1.28  15-May-2002  bjh21 Implement sh -a (allexport). Code (all two lines of it) from FreeBSD
(FreeBSD var.c 1.13, sh.1 1.27).
 1.27  04-Feb-2001  christos branches: 1.27.2;
remove redundant declarations and nexted externs.
 1.26  20-Dec-2000  cgd __CONCAT does token pasting, not string concatnation. if something like:
__CONCAT("PATH=",_PATH_STDPATH);
actually works to concantate strings, it's because the preprocessor expands
it into "PATH=""whatever _PATH_STDPATH is" as separate strings, and then
ANSI string concatenation is performed on that. It's more straightforward
to just use ANSI string concatenation directly, and newer GCCs complain
(rightly) about mis-use of token pasting.
 1.25  22-May-2000  elric Back out previous vfork changes.
 1.24  17-May-2000  elric When vforking ensure that the environment passed to exec is built before
vforking as a set of local variables which can be popped by the parent.

Addresses bin/10124.
 1.23  09-Jul-1999  christos compile with WARNS = 2
 1.22  28-Jan-1999  kleink Add support for the export and readonly -p option.
 1.21  07-Apr-1998  fair fix default PATH to be <paths.h> _PATH_DEFPATH
 1.20  07-Apr-1998  fair Change a few things to reference /usr/include/paths.h instead of local
references. Fixing the default PATH is a bit more effort.
 1.19  04-Jul-1997  christos branches: 1.19.2;
Fix compiler warnings.
 1.18  11-Apr-1997  christos Track $TERM and call the appropriate editline(3) routine to update the
terminal type.
 1.17  14-Mar-1997  christos NO_HISTORY->SMALL
 1.16  11-Jan-1997  tls kill 'register'
 1.15  16-Oct-1996  christos PR/2808: - Don't use p++ in macros.
- Hash using unsigned numbers.
(from FreeBSD)
 1.14  25-Jun-1996  christos - Add function callback capability when variables are set.
- Add setvarsafe that returns an error instead of longjmp() to the
error code.
 1.13  11-May-1995  christos branches: 1.13.6;
Merge in my changes from vangogh, and fix the x=`false`; echo $? == 0
bug.
 1.12  21-Mar-1995  cgd convert to new RCS id conventions.
 1.11  20-Jan-1995  mycroft Remove `.' from default PATH.
 1.10  05-Dec-1994  cgd clean up further. more patches from Jim Jegers
 1.9  23-Sep-1994  mycroft Eliminate uses of some obsolete functions.
 1.8  11-Jun-1994  mycroft Add RCS ids.
 1.7  14-May-1994  cgd add back in support for building w/o obj dir. also, add NO_HISTORY
define, which (if you invoke mkbuiltins properly) gets you a sh w/o
history of command line editing (for floppy sh).
 1.6  12-May-1994  jtc Include appropriate header files to bring function prototypes into scope.
 1.5  11-May-1994  jtc sync with 4.4lite
 1.4  01-Aug-1993  mycroft Add RCS identifiers.
 1.3  23-Mar-1993  cgd changed "Id" to "Header" for rcsids
 1.2  22-Mar-1993  cgd added rcs ids to all files
 1.1  21-Mar-1993  cgd branches: 1.1.1;
Initial revision
 1.1.1.2  11-May-1994  jtc 44lite code
 1.1.1.1  21-Mar-1993  cgd initial import of 386bsd-0.1 sources
 1.13.6.1  26-Jan-1997  rat Update /bin/sh from trunk per request of Christos Zoulas. Fixes
many bugs.
 1.19.2.1  08-May-1998  mycroft Sync with trunk, per request of christos.
 1.27.2.1  27-Mar-2002  elric 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
 1.39.16.1  23-Jun-2011  cherry Catchup with rmind-uvmplock merge.
 1.40.4.1  16-Nov-2016  snj Pull up following revision(s) (requested by dholland in ticket #1412):
bin/sh/exec.c: revision 1.45
bin/sh/var.c: revision 1.43
PR/48312: Dieter Roelants: According to TOG, unset should not return an error
for functions are variables that were not previously set:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
 1.40.2.3  22-May-2014  yamt sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
 1.40.2.2  23-Jan-2013  yamt sync with head
 1.40.2.1  17-Apr-2012  yamt sync with head
 1.41.2.2  19-Aug-2014  tls Rebase to HEAD as of a few days ago.
 1.41.2.1  25-Feb-2013  tls resync with head
 1.49.6.3  19-May-2017  pgoyette Resolve conflicts from previous merge (all resulting from $NetBSD
keywork expansion)
 1.49.6.2  11-May-2017  pgoyette Sync with HEAD
 1.49.6.1  02-May-2017  pgoyette Sync with HEAD - tag prg-localcount2-base1
 1.55.2.4  07-Dec-2018  martin Pull up following revision(s) (requested by kre in ticket #1127):

bin/sh/var.h: revision 1.38 (via patch)
bin/sh/var.c: revision 1.72
bin/sh/sh.1: revision 1.211 (via patch)

Alter a design botch when magic (self modifying) variables
were added to sh ... in other shells, setting such a variable
(for most of them) causes it to lose its special properties,
and act the same as any other variable. I had assumed that
was just implementor laziness... I was wrong.

From now on the NetBSD shell will act like the others, and if vars
like HOSTNAME (and SECONDS, etc) are used as variables in a script
or whatever, they will act just like normal variables (and unless
this happens when they have been made local, or as a variable-assignment
as a prefix to a command, the special properties they would have had
otherwise are lost for the remainder of the life of the (sub-)shell
in which the variables were set).

Importing a value from the environment counts as setting the
value for this purpose (so if HOSTNAME is set in the environment,
the value there will be the value $HOSTNAME expands to).
The two exceptions to this are LINENO and RANDOM. RANDOM
needs to be able to be set to (re-)set its seed. LINENO needs to
be able to be set (at least in the "local" command) to achieve
the desired functionality. It is unlikely that any (sane) script
is going to want to use those two as normal vars however.

While here, fix a minor bug in popping local vars (fn return) that need
to notify the shell of changes in value (like PATH).
Change sh(1) to reflect this alteration. Also add doc of the
(forgotten) magic var EUSER (which has been there since the others
were added), and add a few more vars (which are documented
in other places in sh(1) - like ENV) into the defined or used
variable list (as well as wherever else they appear).

XXX pullup -8
 1.55.2.3  25-Aug-2018  martin Pull up following revision(s) (requested by kre in ticket #988):

bin/sh/parser.c: revision 1.147
bin/sh/var.c: revision 1.70
bin/sh/mystring.c: revision 1.18
bin/sh/options.c: revision 1.53
bin/sh/histedit.c: revision 1.53

Remove atoi()

Mostly use number() (no longer implemented using atoi()) when an
unsigned integer is required, but use strtoXXX() when a conversion
is wanted, without the possibility or error (like setting OPTIND
and RANDOM). Always init OPTIND to 1 when sh starts (overriding
anything in environ.)
 1.55.2.2  31-Aug-2017  martin Pull up following revision(s) (requested by kre in ticket #250):
bin/sh/var.c: revision 1.67
Fix a bug noticed by Soren Jacobsen running the netbsd-6-0 build.sh which
causes a core dump in some exotic circumstances (when restoring local
variables when a function returns). ("build.sh makewrapper" exposed it.)
This was introduced in 1.63 - not as part of the substance of that
change (addition) but as an unrelated "must be the right thing to do"
cleanup, which wasn't...
 1.55.2.1  23-Jul-2017  snj 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.
 1.69.4.3  21-Apr-2020  martin Ooops, restore accidently removed files from merge mishap
 1.69.4.2  21-Apr-2020  martin Sync with HEAD
 1.69.4.1  10-Jun-2019  christos Sync with HEAD
 1.69.2.3  26-Jan-2019  pgoyette Sync with HEAD
 1.69.2.2  26-Dec-2018  pgoyette Sync with HEAD, resolve a few conflicts
 1.69.2.1  28-Jul-2018  pgoyette Sync with HEAD
 1.78.2.1  02-Jan-2025  martin Pull up following revision(s) (requested by kre in ticket #1932):

bin/sh/var.c: revision 1.88

Fix a bug from when the ToD variable was added (July 2017) where if
TZ is unset, and ToD_FORMAT contains and strftime() conversions which
need to know the zone, bad things happen.

Amazing that no-one (incl me) ever noticed this.
 1.82.4.1  02-Aug-2025  perseant Sync with HEAD
 1.82.2.1  31-Dec-2024  snj Pull up following revision(s) (requested by kre in ticket #1034):
bin/sh/var.c: 1.88
Fix a bug from when the ToD variable was added (July 2017) where if
TZ is unset, and ToD_FORMAT contains and strftime() conversions which
need to know the zone, bad things happen.
Amazing that no-one (incl me) ever noticed this.

RSS XML Feed