Revert a part of a change made on 1999-07-09 (in rev 1.21).

That change ("compile with WARNS = 2") added "const" qualifiers
in many places.

One of them, in this file, became a const char *, which n

Revert a part of a change made on 1999-07-09 (in rev 1.21).

That change ("compile with WARNS = 2") added "const" qualifiers
in many places.

One of them, in this file, became a const char *, which needed to be
passed to sh function defined as taking a char * arg. (evalstring()).

To do that safely (in 1999), a copy of the original string was made,
and that copy was passed to evalstring() instead of the original.
The copy is simply char *, and if something altered it, no-one would
care. The original string (in some cases) must not be altered.

That was the cause of the bug fixed (a different way) in the
previous commit to this file. To copy the string, space needed
to be allocated, and when that was done, if the string was just
(the right length, its terminating \0 (which previously was stored
outside the string itself) and if the current shell stack memory block
was big enough that a new one wasn't needed, the \0 would be trampled
(then the strcpy() would become overwriting, and havoc result).

Now evalstring() has been updated to take a const char *, and
the string passed to it truly is treated as const data (nothing
ever attempts to alter it) so making a copy of the string isn't
needed, and we can go back to the way the code used to be, pre-1999.

That is, modulo other unrelated changes (or one change actually)
that has been made since, which has nothing to do with the issues here.

The change made in the previous revision could be undone, but won't
be, as it is logically the right thing to do.

NFCI.

show more ...

Fix a very old core dump causing bug found by RVP in the history code.
That is, truly very old - it is in rev 1.1 from 1994 (and so is probably
even older than that).

If one uses the (very rarely us

Fix a very old core dump causing bug found by RVP in the history code.
That is, truly very old - it is in rev 1.1 from 1994 (and so is probably
even older than that).

If one uses the (very rarely used)
fc -s string=otherstring
builtin command, to rerun the previous command (or with additional args,
any other command) after replacing the first instance of "string" in that
command with "otherstring" and the resulting command line just happens to
be a length that is a multiple of the shell's memory allocation alignment
constant, then the \0 string terminator that is appended to the result
to mark its end stood a very small chance (in 1994 probably no chance at all,
but made considerably more likely in 1999 when other changes were made -
certain in the right circumstances) of being destroyed by other sh memory
allocation before the string was finished being used.

The fix (also suggested by RVP) is to make that \0 an actual part of
the allocated result string, rather than an extra byte tacked on the
end of it -- in itself, doing the latter is common in sh, and not at all
improper, sometimes even required, but only when the string as a string
will be consumed before more (shell) stack memory allocation is performed.
It 1994 it would have been. Since 1999, it isn't.

The 1999 change is going to be undone in a later commit, but this one
is simpler to pull up to earlier releases, and probably the right thing
to do anyway, even if not strictly essential.

XXX pullup -9, -10 (and everything back to 1.5 - it looks as if 1.4 is OK).

show more ...

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.

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 setv

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.

show more ...

Don't emit a user causable "internal error" message.

Non-numeric args to "fc" simply fail to find the string
in an empty history buffer, as they might in a non-empty
history, and generate a reasonab

Don't emit a user causable "internal error" message.

Non-numeric args to "fc" simply fail to find the string
in an empty history buffer, as they might in a non-empty
history, and generate a reasonable error message.

But normally, as numeric args to the "fc" utility are trimmed
to the bounds of the contents of the history buffer, it
is impossible for them to fail to find an entry, as at the
very least the "fc" command itself should be there.

Hence "sh" claimed such a thing was an "internal error".

But it is possible to run fc commands, not entered from
stdin, and so not eligible for the history buffer, before
any interactive commands are entered. In such a case
the history buffer will be empty, which "sh" has been
reporting as an "internal error". It isn't.
Generate a more meaningful (and less scary) message instead.

No pullups planned - the code has been like this for a
very long time, and no-one ever noticed, as it would be
very (VERY) unusual for the "fc" utility to be invoked
at a time when the history buffer is active & empty, given
the way the code currently exists (unlikely, not impossible).

This change is more in preparation for future possible
changes which would make this error easier to encounter.

show more ...

Ignore non-numeric values for HISTSIZE

This is a temporary change (which can be pulled up to -9 and -10)
to avoid having
HISTSIZE=foo /bin/sh
cause sh to fail to start.

A better change, but one re

Ignore non-numeric values for HISTSIZE

This is a temporary change (which can be pulled up to -9 and -10)
to avoid having
HISTSIZE=foo /bin/sh
cause sh to fail to start.

A better change, but one requiring far more code changes, so that
bad HISTSIZE is ignored, only when read from the environment, but
will be an error otherwise, will come later.

XXX pullup -9, -10

show more ...

General source cleanup, whitespace, KNF, 80-col police, ...

No executable binary change intended (certainly NFCI).
Some debugging info will change as line numbers have altered.

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

NFCI.

Add debugging trace points for history and the editline interface.
NFC for any normal shell (not compiled with debugging (sh DEBUG) enabled.

We have had a defined debug mode for this for years, but

Add debugging trace points for history and the editline interface.
NFC for any normal shell (not compiled with debugging (sh DEBUG) enabled.

We have had a defined debug mode for this for years, but since I have
not often played in this arena, never used it. Until recently (relatively).
This (or a small part of it) played a part in discovering the fc -e
bug cause. I have had it in my tree a while now - recent changes
kept causing merge conflicts (all because I hadn't bothered to commit
this), so I think now is the time...

show more ...

sh(1): revert previous because it interferes with custom user bindings

sh(1): Allow an explicit set -o vi or set -o emacs to override ~/.editrc

sh(1): Assign the tab completion key binding last so a user having
"bind -v" or "bind -e" in ~/.editrc doesn't cause tab completion
to no longer function.

sh: fix typo in comment

After (a few days short of) 21 years, revert 1.25, which did nothing except
make the -e option to "fc" fail to work (the commit message was about some
other changes entirely, so I an only assume this

After (a few days short of) 21 years, revert 1.25, which did nothing except
make the -e option to "fc" fail to work (the commit message was about some
other changes entirely, so I an only assume this was committed by mistake).

It says a lot about the use of the fc command that no-one noticed that
this did not work properly for all this time.

Internally in sh, it is possible for built in commands to use either
getopt(3) (from libc) or the much simpler internal shell nextopt() routine
for option (flag) parsing. However it makes no sense to use getopt()
and then access a global variable set only by nextopt() instead of the
one getopt() sets (which is what the code had used previously, forever).

Use the correct variable again.

XXX pullup -9 -8 (-7 -6 -5 ...)

show more ...

When we initialize libedit (editline) always call ourselves "sh" no
matter what $0 is (or is not) set to. This means that editrc(5)
lines that start "sh:" are used (in addition to those with no pre

When we initialize libedit (editline) always call ourselves "sh" no
matter what $0 is (or is not) set to. This means that editrc(5)
lines that start "sh:" are used (in addition to those with no prefix,
which will usually be most of them), regardless of the name or manner in
which we were invoked.

OK christos@

show more ...

Add some comments explaining accesses to the environment via
getenv()/setenv()/unsetenv() which manipulate the envornoment
the shell was passed at entry.

These are a little odd in sh as that environ

Add some comments explaining accesses to the environment via
getenv()/setenv()/unsetenv() which manipulate the envornoment
the shell was passed at entry.

These are a little odd in sh as that environment is copied into
the shell's internal variable data struct at shell startup, and
normally never accessed after that - in builtin commands (test.
printf, ...) getenv() is #defined to become an internal sh lookup
function instead, so even those never use the startup environment).

NFCI

show more ...

Quote the filenames like before

- Add command completion (from FreeBSD)
- Use EL_SAFEREAD

Remove a function prototype which was added to <histedit.h> in 2005.
I think we can trust it to be stable by now, and doin't need the dup.

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 i

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.

show more ...

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 se

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.)

show more ...

Now libedit supports embedded mode switch sequence, improve sh
support for them (adds PSlit variable to set the magic character).

Add literal prompt support this allows one to do:
CA="$(printf '\1')"
PS1="${CA}$(tput bold)${CA}\$${CA}$(tput sgr0)${CA} "

Properly support EDITRC - use it as (naming) the file when setting
up libedit, and re-do the config whenever EDITRC is set.

source .editrc after we initialize so that commands persist!