1
0
Fork 0
mirror of git://git.code.sf.net/p/cdesktopenv/code synced 2025-03-09 15:50:02 +00:00
Commit graph

379 commits

Author SHA1 Message Date
Martijn Dekker
dde8da6769 Fix history comment character in history expansion (re: 41ee12a5)
Reproducer: on an interactive shell with the -H option on,

  $ v=foo
  $ print ${#v}

does not print anything (but should print "3").
The 'print' line also is not added to the history.

This bug was exposed by commit 41ee12a5 which enabled the history
comment character by default, setting it to '#' as on bash. When it
was disabled by default, this bug was rarely exposed.

The problem happens here:

src/cmd/ksh93/edit/hexpand.c
203: if(hc[2] && *cp == hc[2]) /* history comment designator, skip rest of line */
204: {
205: 	stakputc(*cp++);
206: 	stakputs(cp);
207: 	DONE();
208: }

The DONE() macro sets the HIST_ERROR bit flag:

src/cmd/ksh93/edit/hexpand.c
45: #define	DONE()	{flag |= HIST_ERROR; cp = 0; stakseek(0); goto done;}

For the history comment character that is clearly wrong, as no
error has occurred.

There is another problem. The documentation I added for history
expansion states this bit, which is based on bash's behaviour:

    If a word on a command line begins with the history comment
    character #, history expansion is ignored for the rest of that
    line.

With an expansion like ${#v}, the word does not begin with # so
history expansion should not have parsed that as a comment
character. The intention was to act like bash.

src/cmd/ksh93/edit/hexpand.c:
- Split the DONE() macro into DONE and ERROROUT of which only the
  latter sets the HIST_ERROR bit flag. Change usage accordingly.
  Thix fixes the first problem.
- Don't make these new macros function-style macros (with ()) as
  they end in a goto, so that's a bit misleading.
- Add is_wordboundary() which makes a best-effort attempt to
  determine if the character following the specified character is
  considered to start a new word by shell grammar rules. Word
  boundary characters are whitespace and: |&;()`<>
- Only recognise the history comment character if is_wordbounary()
  returns true for the previous character. This fixes the second
  problem.

Thanks to @jghub for the bug report.
Resolves: https://github.com/ksh93/ksh/issues/513
2022-08-16 22:00:20 +01:00
Martijn Dekker
ebdcfcbb62 Release 1.0.2 (re: cd063869)
This release fixes the interactive shell crashing when one of the
predefined aliases (currently 'history' and 'r') is redefined,
whether from a profile/kshrc script or manually. This crash
occurred in two scenarios:

1. when redefining and then unsetting a predefined alias;

2. when redefining a predefined alias and then executing a shell
   script that does not begin with a #! path.

Both are fixed now.
2022-08-08 10:49:58 +01:00
Martijn Dekker
1335cbd1d7 remove ${.sh.pool} predefined variable entry (re: 3613da42)
This entry was doing nothing, because it is another overlooked
remnant of the removed libcoshell code.
2022-08-07 15:28:52 +01:00
Martijn Dekker
cd0638690c Fix crashes on redefining/unsetting predefined alias (re: 7e7f1372)
Reproducer 1:

  $ alias r
  r='hist -s'
  $ alias r=foo
  $ unalias r
  ksh(10127,0x10d6c35c0) malloc: *** error for object 0x7ffdcd404468: pointer being freed was not allocated
  ksh(10127,0x10d6c35c0) malloc: *** set a breakpoint in malloc_error_break to debug
  Abort

The crash happens as unall() (typeset.c) calls nv_delete() (name.c)
which tries to free a node pointer that was not directly allocated.

Reproducer 2:

  $ ENV=/./dev/null ksh
  $ echo : >script
  $ chmod +x script
  $ alias r=foo
  $ ./script
  ksh(10193,0x10c8505c0) malloc: *** error for object 0x7fa136c04468: pointer being freed was not allocated
  ksh(10193,0x10c8505c0) malloc: *** set a breakpoint in malloc_error_break to debug
  Abort

This crash happens for the same reason, but in another location,
namely in sh_reinit() (init.c) as it is freeing up the alias table
before executing a script that does not start with a #! path.

This is a serious bug because it is not uncommon for .kshrc or
.profile scripts to (re)define an alias called 'r'.

Analysis:

These crashes happen because the incorrectly freed node pointer is
part of a larger block of nodes initialised by sh_inittree() in
init.c. That function allocates all the nodes for a table (see
data/{aliases,builtins,variables}.c) in a contiguous block
addressable by numeric index (see builtins.h and variables.h for
how that is used).

So, while the value of the alias is correctly marked NV_NOFREE and
is not freed, that attribute does not apply to the node pointer
itself, which also is not freeable. Thus, if the value is replaced
by a freeable one, the node pointer is incorrectly freed upon
unaliasing it, and the shell crashes.

The simplest fix is to allocate each predefined alias node
individually, like any other alias -- because, in fact, we do not
need the predefined alias nodes to be in a contiguous addressable
block; there is nothing that specifically addresses these aliases.

src/cmd/ksh93/sh/main.c: sh_main():
- Instead of calling sh_inittree(), use a dedicated loop to
  allocate each predefined alias node individually, making each
  node invidually freeable. The value does remain non-freeable,
  but the NV_NOFREE attribute correctly takes care of that.

src/cmd/ksh93/bltins/typeset.c:
- Get rid of the incomplete and now unnecessary workarounds in
  unall() and sh_reinit().

Thanks to @jghub and @JohnoKing for finding and reporting the bug.
Discussion: https://github.com/ksh93/ksh/discussions/503#discussioncomment-3337172
2022-08-06 11:54:33 +01:00
Martijn Dekker
9c9743998f Revert buggy exec optimisation (re: d6c9821c)
As of 2022-06-18, ksh 93u+m is not capable of being used as /bin/sh
while building GNU binutils. The execution of some of its build
system's dot scripts is incorrectly aborted as an external 'sed'
command is execve(2)'d without forking. This means that incorrect
exec optimization was happening.

Unfortunately I have not been able to derive a minimal reproducer
of the problem yet because the GNU binutils build scripts are very
complex. Pending further research, the optimisation is reverted.
Even if a way to make it work is found, it will not be reintroduced
to the 1.0 branch.

Thanks to @atheik for finding the problem and identifying the
commit that introduced it.

Resolves: https://github.com/ksh93/ksh/issues/507
2022-08-05 12:52:49 +02:00
Martijn Dekker
3a25aa0d93 Release 93u+m/1.0.0
_        _        ___ _____                          ___   ___   ___
| | _____| |__    / _ \___ / _   _   _   _ __ ___    / / | / _ \ / _ \
| |/ / __| '_ \  | (_) ||_ \| | | |_| |_| '_ ` _ \  / /| || | | | | | |
|   <\__ \ | | |  \__, |__) | |_| |_   _| | | | | |/ / | || |_| | |_| |
|_|\_\___/_| |_|    /_/____/ \__,_| |_| |_| |_| |_/_/  |_(_)___(_)___/

It may have taken exactly a decade, but here we are... a proper new
ksh release. :) Many thanks to all contributors for their hard work!
Compared to an unpatched 93u+, this release has roughly a thousand
bugs fixed. It incorporates a fair number of enhancements as well.

Not all known bugs have been worked out yet; see the TODO file. Let's
hope this release will rekindle interest and attract more bug hunters.

This commit also makes some very minor fixes in comments. Notable:
src/cmd/ksh93/sh/arith.c: sh_strnum():
- Update a security-related comment. As of b48e5b33, evaluating
  untrusted arithmetic expressions from the environment should no
  longer cause CVE-2019-14868. But let's keep disallowing it anyway.

Resolves: https://github.com/ksh93/ksh/issues/491
2022-08-01 21:44:02 +02:00
Martijn Dekker
9c69fac793 Re-backport atomic job locking from 93v- (re: 52067c3d, 595a0a56)
[This commit was previously reverted because it seemed to cause the
build to fail on Cygwin. But I just re-tested it, and it's fine. It
may be that my Cygwin installation at the time was defective.]

Something similar was previously done in 07cc71b8 from a Debian
patch, and eventually reverted; it redefined the ast atomic
functions asoincint() and asodecint() to be gcc-specific. This
imports the upstream version from the ksh 93v- beta instead.

This commit is based on an OpenSUSE patch:
https://build.opensuse.org/package/view_file/shells/ksh/ksh93-joblock.dif

src/cmd/ksh93/include/jobs.h:
- Replace job locking mechanism with the 93v- version which uses
  the atomic libast functions asoincint(), asogetint() and
  asodecint(). See: src/lib/libast/man/aso.3

src/cmd/ksh93/sh/jobs.c: job_subsave():
- Revert gcc optimiser bug workaround from c258a04f.
  It should now be unnecessary.
2022-08-01 05:41:52 +02:00
Martijn Dekker
38acc02e78 nv_newattr(): Fix out-of-bounds read (re: bdb99741)
When converting from -Z to another attribute, if the value of the
-Z variable was empty (so -Z0 and an empty value), the loop that
skips initial zeros may read before the beginning of the buffer:

2968:	if(nv_isattr(np,NV_ZFILL))
2969:	{
2970:		while(*sp=='0') sp++;	/* skip initial zeros */
2971:		if(!*sp) sp--;		/* if number was 0, leave one zero */
2972:	}

If the *sp value is empty (just a terminating zero byte), line 2970
does nothing, but line 2971 still decrases the pointer, to before
the beginning of the buffer.

The fix is to check for an initial zero before running that block.

Reproducer (fails intermittently, depending on garbage before *sp):

    typeset -Z foo=
    typeset -i foo
2022-07-31 04:13:42 +02:00
Martijn Dekker
807863c29a Update author attributions in all source files
This commit:

1. Updates the COPYRIGHT file with all the contributors to ksh
   93u+m since the reboot, based on the commit history, sorted by
   number of commits in descending order. It also separates the
   authors of backported contributions from direct contributors.

2. Adds missing contributors of source each file to that file's
   copyright header based on that file's commit history.

The script used to maintain this is now up at:
https://github.com/ksh93/ksh/wiki/update-copyright.sh

In addition, the original ast copyright notice is restored to
its EPL 1.0 version -- that is what AT&T Intellectual Property
originally licensed this code under, and we are the ones who
upgraded it to EPL 2.0 (as allowed by EPL 1.0) in 441dcc04.
The history should be accurate.
2022-07-31 00:47:08 +02:00
Martijn Dekker
3e84231558 stk(3): fix argument type of exception callback function
The callback function for malloc(3) failure in the stk(3) routines
(which can be specified using stkinstall() and is set to nomemory()
in init.c) uses a size argument of type int. That's a type mismatch
with all the other size arguments and variables in stk(3) which use
size_t, an unsigned type that may be larger than int.

This is all quite inconsequential as nothing in our code base (or
in the complete old AT&T AST code base) actually uses that size for
anything, but it's still wrong, so this corrects the interface.

With this very minor API change, let's bump the libast API version
to 20220801, the date of the upcoming ksh 93u+m 1.0.0 release. :)

The ksh93/sh/init.c nomemory() function now reports the size that
could not be allocated, just because it can.
2022-07-30 00:45:41 +02:00
Martijn Dekker
9f6841c37e Fix "$*" doing pattern matching if $IFS is wildcard (BUG_IFSGLOBS)
The bug is that "$*", and related expansions such as "${arr[*]}",
etc., do pattern matching if the first character of $IFS is a
wildcard. For example, the following:

    IFS=*
    set -- F ''
    case BUGFREE in
    BUG"$*")        echo bug ;;
    esac

outputs 'bug'. This bug can be reproduced in every other glob
pattern matching context as well, but not in pathname expansion.

src/cmd/ksh93/sh/macro.c: varsub():
- When joining fields into one for a "$*"-type expansion, check if
  a glob pattern matching operation follows (mp->pattern is set).
  If so, write a preceding backslash to escape the separator.

Resolves: https://github.com/ksh93/ksh/issues/489
Resolves: https://github.com/att/ast/issues/12
2022-07-28 23:36:39 +02:00
Martijn Dekker
441dcc0483 Upgrade licence to EPL 2.0
EPL 1.0 says, in section 7: "The Program (including Contributions)
may always be distributed subject to the version of the Agreement
under which it was received. In addition, after a new version of
the Agreement is published, Contributor may elect to distribute the
Program (including its Contributions) under the new version."

The Eclipse Foundation also encourage everyone to upgrade:
https://www.eclipse.org/legal/epl-2.0/faq.php#h.60mjudroo8e5
https://www.eclipse.org/legal/epl-2.0/faq.php#h.tci84nlsqpgw

Unfortunately the new Secondary License option is not available to
us as we're not the original copyright holders and don't have the
legal power to add one. So, no GPL compatibility. Sorry.
2022-07-28 05:46:08 +02:00
Martijn Dekker
1a0d75d47c Add ${.sh.ppid} (re: 48f78227)
Since we now have sh.current_ppid, we might as well point a shell
variable to it, as the cost is nil.

Together, ${.sh.pid} and ${.sh.ppid} (updated when a virtual
subshell forks) form a logical counterpart pair to $$ and $PPID
(never updated in subshells).

This commit also adds a section to the manual page that hopefully
does away with the depressingly widespread subshell/child shell
confusion once and for all... :P
2022-07-27 22:58:43 +02:00
Martijn Dekker
305073af9d Remove .sh.dollar (re: 3613da42, 7b0e0776)
The undocumented .sh.dollar variable was a hack used to change the
value of $$ (main shell's PID); any value assigned to .sh.dollar
overrides the value of $$. This was used by libcoshell and by the
pre-fork(2) code to update the value of $$ in child processes
initialised by internally generated shell scripts. Both were
removed long ago, so we don't need this.
2022-07-27 22:58:10 +02:00
Martijn Dekker
48f78227a9 Fix $PPID for hashbangless script (re: 232b7bff)
I made a mistake in sh.reinit() which caused $PPID to be set to the
new process ID, not the parent process ID. This commit fixes it by
introducing, updating and using sh.current_ppid, so we continue to
minimise context switches due to getpid(2)/getppid(2) system calls.

Thanks to Geoff Clare for the report.
2022-07-27 22:48:57 +02:00
Martijn Dekker
592ce7415a test/[/[[: Fix incorrect 0-skipping, float precision (re: c734568b)
The arguments to the binary numerical comparison operators (-eq,
-gt, etc.) in the [[ and test/[ commands are treated as arithmetic
expressions, even if $((...)) is not used. But there is some
seriously incorrect behaviour:

Reproducers (all should output 0/true):

    $ [[ 0x0A -eq 10 ]]; echo $?
    1
    $ [[ 1+0x0A -eq 11 ]]; echo $?
    0
    $ (set --posix; [[ 010 -eq 8 ]]); echo $?
    1
    $ (set --posix; [[ +010 -eq 8 ]]); echo $?
    0
    $ [[ 0xA -eq 10 ]]; echo $?
    1
    $ xA=10; [[ 0xA -eq 10 ]]; echo $?
    0
    $ xA=WTF; [[ 0xA -eq 10 ]]; echo $?
    ksh: WTF: parameter not set

(POSIX mode enables the recognition of the initial 0 as a prefix
indicating an octal number in arithmetic expressions.)

The cause is the two 'while' loops in this section in test_binop()
in src/cmd/ksh93/bltins/test.c:

502:	if(op&TEST_ARITH)
503:	{
504:		while(*left=='0')
505:			left++;
506:		while(*right=='0')
507:			right++;
508:		lnum = sh_arith(left);
509:		rnum = sh_arith(right);
510:	}

So initial zeros are unconditionally skipped. Ostensibly this is to
disable the recognition of the initial zero as an octal prefix as
well as 0x as a hexadecimal prefix. This would be okay for
enforcing a decimal-only limitation for simple numbers, but to do
this for arithmetic expressions is flagrantly incorrect, to say the
least. (insert standard rant about AT&T quality standards here)

The fix for '[[' is simply to delete the two 'while' loops. But
that creates a problem for the deprecated-but-standard 'test'/'['
command, which also uses the test_binop() function. According to
POSIX, test/[ only parses simple decimal numbers, so octal, etc. is
not a thing. But, after that fix, 'test 08 -eq 10' in POSIX mode
yields true, which is unlike every other shell. (Note that this is
unlike [[ 08 -eq 10 ]], which yields true on bash because '[['
parses operands as arithmetic expressions.)

For test/[ in non-POSIX mode, we don't need to change anything. For
POSIX mode, we should only parse literal decimal numbers for these
operators in test/[, disallowing unexpanded arithmetic expressions.
This makes ksh's POSIX-mode test/[ act like every other shell and
like external .../bin/test commands shipped by OSs.

src/cmd/ksh93/bltins/text.c: test_binop():
- Correct a type mismatch. The left and right hand numbers should
  be Sfdouble_t, the maximum double length on the current system,
  and the type that sh_arith() returns. Instead, long double
  (typeset -lF) values were reduced to double (typeset -F) before
  comparing!
- For test/[ in POSIX, only accept simple decimal numbers: use
  strtold() instead of sh_arith(). Do skip initial zeros here as
  this disables the recognition of the hexadecimal prefix. Throw an
  error on an invalid decimal number. Floating point constants are
  still parsed, but that's fine as this does not cause any
  incompatibility with POSIX.

- For code legibility, move handling of TEST_EQ, etc. to within the
  if(op&TEST_ARITH) block. This also allows lnum and rnum to be
  local to that block.
2022-07-26 21:33:00 +02:00
Martijn Dekker
b7817c3750 Release 93u+m/1.0.0-rc.1
We're nearly there!

I intend to release ksh 93u+m/1.0.0 on 2022-08-01, precisely ten
years after the last canonical 93u+ release.

We have a week until then, so here's a release candidate. Please
try as hard as you can to break it, and to help fix known bugs.

As of this commit, the 1.0 branch is feature-frozen and will only
get bugfixes.

src/cmd/ksh93/fun/man:
- Last-minute fix: .man.try_os_man(): do not look for arguments
  with / in section 1 and 8; this can cause false positives.
2022-07-25 04:03:16 +02:00
Martijn Dekker
b8ea3ab76a Round number I-lost-count-long-ago of minor cleanups
Somewhat notable changes:
- Remove pointless test commands from Mamfiles.
- Consistent use of NoN macro instead of manual void _STUB_foo(){}
  (this is to silence "foo.o has no symbols" warnings from ld).
- Remove src/lib/libast/comp/transition.c; obsolete, does nothing.
- xec.c: Fix off-by-one error in sigreset() used by sh_ntfork():
  it tried to (re)set signal 0, which is harmless, but wrong.
  (note that sh.st.trapmax is the current max trapped sig + one!)
2022-07-24 16:29:17 +02:00
Martijn Dekker
bb4f23e63f set -b/--notify: do not mess up the command line
This commit makes three interrelated changes.

First, the code for erasing the command line before redrawing it
upon a window size change is simplified and modernised. Instead of
erasing the line with lots of spaces, it now uses the sequence
obtained from 'tput ed' (usually ESC, '[', 'J') to "erase to the
end of screen". This avoids messing up the detection and automatic
redrawing of wrapped lines on terminals such as Apple Terminal.app.

Second, the -b/--notify option is made more usable. When it is on
and either the vi or emacs/gmacs line editor is in use, 'Done' and
similar notifications are now buffered and trigger a command line
redraw as if the window size changed, and the redraw routine prints
that notify buffer between erasing and redrawing the commmnd line.
The effect is that the notification appears to magically insert
itself directly above the line you're typing. (The notification
behaviour when not in the shell line editor, e.g. while running
commands such as external editors, is unchanged.)

Third, a bug is fixed that caused -b/--notify to only report on one
job when more than one terminated at the same time. The rest was
reported on the next command line as if -b were not on. Reproducer:
$ set -b; sleep 1 & sleep 1 & sleep 1 &

This commit also includes a fair number of other window size and
$COLUMNS/$LINES handling tweaks that made all this easier, not all
of which are mentioned below.

src/cmd/ksh93/include/fault.h,
src/cmd/ksh93/sh/fault.c:
- Replace sh_update_columns_lines with a new sh_winsize() function.
  It calls astwinsize() and is to be used instead of it, and
  instead of nv_getval(LINES) and nv_getval(COLUMNS) calls. It:
  - Allows passing one or neither of lines or cols pointers.
  - Updates COLUMNS and LINES, but only if they actually changed
    from the last values. This makes .set discipline functions
    defined for these variables more useful.
  - Sets the sh.winch flag, but only if COLUMNS changes. If only
    the height changes, the command line does not need redrawing.

src/cmd/ksh93/include/io.h:
- Add sh_editor_active() that allows checking whether one of vi,
  emacs or gmacs is active without onerous #if SHOPT_* directives.

src/cmd/ksh93/sh/jobs.c: job_reap():
- Remove the fix backported in fc655f1a, which was really just a
  workaround that papered over the real bug.
- Move a check for errno==ECHILD so it is only done when waitpid()
  returns an error (pid < 0); the check was not correct because C
  library functions that do not error out also do not change errno.
- Move the SH_NOTIFY && SH_TTYWAIT code section to within the
  while(1) loop so it is run for each job, not only the
  last-processed one. This fixes the bug where only one job was
  notified when more than one ended at the same time.
- In that section, check if an editor is active; if so, set the
  output file for job_list() to sh.notifybuffer instead of standard
  error, list the jobs without the initial newline (JOB_NLFLAG),
  and trigger a command line redraw by setting sh.winch.

src/cmd/ksh93/edit/edit.c:
- Obtain not just CURSOR_UP but also ERASE_EOS (renamed from
  KILL_LINE) using 'tput'. The latter had the ANSI sequence
  hardcoded. Define a couple of TPUT_* macros to make it easier to
  deal with terminfo/termcap codes.
- Add get_tput() to make it easier to get several tput values
  robustly (with SIGINT blocked, trace disabled, etc.)
- ed_crlf(): Removed. Going by those ancient #ifdefs, nothing that
  93u+m will ever run on requires a '\r' before a '\n' to start a
  new line on the terminal. Plus, as of 93u+, there were already
  several spots in emacs.c and vi.c where it printed a sole '\n'.
- ed_read():
  - Simplify/modernise command line erase using ERASE_EOS.
  - Between erasing and redrawing, print the contents of the notify
    buffer. This has the effect of inserting notifications above
    the command line while the user is typing.

src/cmd/ksh93/features/cmds:
- To detect terminfo vs termcap codes, use all three codes we're
  currently using. This matters on at least on my system (macOS
  10.14.6) in which /usr/bin/tput has incomplete terminfo support
  (no 'ed') but complete termcap support!
2022-07-24 04:11:12 +02:00
Martijn Dekker
39e467dab3 Remove broken iousepipe/sh_iounpipe (re: a2196f94)
After that commit, iousepipe(), sh_iounpipe(), and supporting flags
were all broken and dead code. Since all command substitutions use
temp files now, they're unused; remove them.

I'm experimenting with reintroducing pipes to command substitutions
in a consistent way, as this is needed for them to wait for
grandchildren. If and when I ever manage to figure out how to do
that in a way that doesn't cause severe hanging and crashing bugs,
these functions may return in some form.

Related: https://github.com/ksh93/ksh/issues/124
2022-07-23 00:00:10 +02:00
Martijn Dekker
ce3cc66d58 Next round of minor tweaks and cleanups
Notable changes:
- Tie up some loose ends re: 3de4da5a and 7ba2c685.
- comp/omitted.c: Header include fix for Cygwin.
- misc/optget.c:
  - args(): When printing options for the uage line, use a local
    pointer for the 'if' block instead of reusing the 'b' pointer.
    That variable is used to output blanks later.
  - The above fix allows re-enabling the AST translation-aware
    macros and deleting the astsa fallback without causing usage
    message corruption in multibyte locales. Maybe someday we'll
    make ksh actually translatable.
  - Remove code to reinitialise _error_infop_ and _opt_info_
    'because these are not initialised by all DLLs'. In 2022,
    hopefully the buggy dynamic linkers are fixed. If not, we're
    not going to find out by keeping the workaround. I suspect that
    those bugs may have been triggered by the Microsoft/Cygwin
    import/export obfuscation removed in 3de4da5a.
- ksh93:
  - Remove unused sh.st.var_local variable. This was a leftover of
    a 93v- attempt to implement the bash 'local' command. It used
    static scoping, so it's not actually compatible.
  - Add a few regression tests for miscellaneous breakage that I
    caused in experiments (the breakage never made it to git; the
    tests are just to keep it that way).
2022-07-22 00:07:41 +02:00
Martijn Dekker
3de4da5afb Remove Microsoft/Cygwin import/export nonsense
Windows/Cygwin requires onerous special handling and the definition
of additional _imp__* symbols to import/export symbols between
dynamically linked binaries. Its support in AST used a lot of
macros and code obfuscation. In the features/common test for this,
AT&T called this the "Microsoft import/export nonsense".

They're right, it's nonsense. Somehow, Microsoft's POSIX layer,
SFU/Interix, always managed without it. No one has time to maintain
this (especially considering how incredibly sluggish Cygwin is).
And in fact, it had already fallen victim to bit rot; I confirmed
this in my early experiments with reintroducing dynamic library
support. No one has time to fix it, either.

So, my apologies to any Cygwin fans; ksh 93u+m will never support
dynamically loadable built-ins on Cygwin, even when I do manage to
reintroduce dynamic linking properly.
2022-07-21 23:27:37 +02:00
Martijn Dekker
d9a85caf22 Remove AT&T UWIN support code
UWIN was David Korn's UNIX emulation layer for Microsoft Windows.
It was never very well known, certainly not like Cygwin or
Microsoft SFU/Interix. It was a very interesting system that
exposed the Windows registry to the file system, making it
UNIX-like, and that natively used ksh and all the AST utilities.

Regrettably, it appears to be dead and buried. Only 32-bit binaries
can still be found in the wild, as well as the source code at:
	https://github.com/att/uwin
The latter does not seem to be usable since (as far as I can tell)
it requires a UWIN environment with a compiler to build, and UWIN
binaries with a compiler are simply nowhere to be found.

The activity level on that repo (which is zero) also shows how much
interest there still is in this project. And of course the
supporting code in this repo is almost certainly broken by now as
we've never been able to test it on a UWIN system.

The AST team clearly cared about it since roughly 8k lines of code
are dedicated to its support, disabled (directly or indirectly) on
non-UWIN systems via the _UWIN macro. This removes all that.
2022-07-21 10:17:14 +02:00
Martijn Dekker
8264d2089a Remove ineffective check for login shell; require -p for suid/sgid
In main.c:

158:		if(sh.ppid==1)
159:			sh.login_sh++;

If that was ever valid, it certainly is not now. As far as I know,
there is no currently existing system where PID 1 (init or systemd
or whatever) is the parent shell of the login shell, even straight
after bootup; login shells are invoked via a program like login(1).
Plus, there is no guarantee the init process actually has PID 1.

This invalidates all use of login_sh that couldn't be replaced by
checks for the login_shell option, so this commit does just that.

src/cmd/ksh93/include/shell.h:
- Remove login_sh flag.

src/cmd/ksh93/sh/init.c:
- If a login shell was detected, just set the login_shell option.
- Remove obsolete check for #! setuid scripts. This was meant to
  guard against a symlink called '-i' to a setuid script with a
  hashbang path, which used to give users a root shell. All modern
  Unixes ignore the setuid bit when they detect a hashbang path.

src/cmd/ksh93/SHOPT.sh:
- By default, let's require the -p/--privileged invocation option
  for the setuid/setgid bit on the shell binary to be respected,
  for all user IDs (>= 0). This is what bash and mksh do, and
  it seems sensible. (See init.c 1475-1483)
2022-07-21 05:51:07 +02:00
Martijn Dekker
948fab26aa Fix: running external command influences $RANDOM sequence
The pseudorandom generator generates a reproducible sequnece of
values after seeding it with a known value. But:

    $ (RANDOM=1; echo $RANDOM; echo $RANDOM)
    2100
    18270
    $ (RANDOM=1; echo $RANDOM; ls >/dev/null; echo $RANDOM)
    2100
    30107

Since RANDOM was seeded with a specific value, the two command
lines should output the same pair of numbers. Running 'ls' in the
middle should make no difference.

The cause is a nv_getval(RANDNOD) call in xec.c, case TFORK, that
is run for all TFORK cases, in the parent process -- including
background jobs and external commands. What should happen instead
is that $RANDOM is reseeded in the child process.

This bug is in every version of ksh93 since before 1995.

There is also an opportunity for optimisation. As of 396b388e, the
RANDOM seed may be invalidated by setting rand_last to -2,
triggering a reseed the next time a $RANDOM value is obtained. This
was done to optimise the virtual subshell mechanism. But that can
also be used to eliminate unconditional reseeding elsewhere. So as
of this commit, RANDOM is never (re)seeded until it's used.

src/cmd/ksh93/include/variables.h,
src/cmd/ksh93/sh/subshell.c:
- Add RAND_SEED_INVALIDATED macro, a single source of truth for the
  value that triggers a reseeding in sh_save_rand_seed().
- Add convenient sh_invalidate_rand_seed() function macro.

src/cmd/ksh93/sh/init.c,
src/cmd/ksh93/sh/xec.c:
- Optimisation: invalidate seed instead of reseeding directly.
- sh_exec(): case TFORK: Delete the nv_getval(RANDNOD) call. Add a
  sh_invalidate_rand_seed() to the child part. This fixes the bug.
2022-07-21 01:01:32 +02:00
Martijn Dekker
1884f57a74 Streamline some nval(3) and related flaggery
In the olden days, ksh used the hash(3) library to store variables,
aliases, functions, etc. For many years, it's been using the cdt(3)
library instead. But the low-level nv_search() name-value tree
lookup function was still repurposing some bit flags from the old
hash API for its options, though that API is otherwise unused.

So we were still including the entire obsolete <hash.h> API just
to use two repurposed HASH_* bit flags for nv_search(). This commit
makes nv_search() repurpose some flags from <nval.h> instead.

This commit should not change ksh's behaviour.

src/cmd/ksh93/sh/nvdisc.c:
- Make nv_search() use NV_NOSCOPE instead of HASH_NOSCOPE and
  NV_REF instead of HASH_BUCKET.
- The HASH_SCOPE flag was also passed to some nv_search() calls,
  but nv_search() ignores it, so that flag is deleted from those.
- Document nv_search() in a comment.

src/cmd/ksh93/include/name.h:
- Move NV_UNATTR to nval.h to join the other nv_open() options
  there. (re: 1184b2ad)

src/cmd/ksh93/include/nval.h:
- Since we no longer use HASH_* macros, do not include <hash.h>.
- Remove unused NV_NOASSIGN macro, defined to 0. This was there
  for "backward compatibility" since before 1995; long enough.

src/cmd/ksh93/include/shell.h:
- Bump SH_VERSION due to the nv_search() API change (even though no
  changes were made to the APIs documented in nval.3 or shell.3).

All other changed files:
- Update to match the flaggery changes.
2022-07-20 04:32:43 +02:00
Martijn Dekker
064baa372e More misc. tweaks and cleanups
Notable changes:

.github/workflows/ci.yml:
- Run 'bin/package test' on the github runner so we test iffe too.

src/cmd/ksh93/sh/subshell.c:
- sh_assignok was usually called like 'np = sh_assignok(np,0)'. But
  the function never changes np, it just returns the np value
  passed to it, so the assignment is pointless and that function
  can be changed to a void.

src/cmd/ksh93/sh/fault.c: sh_fault():
- Remove check for sh.subshell after sh_isstate(SH_INTERACTIVE). As
  of 48ba6964, it is never set in subshells.
2022-07-14 17:34:08 +02:00
Martijn Dekker
adc6a64b82 Fix bad job control msg on trapped SIGINT and set -b (re: fc655f1)
When running an external command while trapping Ctrl+C via SIGINT,
and set -b is on, then a spurious Done job control message is
printed. No background job was executed.

    $ trap 'ls' INT
    $ set -b
    $ <Ctrl+C>[file listing follows]

    [1] +  Done                    set -b

In jobs.c (487-493), job_reap() calls job_list() to list a running
or completed background job, passing the JOB_NFLAG bit to only
print jobs with the P_NOTIFY flag. But the 'ls' in the trap is not
a background job. So it is getting the P_NOTIFY flag by mistake.

In fact all processes get the P_NOTIFY flag by default when they
terminate. Somehow the shell normally does not follow a code path
that calls job_list() for foreground processes, but does when
running one from a trap. I have not yet figured out how that works.

What I do know is that there is no reason why non-background
processes should ever have the P_NOTIFY flag set on termination,
because those should never print any 'Done' messages. And we seem
to have a handy P_BG flag that is set for background processes; we
can check for this before setting P_NOTIFY. The only thing is that
flag is only compiled in if SHOPT_BGX is enabled, as it was added
to support that functionality.

For some reason I am unable to reproduce the bug in a pty session,
so there is no pty.sh regression test.

src/cmd/ksh93/sh/jobs.c:
- Rename misleadingly named P_FG flag to P_MOVED2FG; this flag is
  not set for all foreground processes but only for processes moved
  to the foreground by job_switch(), called by the fg command.
- Compile in the P_BG flag even when SHOPT_BGX is not enabled. We
  need to set this flag to check for a background job.
- job_reap(): Do not set the P_NOTIFY flag for all terminated
  processes, but only for those with P_BG set.

src/cmd/ksh93/sh/xec.c: sh_fork():
- Also pass special argument 1 for background job to job_post() if
  SHOPT_BGX is not enabled. This is what gets it to set P_BG.
- Simplify 5 lines of convoluted code into 1.

Resolves: https://github.com/ksh93/ksh/issues/481
2022-07-14 07:02:30 +02:00
Martijn Dekker
ffee9100d5 Robustify ${.sh.level} scope switching (re: 69d37d5e, e1c41bb2)
Switching the function scope to a parent scope by assigning to
.sh.level (SH_LEVELNOD) leaves the shell in an inconsistent state,
causing invalid-free and/or use-after-free bugs. The intention of
.sh.level was always to temporarily switch scopes inside a DEBUG
trap, so this commit minimises the pitfalls and instability by
imposing some sensible limitations:
1. .sh.level is now a read-only variable except while executing a
   DEBUG trap;
2. while it's writeable, attempts to unset .sh.level or to change
   its attributes are ignored;
3. attempts to set a discipline function for .sh.level are ignored;
4. it is an error to set a level < 0 or > the current scope.

Even more crashing bugs are fixed by simplifiying the handling and
initialisation of .sh.level and by exempting it completely from
virtual subshell scoping (to which it's irrelevant).

TODO: one thing remains: scope corruption and use-after-free happen
when using the '.' command inside a DEBUG trap with ${.sh.level}
changed. Behaviour same as before this commit. To be investigated.

All changed files:
- Consistently use the int16_t type for level values as that is the
  type of its non-pointer storage in SH_LEVELNOD.
- Update .sh.level by using an update_sh_level() macro that assigns
  directly to the node value, then restores the scope if needed.
- To eliminate implicit typecasts, use the same int16_t type (the
  type used by short ints such as SH_LEVELNOD) for all variables
  containing a function and/or dot script level.

src/cmd/ksh93/include/variables.h:
- Add update_sh_level() macro.

src/cmd/ksh93/include/name.h,
src/cmd/ksh93/sh/macro.c:
- Add a nv_nonptr() macro that checks attributes for a non-pointer
  value -- currently only signed or unsigned short integer value,
  accessed via the 's' member of 'union Value' (e.g. np->nvalue.s).
- nv_isnull(): To avoid undefined behaviour, check for attributes
  indicating a non-pointer value before accessing the nvalue.cp
  pointer (re: 5aba0c72).
- varsub(): In the set/unset check, remove the now-redundant
  exception for SH_LEVELNOD.

src/cmd/ksh93/data/variables.c,
src/cmd/ksh93/sh/init.c:
- shtab_variables[]: Make .sh.level a read-only short integer.
- sh_inittree(): To avoid undefined behaviour, do not assign to the
  'union Value' char pointer if the attribute indicates a non-
  pointer short integer value. Instead, the table value is ignored.

src/cmd/ksh93/sh/subshell.c: sh_assignok():
- Never create a subshell scope for SH_LEVELNOD.

src/cmd/ksh93/sh/xec.c:
- Get rid of 'struct Level' and its maxlevel member. This was only
  used in put_level() to check for an out of range assignment, but
  this can be trivially done by checking sh.fn_depth+sh.dot_depth.
- This in turn allows further simplification that reduces init for
  .sh.level to a single nv_disc() call in sh_debug(), so get rid of
  init_level().
- put_level(): Throw a "level out of range" error if assigned a
  wrong level.
- sh_debug():
  - Turn off the NV_RDONLY (read-only) attribute for SH_LEVELNOD
    while executing the DEBUG trap.
  - Restore the current scope when trap execution is finished.
- sh_funct(): Remove all .sh.level handling. POSIX functions (and
  dot scripts) already handle it in b_dot_cmd(), so sh_funct(),
  which is used by both, is the wrong place to do it.
- sh_funscope(): Update .sh.level for ksh syntax functions here
  instead. Also, do not bother to initialise its discipline here,
  as it can now only be changed in a DEBUG trap.

src/cmd/ksh93/bltins/typeset.c: setall():
- When it's not read-only, ignore all attribute changes for
  .sh.level, as changing the attributes would crash the shell.

src/cmd/ksh93/sh/nvdisc.c: nv_setdisc():
- Ignore all attempts to set a discipline function for .sh.level,
  as doing this would crash the shell.

src/cmd/ksh93/bltins/misc.c: b_dot_cmd():
- Bug fix: also update .sh.level when quitting a dot script.

src/cmd/ksh93/sh/name.c:
- _nv_unset():
  - To avoid an inconsistent state, ignore all attempts to unset
    .sh.level.
  - To avoid undefined behaviour, do not zero np->nvalue.cp if
    attributes for np indicate a non-pointer value (the actual bit
    value of a null pointer is not defined by the standard, so
    there is no guarantee that zeroing .cp will zero .s).
- sh_setscope(): For consistency, always set error_info.id (the
  command name for error messages) to the new scope's cmdname.
  Previously this was only done for two calls of this function.
- nv_name(): Fix a crashing bug by checking that np->nvname is a
  non-null pointer before dereferencing it.

src/cmd/ksh93/include/nval.h:
- The NV_UINT16P macro (which is unsigned NV_INT16P) had a typo in
  it, which went unnoticed for many years because it's not directly
  used (though its bit flags are set and used indirectly). Let's
  fix it anyway and keep it for completeness' sake.
2022-07-13 23:11:18 +02:00
Martijn Dekker
7a01d6df47 history: fix out-of-bounds read on retrieving empty line
Reproducer: Compile a ksh with AddressSanitizer. In that ksh, edit
the last command line with 'fc', insert an empty line at the start,
and save. Now use the up-arrow to retrieve the empty line. Ksh
aborts on history.c line 1011 as hist_copy() tries to read before
the beginning of the buffer pointed to by s1.

src/cmd/ksh93/edit/history.c: hist_copy():
- Verify that the s1 pointer was increased from the original s1
  before trying to read the character *(s1-1).
2022-07-10 21:18:49 +02:00
Martijn Dekker
1934686de3 Fix oddly specific syntax error corrupting subsequent [[ ... ]]
Reproducer:

    $ x=([x]=1 [y)
    -ksh: syntax error: `)' unexpected
    $ [[ -z $x ]]
    -ksh: [[ -z  ]]: not found

Any '[[' command following that syntax error will fail similarly;
the whole of it (after variable expansion) is incorrectly looked up
as a command name. The syntax error must be generated by an
associative array assignment (with or without an explicit typeset
-A) with at least one valid assignment element followed by an
invalid assignment element starting with '[' but not containing
']='.

This seems to be another bug that is in every ksh93 version ever.
I've confirmed that ksh 1993-12-28 s+ and ksh2020 fail identically.
Presumably, so does everything in between.

Analysis:

The syntax error function, sh_syntax(), calls lexopen() in mode 0
to reset the lexer state. There is a variable that isn't getting
reset there though it should be. Using systematic elimination I
found that the variable that needs to be reset is lp->assignok (set
"when name=value is legal"). If it is set, '[[' is not processed.

src/cmd/ksh93/sh/lex.c: lexopen():
- Reset 'assignok' in the lexer state (regardless of mode).
- In the mode 0 total lexer state reinit, several members of lexd
  (struct _shlex_pvt_lexdata_) were not getting reset; just memset
  the whole thing to zero.
     Note for backporters: this change requires commit da97587e to
  be correct. That commit took the stack size and pointer (lex_max
  and *lex_match) out of this struct; those should not be reset!

Resolves: https://github.com/ksh93/ksh/issues/486
2022-07-09 23:00:11 +02:00
Martijn Dekker
7c4418ccdc Multibyte character handling overhaul; allow global disable
The SHOPT_MULTIBYTE compile-time option did not make much sense as
disabling it only disabled multibyte support for ksh/libshell, not
libast or libcmd built-in commands. This commit allows disabling
multibyte support for the entire codebase by defining the macro
AST_NOMULTIBYTE (e.g. via CCFLAGS). This slightly speeds up the
code and makes an optimised binary about 5% smaller.

src/lib/libast/include/ast.h:
- Add non-multibyte fallback versions of the multibyte macros that
  are used if AST_NOMULTIBYTE is defined. This should cause most
  multibyte handling to be automatically optimised out everywhere.
- Reformat the multibyte macros for legibility.
- Similify mbchar() and and mbsize() macros by defining them in
  terms of mbnchar() and mbnsize(), eliminating code duplication.
- Correct non-multibyte fallback of mbwidth(). For consistent
  behaviour, control characters and out-of-range values should
  return -1 as they do for UTF-8. The fallback is now the same as
  default_wcwidth() in src/lib/libast/comp/setlocale.c.

src/lib/libast/comp/setlocale.c:
- If AST_NOMULTIBYTE is defined, do not compile in the debug and
  UTF-8 locale conversion functions, including several large
  conversion tables. Define their fallback macros as 0 as these are
  used as function pointers.

src/cmd/ksh93/SHOPT.sh,
src/cmd/ksh93/Mamfile:
- Change the SHOPT_MULTIBYTE default to empty, indicating "probe".
- Synchronise SHOPT_MULTIBYTE with !AST_NOMULTIBYTE by default.

src/cmd/ksh93/include/defs.h:
- When SHOPT_MULTIBYTE is zero but AST_NOMULTIBYTE is not non-zero,
  then enable AST_NOMULTIBYTE here to use the ast.h non-multibyte
  fallbacks for ksh. When this is done, the effect is that
  multibyte is optimized out for ksh only, as before.
- Remove previous fallback for disabling multibyte (re: c2cb0eae).

src/cmd/ksh93/include/lexstates.h,
src/cmd/ksh93/sh/lex.c:
- Define SETLEN() macro to assign to LEN (i.e. _Fcin.fclen) for
  multibyte only and do not assign to it directly. With no
  SHOPT_MULTIBYTE, define that macro as empty. This allows removing
  multiple '#if SHOPT_MULTIBYTE' directives from lex.c, as that
  code will all be optimised out automatically if it's disabled.

src/cmd/ksh93/include/national.h,
src/cmd/ksh93/sh/string.c:
- Fix flagrantly incorrect non-multibyte fallback for sh_strchr().
  The latter returns an integer offset (-1 if not found), whereas
  strchr(3) returns a char pointer (NULL if not found). Incorporate
  the fallback into the function for correct handling instead of
  falling back to strchr(3) directly.

src/cmd/ksh93/sh/macro.c:
- lastchar() optimisation: avoid function call if SHOPT_MULTIBYTE
  is enabled but we're not actually in a multibyte locale.

src/cmd/ksh93/sh/name.c:
- Use ja_size() even with SHOPT_MULTIBYTE disabled (re: 2182ecfa).
  Though no regression tests failed, the non-multibyte fallback for
  typeset -L/-R/-Z length calculation was probably not quite
  correct as ja_size() does more. The ast.h change to mbwidth()
  ensures correct behaviour for non-multibyte locales.

src/cmd/ksh93/tests/shtests:
- Since its value in SHOPT.sh is now empty by default, add a quick
  feature test (for the length of the UTF-8 character 'é') to check
  if SHOPT_MULTIBYTE needs to be enabled for the regression tests.
2022-07-09 00:32:27 +02:00
Martijn Dekker
06e56251b9 Fix wrong syntax error upon process substitution after redirection
Grammatically, redirections may occur anywhere within a command
line and are removed after processing them, whereas a process
substitution (<(commandlist) or >(commandlist)) is replaced by a
file name which should be treated as just another simple word.
So the following should not be a syntax error:

$ cat </dev/null <(true)
-ksh: syntax error: `)' unexpected
$ cat </dev/null >(true)
-ksh: syntax error: `)' unexpected
$ cat >/dev/null <(true)
-ksh: syntax error: `)' unexpected
$ cat >/dev/null >(true)
-ksh: syntax error: `)' unexpected

This bug is in every ksh93 version.

The problem is in the parser (parse.c). The process substitution is
misparsed as a redirection due to inout() recursively parsing
multiple redirections without recognising process substitutions.
inout() is mistaking '<(' for '<' and '>(' for '>', which explains
the incorrect syntax error.

This also causes the following to fail to detect a syntax error:
$ cat >&1 <(README.md
[the contents of README.md are shown]

...and other syntax errors detected in the wrong spot, for example:
$ { true; } <(echo wrong)
-ksh: syntax error: `wrong' unexpected
which should be:
-ksh: syntax error: `<(' unexpected

src/cmd/ksh93/sh/parse.c:
- Add global inout_found_procsub flag.
- inout(): On encountering a process substitution, set this flag
  and return, otherwise clear the flag.
- simple(): After calling inout(), check this flag and, if set,
  jump back to where process substitutions are parsed.

Resolves: https://github.com/ksh93/ksh/issues/418
2022-07-05 13:20:28 +02:00
Martijn Dekker
8a0920ea0a Yet another round of accumulated tweaks and cleanups
Notable changes:

- sh/timers.c: Rename timerdel() to sh_timerdel() for consistency;
  we had timerdel() but sh_timeradd().

- include/shell.h: Remove unused sh struct members:
  - sh.lastpath (this was still being saved/restored in several
    places, but not actually used since 2008-06-02 ksh93t-)
  - sh.lastbase (unused since 2000-10-31 ksh93k)
  - sh.inpool (unused since libcoshell was removed in 3613da42)

- sh/xec.c: sh_exec(): Add comments for the various command types.
2022-07-04 00:29:05 +02:00
Martijn Dekker
366efa4b06 restore C90 compat: do not repeat a typedef (re: 3e0da770)
We try to stay compatibile with C90. Turns out that repeating a
typedef is valid only from C11 onwards, as a feature taken from
C++. So I goofed and broke the build on old or strict compilers.

src/cmd/ksh93/include/{name,shell}.h:
- union Value: Since we will now once again have to typecast to use
  nvalue.bfp in any case, just make it a void pointer; that is how
  pointers that require typecasts are handled in every other case.
- Since the funptr() macro needs a typecast to Shbltin_f which is
  defined in libast's shcmd.h, move this macro to shell.h which
  (unlike name.h) includes that header.

src/cmd/ksh93/sh/{init,nvdisc}.c:
- Typecast to void* when assigning to *->nvalue.bfp.

src/lib/libast/include/shcmd.h:
- Use shell_h_defined (introduced in 4491bc6a) and defs_h_defined
  to check if ksh's shell.h or defs.h were included before shcmd.h,
  instead of random macros defined by them; much clearer.
2022-07-03 18:56:47 +02:00
Martijn Dekker
24c3d77e3c cleanup: remove redundant sh.st.execbrk flag
The 'break' and 'continue' flow control commands use three int
variables in the scoped sh.st struct:

	sh.st.execbrk:	nonzero if 'break' or 'continue' are used
	sh.st.breakcnt:	number of levels to 'break'/'continue'
			(negative if 'continue')
	sh.st.loopcnt:	loop level counter for 'break'/'continue'

Reading the code that sets and uses these (in bltins/cflow.c and
sh/xec.c) makes it fairly obvious that the sh.st.execbrk flag is
redundant; it is zero if no 'break' or 'continue' should happen,
but the same is true for sh.st.breakcnt.

This commit simplifies the code by removing sh.st.execbrk.
It also adds some comments clarifying the use of the other two.

Trivia: the ancient "Version 06/03/86a" ksh source code was
recently discovered. It uses global execbrk, breakcnt and loopcnt
variables with the same redundancy. More evidence that the AT&T
team always lacked a question-everything department...
https://minnie.tuhs.org/pipermail/tuhs/2020-December/022640.html
https://github.com/weiss/original-bsd/blob/master/local/toolchest/ksh/sh/builtin.c
https://github.com/weiss/original-bsd/blob/master/local/toolchest/ksh/sh/xec.c
2022-07-03 12:53:15 +02:00
Martijn Dekker
4df6d674a0 Fix signal exit status of last command in subshell (re: b3050769)
Reproducer (on macOS/*BSD where SIGUSR1 has signal number 30):

  $ ksh -c '(sh -c '\''kill -s USR1 $$'\''); echo $?'
  ksh: 54220: User signal 1
  30

Expected output for $?: 286, not 30. The signal is not reflected in
the 9th bit of the exit status.

This bug was introduced for virtual subshells in b3050769 but
exists in every ksh93 version for real (forked) subshells:

  $ ksh -c '(ulimit -t unlimited; trap : EXIT; \
	sh -c '\''kill -s USR1 $$'\''); echo $?'
  ksh: 54267: User signal 1
  30

(As of d6c9821c, a dummy trap is needed to trigger the bug, or it
will be masked by the exec optimization for the sh invocation.)

This is caused by the exit status being masked to 8 bits when a
subshell terminates. For a real subshell, this is inevitable as the
kernel does this. As of b3050769, virtual subshells behave in a
manner consistent with real subshells in this regard.

However, for both virtual and real subshells, if its last command
was terminated by a signal, then that should still be reflected in
the 9th bit of ksh's exit stauts.

The root of the problem is that ksh simply cannot rely internally
on the 9th bit of the exit status to determine if a command exited
due to a signal. The 9th bit may be trimmed by a subshell or may be
set by 'return' without a signal being involved. This commit fixes
it by introducing a separate flag which will be a reliable
indicator of this.

src/cmd/ksh93/include/shell.h:
- Add sh.chldexitsig flag (set if the last command was a child
  process that exited due to a signal).

src/cmd/ksh93/sh/jobs.c: job_wait():
- When the last child process exited due to a signal, not only set
  the 9th (SH_EXITSIG) bit of sh.exitval but also sh.chldexitsig.

src/cmd/ksh93/sh/subshell.c: sh_subshell():
- Fix the virtual subshell reproducer above. After trimming the
  exit status to 8 bit, set the 9th bit if sh.chldexitsig is set.
  This needs to be done in two places: one that runs in the parent
  process after sh_subfork() and one for the regular virtual
  subshell exit.

src/cmd/ksh93/sh/fault.c:
- sh_trap(): Save and restore sh.chldexitsig so that this fix does
  not get deactivated if a trap is set.
- sh_done():
  - Fix the real subshell reproducer above. When the last command
    of a real subshell is a child process that exited due to a
    signal (i.e., if (sh.chldexitsig && sh.realsubshell)), then
    activate the code to pass down the signal to the parent
    process. Since there is no way to pass a 9-bit exit status to a
    parent process, this is the only way to ensure a correct exit
    status in the parent shell environment.
  - When exiting the main shell, use sh.chldexitsig and not the
    unreliable SH_EXITSIG bit to determine if the 8th bit needs to
    be set for a portable exit status indicating its last command
    exited due to a signal.
2022-07-03 12:49:36 +02:00
Martijn Dekker
3688842b72 [v1.0] rm unused sh.st.timetrap (re: 4d50b69c) 2022-07-03 10:29:57 +02:00
Martijn Dekker
372d704bfb {edit,fault}.c: improve SIGWINCH and SIGINT handling
The fault.c and edit.c changes in this commit were inspired by
changes in the 93v- beta but take a slightly different approach:
mainly, the code to update $COLUMNS and $LINES is put in its own
function instead of duplicated in sh_chktrap() and ed_setup().

src/cmd/ksh93/sh/fault.c:
- Move code to update $COLUMNS and $LINES to a new
  sh_update_columns_lines() function so it can be reused.
- Fix compile error on systems without SIGWINCH.

src/cmd/ksh93/edit/edit.c:
- ed_setup(): Call sh_update_columns_lines() instead of issuing
  SIGWINCH to self.
- Change two sh_fault(SIGINT) calls to issuing the signal to the
  current process using kill(2). sh_fault() is now never called
  directly (as in the 93v- beta).

src/cmd/ksh93/sh/main.c: sh_main():
- On non-interactive, call sh_update_columns_lines() and set the
  signal handler for SIGWINCH to sh_fault(), causing $COLUMNS and
  $LINES to be kept up to date when the terminal window is resized
  (this is handled elsewhere for interactive shells). This change
  makes ksh act like mksh, bash and zsh. (Previously, ksh required
  setting a dummy SIGWINCH trap to get auto-updated $COLUMNS and
  $LINES in scripts, as this set the SIGWINCH signal handler to
  sh_fault(). This persisted even after unsetting the trap again,
  so that was inconsistent behaviour.)

src/cmd/ksh93/include/shell.h:
- Don't define sh.winch on systems without SIGWINCH.

src/cmd/ksh93/sh.1:
- Update and tweak the COLUMNS and LINES variable documentation.
- Move them up to the section of variables that are set by the
  shell (which AT&T should have done before).
2022-07-01 22:49:40 +02:00
Martijn Dekker
416a412d71 Fix seeking on block devices with FD 0, 1 or 2
@stephane-chazelas reports:
> A very weird issue:
>
> To reproduce on GNU/Linux (here as superuser)
>
> # truncate -s10M file
> # export DEV="$(losetup -f --show file)"
> # ksh -c 'exec 3<> "$DEV" 3>#((0))'   # fine
> # ksh -c 'exec 1<> file 1>#((0))'     # fine
> # ksh -c 'exec 1<> "$DEV" 1>#((0))'
> ksh: 0: invalid seek offset
>
> Any seek offset is considered "invalid" as long as the file is a
> block device and the fd is 0, 1 or 2. It's fine for fds above 2
> and it's fine with any fd for regular files.

Apparently, block devices are not seekable with sfio. In io.c there
is specific code to avoid using sfio's sfseek(3) if there is no
sfio stream in sh.sftable[] for the file descriptor in question:

1398:	Sfio_t *sp = sh.sftable[fn];
[...]
1420:		if(sp)
1421:		{
1422:			off=sfseek(sp, off, SEEK_SET);
1423:			sfsync(sp);
1424:		}
1425:		else
1426:			off=lseek(fn, off, SEEK_SET);

For file descriptors 0, 1 or 2 (stdin/stdout/stderr), there is a
sh.sftable[] stream by default, and it is marked as not seekable.
This makes it return -1 in these lines in sfseek.c, even if the
system call called via SFSK() succeeds:

89:	if(f->extent < 0)
90:	{	/* let system call set errno */
91:		(void)SFSK(f,(Sfoff_t)0,SEEK_CUR,f->disc);
92:		return (Sfoff_t)(-1);
93:	}

...which explains the strange behaviour.

src/lib/libast/sfio/sfseek.c: sfseek():
- Allow for the possibility that the fallback system call might
  succeed: let it handle both errno and the return value.

Resolves: https://github.com/ksh93/ksh/issues/318
2022-06-28 22:18:46 +02:00
Martijn Dekker
cc1689849e Another round of tweaks
Notable changes:
- Change a bunch of uses of memcmp(3) to compare strings (which can
  cause buffer read overflows) to strncmp(3).
- src/cmd/ksh93/include/name.h: Eliminate redundant Nambfp_f type.
  Replace with Shbltin_f type from libast's shcmd.h. Since that is
  not guaranteed to be included here, repeat the type definition
  here without fully defining the struct (which is valid in C).
2022-06-24 15:34:55 +01:00
Martijn Dekker
da97587e9e lex.c: prevent restoring outdated stack pointer
Lexical levels are stored in a dynamically grown array of int values
grown by the stack_grow function. The pointer lex_match and the
maximum index lex_max are part of the lexer state struct that is now
saved and restored in various places -- see e.g. 37044047, a2bc49be.
If the stack needs to be grown, it is reallocated in stack_grow()
using sh_realloc(). If that happens between saving and restoring the
lexer state, then an outdated pointer is restored, and crash.

src/cmd/ksh93/include/shlex.h,
src/cmd/ksh93/sh/lex.c:
- Take lex_match and lex_max out of the lexer state struct and make
  them separate static variables.

src/cmd/ksh93/edit/edit.c:
- While we're at it, save and restore the lexer state in a way that
  is saner than the 93v- beta approach (re: 37044047) as well as
  more readable. Instead of permanently allocating memory, use a
  local variable to save the struct. Save/restore directly around
  the sh_trap() call that actually needs this done.

Resolves: https://github.com/ksh93/ksh/issues/482
2022-06-23 03:35:48 +01:00
Martijn Dekker
d8dc2a1d81 sh_setenviron(): deactivate compound assignment prefix
Reproducers:

$ ksh -c 'typeset -a arr=( ( (a $(($(echo 1) + 1)) c)1))'
ksh: echo: arr[0]._AST_FEATURES=CONFORMANCE - ast UNIVERSE - ucb: cannot be an array
ksh: [1]=1: invalid variable name
$ ksh -c 'typeset -a arr=( (a $(($(echo 1) + 1)) c)1)'
ksh: echo: arr._AST_FEATURES=CONFORMANCE - ast UNIVERSE - ucb: is not an identifier
ksh: [1]=1: invalid variable name

src/cmd/ksh93/sh/name.c: sh_setenviron():
- Save and clear the current compound assignment prefix (sh.prefix)
  while assigning to the _AST_FEATURES variable.
2022-06-23 03:34:16 +01:00
Martijn Dekker
4d50b69cbd [v1.0] remove alarm builtin
It's undocumented, it's broken and can crash the shell, and it's
unclear if it can ever be fixed. So with a 1.0 release (hopefully)
not very far off, it's time to remove it from the 1.0 branch.

Related: https://github.com/ksh93/ksh/issues/422
2022-06-21 05:45:53 +01:00
Martijn Dekker
cae9af5eec tweak: make better use of funptr() macro and sh.bltinfun pointer
src/cmd/ksh93/include/name.h:
- Include the ususally-wanted (Shbltin_f) typecast in funptr().

Various files:
- Change several direct foo->nvalue.bfp usages to funptr(np).
- Reduce explicit typecasts after the name.h change.
- To determine if we are (or just were) running a certain built-in
  command, instead of comparing sh.bltindata.bnode with a builtin
  table node, use sh.bltinfun to directly compare the builtin's
  function; this is more readable and efficient.
2022-06-20 22:25:41 +01:00
Martijn Dekker
05fc199c95 More 'command -x' robustification (re: 6f6b2201, 6a0e9a1a, 66e1d446)
The xargs-like functionality of 'command -x' was still failing with
E2BIG in cases or on systems where the environment variables list
is very large. For instance, on a default NixOS installation it's
about 50k by default (absurd; *each* process carries this weight).

This commit tweaks the feature test and introduces a runtime
fallback if it still fails.

POSIX: "The number of bytes available for the new process' combined
argument and environment lists is {ARG_MAX}. It is implementation-
defined whether null terminators, pointers, and/or any alignment
bytes are included in this total."
https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

More recommended reading:
https://mina86.com/2021/the-real-arg-max-part-1/
https://mina86.com/2021/the-real-arg-max-part-2/

So, operating systems are free to consume ARG_MAX space in whatever
bizarre way they want, and may even come up with more innovative
ways to waste buffer space in future. <sigh>

command_xargs() allows for the possibility of adding a certain
number of extra bytes per argument to account for pointers and
whatnot. As of this commit, we still start off from the value that
was determined by the _arg_extrabytes test in features/externs, but
path_spawn() will now increase that number at runtime and retry if
E2BIG still occurs. Hopefully this makes it future-proof.

src/cmd/ksh93/features/externs:
- Rename generated ARG_EXTRA_BYTES macro to _arg_extrabytes for
  better naming consistency with other iffe feature tests.
- Tweaks to avoid detecting 9 extra bytes instead of 8 on some
  versions of 64-bit Linux (it needs the size of a 64 bit pointer).
- Show the result in the iffe output.

src/cmd/ksh93/include/shell.h,
src/cmd/ksh93/sh/init.c:
- Do not store getconf(CONF_ARG_MAX) at init time; on Linux, this
  value may be changed dynamically (via ulimit -s), so it must be
  re-obtained on every use.

src/cmd/ksh93/sh/path.c:
- command_xargs():
  - Use a static global variable for the number of extra bytes per
    argument. Initialise it with the results of the feature test.
    This allows increasing it at runtime if an OS does something
    weird causing an E2BIG failure.
  - Abort instead of return if command_xargs() is called with
    sh.xargmin < 0; this should never happen.
  - To allow retrying without crashing, restore saved args before
    returning -1.
  - Leave more generous space for the environment -- half the size
    of the existing environment. This was experimentally determined
    to be needed to keep Linux and macOS happy.
  - Instead of crashing, return with E2BIG if there is too little
    space to run.
  - Get rid of unnecessary (void*) typecasts; we no longer pretend
    to be compatible with C++ (re: a34e8319).
  - Remove a couple of dead 'if(saveargs) free(saveargs);'
    statements; at those points, saveargs is known to be NULL.
  - Return -2 instead of -1 when retrying would be pointless.
- path_spawn():
  - When command_xargs() returns -1 and the error is E2BIG,
    increase the number of extra bytes by the size of a char*
    pointer and try again. Give up if adding bytes the size of 8
    char* pointers fails.

src/cmd/ksh93/sh/xec.c: check_exec_optimization():
- Do not use this optimization if we are running 'command -x';
  I noticed some instances of the PATH search yielding incorrect
  results if we do. TODO: work this out at some point.
2022-06-20 20:39:41 +01:00
Martijn Dekker
225323f138 Fix more "/dev/null: cannot create" (re: 411481eb)
Reproducer:

  trap : USR1
  while :; do kill -s USR1 $$ || exit; done &
  while :; do : >/dev/null; done

It can take between a fraction of a second and a few minutes, but
eventually it will fail like this:

  $ ksh foo
  foo[3]: /dev/null: cannot create
  kill: 77946: no such process

It fails similarly with "cannot open" if </dev/null is used instead
of >/dev/null.

This is the same problem as in the referenced commit, except when
handling traps -- so the same fix is required in sh_fault().
2022-06-20 19:39:00 +01:00
Martijn Dekker
627058e862 Yet more accumulated tweaks and cleanups
Notable changes:

src/cmd/ksh93/bltins/trap.c: b_trap():
- Disable the unadvertised 'trap + SIG' feature in POSIX mode; it's
  not compatible as '+' is a legitimate command name.

src/cmd/ksh93/data/builtins.c:
- Give "pwd", "alarm" and "times" the BLT_ENV flag for better
  performance. There is no need for those to be stoppable.

src/cmd/ksh93/sh/xec.c:
- sh_eval(): Remove a "temporary tksh hack" and associated
  sh.fn_reset flag.
- sh_exec():
  - Remove now-used 'unpipe' flag and one remaining dead check for
    it (re: a2196f94, 4b22fd5d).
  - Fix unnecessary and confusing reuse of the 'type' variable.

src/lib/libast/comp/conf.sh:
- trap: Use 'rm -rf' instead of 'rm -f' to remove temp executables;
  on macOS, they may include *.dSYM directories.
2022-06-18 23:29:49 +01:00
Martijn Dekker
40245e088d Fix the exec optimisation mess (re: 17ebfbf6, 6701bb30, d6c9821c)
This commit supersedes @lijog's Solaris patch 280-23332860 (see
17ebfbf6) as this is a more general fix that makes the patch
redundant. Of course its associated regression tests stay.

Reproducer script:

	trap 'echo SIGUSR1 received' USR1
	sh -c 'kill -s USR1 $PPID'

Run as a normal script.
Expected behaviour: prints "SIGUSR1 received"
Actual behaviour: the shell invoking the script terminates. Oops.

As of 6701bb30, ksh again allows an exec-without-fork optimisation
for the last command in a script. So the 'sh' command gets the same
PID as the script, therefore its parent PID ($PPID) is the invoking
script and not the script itself, which has been overwritten in
working memory. This shows that, if there are traps set, the exec
optimisation is incorrect as the expected process is not signalled.

While 6701bb30 reintroduced this problem for scripts, this has
always been an issue for certain other situations: forked command
substitutions, background subshells, and -c option argument
scripts. This commit fixes it in all those cases.

In sh_exec(), case TFORK, the optimisation (flagged in no_fork) was
only blocked for SIGINT and for the EXIT and ERR pseudosignals.
That is wrong. It should be blocked for all signal and pseudosignal
traps, except DEBUG (which is run before the command) and SIGKILL
and SIGSTOP (which cannot be trapped).

(I've also tested the behaviour of other shells. One shell, mksh,
never does an exec optimisation, even if no traps are set. I don't
know if that is intentional or not. I suppose it is possible that a
script might expect to receive a signal without trapping it first,
and they could conceivably be affected the same way by this exec
optimisation. But the ash variants (e.g. Busybox ash, dash, FreeBSD
sh), as well as bash, yash and zsh, all do act like this, so the
behaviour is very widespread. This commit makes ksh act like them.)

Multiple files:
- Remove the sh.errtrap, sh.exittrap and sh.end_fn flags and their
  associated code from the superseded Solaris patch.

src/cmd/ksh93/include/shell.h:
- Add a scoped sh.st.trapdontexec flag for sh_exec() to disable
  exec-without-fork optimisations. It should be in the sh.st scope
  struct because it needs to be reset in subshell scopes.

src/cmd/ksh93/bltins/trap.c: b_trap():
- Set sh.st.trapdontexec if any trap is set and non-empty (an empty
  trap means ignore the signal, which is inherited by an exec'd
  process, so the optimisation is fine in that case).
- Only clear sh.st.trapdontexec if we're not in a ksh function
  scope; unlike subshells, ksh functions fall back to parent traps
  if they don't trap a signal themselves, so a ksh function's
  parent traps also need to disable the exec optimisation.

src/cmd/ksh93/sh/fault.c: sh_sigreset():
- Introduce a new -1 mode for sh_funscope() to use, which acts like
  mode 0 except it does not clear sh.st.trapdontexec. This avoids
  clearing sh.st.trapdontexec for ksh functions scopes (see above).
- Otherwise, clear sh.st.trapdontexec whenever traps are reset.

src/cmd/ksh93/sh/xec.c: check_exec_optimization():
- Consolidate all the exec optimisation logic into this function,
  including the logic from the no_fork flag in sh_exec()/TFORK.
- In the former no_fork flag logic, replace the three checks for
  SIGINT, ERR and EXIT traps with a single check for the
  sh.st.trapdontexec flag.
2022-06-18 23:27:10 +01:00
Martijn Dekker
16b3802148 Fix incorrect exec optimisation with monitor/pipefail on
Reproducer script:
    tempfile=/tmp/out2.$$.$RANDOM
    bintrue=$(whence -p true)
    for opt in monitor pipefail
    do
            (
                    set +x -o "$opt"
                    (
                            sleep .05
                            echo "ok $opt" >&2
                    ) 2>$tempfile | "$bintrue"
            ) &
            wait
            cat "$tempfile"
            rm -f "$tempfile"
    done

Expected output:
    ok monitor
    ok pipefail

Actual output:
    (none)

The 'monitor' and 'pipefail' options are supposed to make the shell
wait for the all commands in the pipeline to terminate and not only
the last component, regardless of whether the pipe between the
component commands is still open. In the failing reproducer, the
dummy external true command is subject to an exec optimization, so
it replaces the subshell instead of forking a new process. This is
incorrect, as the shell is no longer around to wait for the
left-hand part of the pipeline, so it continues in the background
without being waited for. Since it writes to standard error after
.05 seconds (after the pipe is closed), the 'cat' command reliably
finds the temp file empty. Without the sleep this would be a race
condition with unpredictable results.

Interestingly, this bug is only triggered for a (background
subshell)& and not for a forked (regular subshell). Which means the
exec optimization is not done for a forked regular subshell, though
there is no reason not to. That will be fixed in the next commit.

src/cmd/ksh93/sh/xec.c: sh_exec():
- case TFORK: Never allow an exec optimization if we're running a
  command in a multi-command pipeline (pipejob is set) and the
  shell needs to wait for all pipeline commands, i.e.: either the
  time keyword is in use, the SH_MONITOR state is active, or the
  SH_PIPEFAIL option is on.
- case TFIL: Fix the logic for setting job.waitall for the
  non-SH_PIPEFAIL case. Do not 'or' in the boolean value but assign
  it, and include the SH_TIMING (time keyword in use) state too.
- case TTIME: After that fix in case TFIL, we don't need to bother
  setting job.waitall explicitly here.

src/cmd/ksh93/sh.1:
- Add missing documentation for the conditions where the shell
  waits for all pipeline components (time, -o monitor/pipefail).

Resolves: https://github.com/ksh93/ksh/issues/449
2022-06-18 23:25:30 +01:00