We cannot just compare histsizeval() against 0, since that returns
a string pointer, which is always non-zero (non-null). The logic
in sethistsize() initializes the history size to 100 with values
that are non-number, and an empty string counts as that. Therefore,
the only time we want to not write into history with HISTSIZE val
set is when it's explicitly 0.
MFC after: 2 weeks
Introduce new prompt format characters:
- '\[' starts the sequence of non-printing chatacters
- '\]' ends the sequence of non-printing characters
Within these sequences, the following characters are now supported:
- '\a' emits ASCII BEL (0x07, 007) character
- '\e' emits ASCII ESC (0x1b, 033) character
- '\r' emits ASCII CR (0x0d, 015) character
- '\n' emits ASCII CRLF sequence
These can be used to embed ANSI sequences into prompt strings.
Example in .shrc:
PS1="\[\e[7m\]\u@\h\[\e[0m\]:\w \\$ "
This tries to maintain some degree of compatibility with GNU bash,
that uses GNU readline library (which behaves slightly different from
BSD editline): It has two "non-printing boundary" characters:
- RL_PROMPT_START_IGNORE (\001)
- RL_PROMPT_END_IGNORE (\002)
while BSD editline only has one (when using EL_PROMPT_ESC setting), so
for this purpose, ASCII \001 was chosen and both \[ and \] emits
this character.
And while here, enlarge PROMPTLEN from 128 to 192 characters.
Reviewed by: jilles
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D37701
Previously when using NO_ROOT we recorded a METALOG entry for the
/.profile hard link with a different mode than the link target, which is
not permitted.
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37476
This is to avoid loading .shrc which may contain commands that would
result in output different than expected.
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D35876
As per Utility Syntax Guidelines, accept both forms: -l -n and -ln.
To do that, anticipate the source string for the next option that will
be parsed by nextopt(). It's not always *argptr, sometimes it is
nextopt_optptr.
To simplify the check for not_fcnumber, slightly modify nextopt() to
always nullify nextopt_optptr in cases where it would have been set
to point to a NUL character.
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D35836
Provide libedit a special function making it always add a space after
the autocompleted command. The default one adds a slash if the word is
also a name of a directory in the current working directory, but this is
wrong for commands.
Reviewed by: bapt, jilles
Differential Revision: https://reviews.freebsd.org/D34544
Pointer arithmetic on a null pointer is undefined behavior.
The bug can be reproduced by running bin/sh/tests/builtins/wait6.0 with
UBSAN.
Reported by: Mark Millard
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D34011
After an unescaped newline, there may be a here-document. Some places in
case and for did not check for one.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D32628
In single-user mode, all env vars are absent, so exptilde() would not be
able to expand ~ correctly.
Place the lines setting PATH below HOME, so exptilde() would work as
expected.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: jilles, emaste
Differential Revision: https://reviews.freebsd.org/D27003
For $reason mobaxterm default on sending unusual sequence from home/del
key, which makes libedit unabel to catch them and bind them correctly.
mobaxterm seems popular on the windows environment, so add proper
keybinding to default shrc configuration so it works out of box.
Reported by: lme
In the default configuration add 2 bindings which has been requested by
many during the HEADSUP discussion:
* csh like arrow history navigation
* ctrl-arrow to jump from word to words
Add an alias to make the history command exist as an alias to fc -l.
Add -o verify to sh to make it use O_VERIFY when
sourcing scripts and reading profiles.
Useful in conjunction with mac_veriexec to help protect at
least some parts of the boot sequence, e.g., /etc/rc*.
Differential revision: https://reviews.freebsd.org/D30464
Reviewed by: jilles, sjg
Obtained from: Stormshield
When there are many matches, find the longest common substring starting
from the beginning of each command and use that to replace input.
As an example: on my system, llv<tab> will be autocompleted to llvm-
and another <tab> will print all matching llvm commands.
Until this change, any bindings set in histedit() were lost on calls to
bindcmd().
Only bind -e and bind -v call libedit's keymacro_reset(). Currently you
cannot fool libedit/map.c:map_bind() by trying something like bind -le
as when p[0] == '-', it does a switch statement on p[1].
When multiple matches are found, we keep the provided string on the
input line and print unique matches as suggestions.
But the multiple matches might be the same command found in different
directories, so we should deduplicate the matches first and then decide
whether to autocomplete the command or not, based on the number of
unique matches.
in emacs mode ^W should delete the previous word by default
Note that upstreaming this change directly into libedit is in process.
Reported by: manu
Reviewed by: jills, pstef, manu
Differential Revision: https://reviews.freebsd.org/D29493
Move code added in b315a7296d ("autocomplete commands") to
conditionally compiled part under #ifndef NO_HISTORY.
Reported by: bdrewery
Fixes: b315a7296d
Implement persistent history storage:
the strategy is simple at start: loads the existing .sh_history file
at exit dump it.
The implementation respects the HISTFILE variable and its POSIX
definition: ~/.sh_history is used if HISTFILE is not set.
to avoid sh to create the history file, set HISTSIZE to 0 or HISTFILE to
en empty value
Co-authored-by: pstef
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D29493
In emacs mode, force ^R to backware search the history
This behaviour is the default in emacs mode for most of the other shells
Note: Note that this can still be overridden via $EDITRC, ~/.editrc or a
bind command after set -o emacs.
MFC after: 1 week
Approved by: jilles
Reviewed by: jilles, arichardson, pstef
Differential Revision: https://reviews.freebsd.org/D29494
Without this patch, sh can autocomplete file names but not commands from
$PATH. Use libedit's facility to execute custom function for autocomplete,
but yield to the library's standard autocomplete function when cursor is
not at position 0.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D29361
POSIX is pretty clear that command -v, command -V and type shall write
absolute pathnames. Therefore, we need to prepend the current directory's
name to relative pathnames.
This can happen either when PATH contains a relative pathname or when the
operand contains a slash but is not an absolute pathname.
If job control is not enabled, a background job (... &) ignores SIGINT and
SIGQUIT, but this can be reverted using the trap builtin in the same shell
environment.
Using the set builtin to change options would also revert SIGINT and SIGQUIT
to their previous dispositions.
This broke due to r317298. Calling setsignal() reverts the effect of
ignoresig().
Reported by: bdrewery
MFC after: 1 week
I've always found this a little bit confusing:
> sh
$ ^D> sh
$ ^D>
Reviewed by: 0mp, jilles
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25813
INTOFF postpones SIGINT processing and INTON enables it again. This is
important so an interactive shell can return to the top level prompt when
Ctrl+C is pressed.
Given that INTON is automatically done when a builtin completes, the part
where onsig() ignores suppressint when in_dotrap is true is both unnecessary
and unsafe. If the trap is for some other signal than SIGINT, arbitrary code
could have been interrupted.
Historically, INTOFF remained in effect for longer.
Reviewed by: bdrewery
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25270
The manual page documents "\$" to expand to either "$" or "#" followed by
a single space. In reality, the single space character is not appended.
PR: 247791
Submitted by: kd-dev@pm.me
MFC after: 7 days
When job control is not enabled, the shell ignores SIGINT while waiting for
a foreground process unless that process exits on SIGINT. In this case, the
foreground process is sleep and it does not exit on SIGINT because the
signal is only sent to the shell. Depending on order of events, this could
cause the SIGINT to be unexpectedly ignored.
On lightly loaded bare metal, the chance of this happening tends to be less
than 0.01% but with higher loads and/or virtualization it becomes more
likely.
Starting the sleep in background and using the wait builtin ensures SIGINT
will not be ignored.
PR: 247559
Reported by: lwhsu
MFC after: 1 week
If job control is not enabled, background commands shall ignore SIGINT and
SIGQUIT, and it shall be possible to override that ignore in the same shell.
MFC after: 1 week
Historically, we've allowed read() of a directory and some filesystems will
accommodate (e.g. ufs/ffs, msdosfs). From the history department staffed by
Warner: <<EOF
pdp-7 unix seemed to allow reading directories, but they were weird, special
things there so I'm unsure (my pdp-7 assembler sucks).
1st Edition's sources are lost, mostly. The kernel allows it. The
reconstructed sources from 2nd or 3rd edition read it though.
V6 to V7 changed the filesystem format, and should have been a warning, but
reading directories weren't materially changed.
4.1b BSD introduced readdir because of UFS. UFS broke all directory reading
programs in 1983. ls, du, find, etc all had to be rewritten. readdir() and
friends were introduced here.
SysVr3 picked up readdir() in 1987 for the AT&T fork of Unix. SysVr4 updated
all the directory reading programs in 1988 because different filesystem
types were introduced.
In the 90s, these interfaces became completely ubiquitous as PDP-11s running
V7 faded from view and all the folks that initially started on V7 upgraded
to SysV. Linux never supported this (though I've not done the software
archeology to check) because it has always had a pathological diversity of
filesystems.
EOF
Disallowing read(2) on a directory has the side-effect of masking
application bugs from relying on other implementation's behavior
(e.g. Linux) of rejecting these with EISDIR across the board, but allowing
it has been a vector for at least one stack disclosure bug in the past[0].
By POSIX, this is implementation-defined whether read() handles directories
or not. Popular implementations have chosen to reject them, and this seems
sensible: the data you're reading from a directory is not structured in some
unified way across filesystem implementations like with readdir(2), so it is
impossible for applications to portably rely on this.
With this patch, we will reject most read(2) of a dirfd with EISDIR. Users
that know what they're doing can conscientiously set
bsd.security.allow_read_dir=1 to allow read(2) of directories, as it has
proven useful for debugging or recovery. A future commit will further limit
the sysctl to allow only the system root to read(2) directories, to make it
at least relatively safe to leave on for longer periods of time.
While we're adding logic pertaining to directory vnodes to vn_io_fault, an
additional assertion has also been added to ensure that we're not reaching
vn_io_fault with any write request on a directory vnode. Such request would
be a logical error in the kernel, and must be debugged rather than allowing
it to potentially silently error out.
Commented out shell aliases have been placed in root's chsrc/shrc to promote
awareness that grep may become noisy after this change, depending on your
usage.
A tentative MFC plan has been put together to try and make it as trivial as
possible to identify issues and collect reports; note that this will be
strongly re-evaluated. Tentatively, I will MFC this knob with the default as
it is in HEAD to improve our odds of actually getting reports. The future
priv(9) to further restrict the sysctl WILL NOT BE MERGED BACK, so the knob
will be a faithful reversion on stable/12. We will go into the merge
acknowledging that the sysctl default may be flipped back to restore
historical behavior at *any* point if it's warranted.
[0] https://www.freebsd.org/security/advisories/FreeBSD-SA-19:10.ufs.asc
PR: 246412
Reviewed by: mckusick, kib, emaste, jilles, cy, phk, imp (all previous)
Reviewed by: rgrimes (latest version)
MFC after: 1 month (note the MFC plan mentioned above)
Relnotes: absolutely, but will amend previous RELNOTES entry
Differential Revision: https://reviews.freebsd.org/D24596
Austin Group bugs #1226 and #1250 changed the requirements for shell scripts
without #! (POSIX does not specify #!; this is about the shell execution
when execve(2) returns an [ENOEXEC] error).
POSIX says we shall allow execution if the initial part intended to be
parsed by the shell consists of characters and does not contain the NUL
character. This allows concatenating a shell script (ending with exec or
exit) and a binary payload.
In order to reject common binary files such as PNG images, check that there
is a lowercase letter or expansion before the last newline before the NUL
character, in addition to the check for the newline character suggested by
POSIX.
The shell maintains a count of the number of times SIGINT processing has
been disabled via INTOFF, so SIGINT processing resumes when all disables
have enabled again (INTON).
If an error occurs in a vfork() child, the processing of the error enables
SIGINT processing again, and the INTON in vforkexecshell() causes the count
to become negative.
As a result, a later INTOFF may not actually disable SIGINT processing. This
might cause memory corruption if a SIGINT arrives at an inopportune time. As
of r360452, it causes the shell to abort when it would unsafely allocate or
free memory in certain ways.
Note that various places such as errors in non-special builtins
unconditionally reset the count to 0, so the problem might still not always
be visible.
PR: 246497
Reported by: jbeich
MFC after: 2 weeks
As I noted in https://reviews.freebsd.org/D22756, INTOFF should be in effect
when calling ckmalloc/ckrealloc/ckfree to avoid memory leaks and double
frees. Therefore, change the functions to check if INTOFF is in effect
instead of applying it.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D24599
