1
0
Fork 0
mirror of git://git.code.sf.net/p/cdesktopenv/code synced 2025-02-13 03:32:24 +00:00
cde/NEWS

410 lines
16 KiB
Text
Raw Normal View History

Fix BUG_CASELIT: pattern matching as literal string in 'case' This fixes an undocumented 'case' pattern matching misbehaviour (labelled BUG_CASELIT in modernish) that goes back to the original Bourne shell, but wasn't discovered until 2018. If a pattern doesn't match as a pattern, it's tried again as a literal string. This breaks common validation use cases, such as: n='[0-9]' case $n in ( [0-9] ) echo "$n is a number" ;; esac would output "[0-9] is a number" as the literal string fallback matches the pattern. As this misbehaviour was never documented anywhere (not for Bourne, ksh88, or ksh93), and it was never replicated in other shells (not even in ksh88 clones pdksh and mksh), it is unlikely any scripts rely on it. Of course, a literal string fallback, should it be needed, is trivial to implement correctly without this breakage: case $n in ( [0-9] | "[0-9]") echo "$n is a number or the number pattern" ;; esac src/cmd/ksh93/sh/xec.c: - Remove trim_eq() function responsible for implementing the misbehaviour described above. NEWS: - Added. Document this bugfix. Ref.: - The problem: thread starting at https://www.mail-archive.com/austin-group-l@opengroup.org/msg02127.html - The solution, thanks to George Koehler: comments/commits in https://github.com/att/ast/issues/476 - Modernish BUG_CASELIT bug test & documentation: https://github.com/modernish/modernish/commit/b2024ae3 (cherry picked from commit 8d6c8ce69884767a160c1e20049e77bdd849c248 with some extra edits to NEWS to upate the info for this reboot)
2020-06-11 15:14:31 +00:00
This documents significant changes in the 93u+m branch of AT&T ksh93.
2020-06-14 04:28:38 +00:00
For full details, see the git log at: https://github.com/ksh93/ksh
Fix BUG_CASELIT: pattern matching as literal string in 'case' This fixes an undocumented 'case' pattern matching misbehaviour (labelled BUG_CASELIT in modernish) that goes back to the original Bourne shell, but wasn't discovered until 2018. If a pattern doesn't match as a pattern, it's tried again as a literal string. This breaks common validation use cases, such as: n='[0-9]' case $n in ( [0-9] ) echo "$n is a number" ;; esac would output "[0-9] is a number" as the literal string fallback matches the pattern. As this misbehaviour was never documented anywhere (not for Bourne, ksh88, or ksh93), and it was never replicated in other shells (not even in ksh88 clones pdksh and mksh), it is unlikely any scripts rely on it. Of course, a literal string fallback, should it be needed, is trivial to implement correctly without this breakage: case $n in ( [0-9] | "[0-9]") echo "$n is a number or the number pattern" ;; esac src/cmd/ksh93/sh/xec.c: - Remove trim_eq() function responsible for implementing the misbehaviour described above. NEWS: - Added. Document this bugfix. Ref.: - The problem: thread starting at https://www.mail-archive.com/austin-group-l@opengroup.org/msg02127.html - The solution, thanks to George Koehler: comments/commits in https://github.com/att/ast/issues/476 - Modernish BUG_CASELIT bug test & documentation: https://github.com/modernish/modernish/commit/b2024ae3 (cherry picked from commit 8d6c8ce69884767a160c1e20049e77bdd849c248 with some extra edits to NEWS to upate the info for this reboot)
2020-06-11 15:14:31 +00:00
Any uppercase BUG_* names are modernish shell bug IDs.
2020-07-07:
- Four of the date formats accepted by 'printf %()T' have had their
functionality altered to the common behavior of date(1):
- '%k' and '%l' print the current hour with blank padding, the former
based on a 24-hour clock and the latter a twelve hour clock. These
are common extensions present on Linux and *BSD.
- '%l' prints the current hour (0-12) with blank padding (GNU and BSD).
- '%f' prints a date with the format string '%Y.%m.%d-%H:%M:%S' (BusyBox).
- '%q' prints the quarter of the year (GNU).
2020-07-06:
- 'notty' is now written to the ksh auditing file instead of '(null)' if
the user's tty could not be determined.
- Unsetting an associative array no longer causes a memory leak to occur.
Fix corrupt UTF-8 char processing & shellquoting after aborted read If the processing of a multibyte character was interrupted in UTF-8 locales, e.g. by reading just one byte of a two-byte character 'ü' (\303\274) with a command like: print -nr $'\303\274' | read -n1 g then the shellquoting algorithm was corrupted in such a way that the final quote in simple single-quoted string was missing. This bug may have had other, as yet undiscovered, effects as well. The problem was with corrupted multibyte character processing and not with the shell-quoting routine sh_fmtq() itself. Full trace and discussion at: https://github.com/ksh93/ksh/issues/5 (which is also an attempt to begin to understand the esoteric workings of the libast mb* macros that process UTF-8 characters). src/lib/libast/comp/setlocale.c: utf8_mbtowc(): - If called from the mbinit() macro (i.e. if both pointer parameters are null), reset the global multibyte character synchronisation state variable. This fixes the problem with interrupted processing leaving an inconsistent state, provided that mbinit() is called before processing multibyte characters (which it is, in most (?) places that do this). Before this fix, calling mbinit() in UTF-8 locales was a no-op. src/cmd/ksh93/sh/string.c: sh_fmtq(): - Call mbinit() before potentially processing multibyte characters. Testing suggests that this could be superfluous, but at worst, it's harmless; better be sure. src/cmd/ksh93/tests/builtins.sh: - Add regression test for shellquoting with 'printf %q' after interrupting the processing of a multibyte characeter with 'read -n1'. This test only fails in a UTF-8 locale, e.g. when running: bin/shtests -u builtins SHELL=/buggy/ksh-2012-08-01 Fixes #5.
2020-07-05 17:24:41 +00:00
2020-07-05:
- In UTF-8 locales, fix corruption of the shell's internal string quoting
algorithm (as used by xtrace, 'printf %q', and more) that occurred when
the processing of a multibyte character was interrupted.
Fix bugs with backslash escaping in interactive vi mode (#57) This commit fixes the following bugs in the 'vi' editing mode backslash escape feature. Ref.: Bolsky & Korn (1995), p. 113, which states for \: "Similar to Control+V [...] except that it escapes only the next Erase or Kill charactrer". 1. The vi mode now only escapes the next character if the last character input was a backslash, fixing the bug demonstrated at: https://asciinema.org/a/E3Rq3et07MMQG5BaF7vkXQTg0 2. Escaping backslashes are now disabled in vi.c if the vi mode is disabled (note that vi.c handles raw editing mode in UTF-8 locales). This makes the behavior of the raw editing mode consistent in C/POSIX and UTF-8 locales. 3. An odd interaction with Backspace when the character prior to a separate buffer entered with Shift-C was a backslash has been fixed. Demonstration at: https://asciinema.org/a/314833 ^? will no longer be output repeatedly when attempting to erase a separate buffer with a Backspace, although, to be consistent with vi(1), you still cannot backspace past it before escaping out of it. Ref.: https://github.com/ksh93/ksh/issues/56#issuecomment-653586994 src/cmd/ksh93/edit/vi.c: - Prevent a backslash from escaping the next input if the previous input wasn't a backslash. This is done by unsetting a variable named backslash if a backslash escaped a character. backslash is set to the result of c == '\\' when the user enters a new character. - Disable escaping backslashes in the raw editing mode because it should not be enabled there. src/cmd/ksh93/tests/pty.sh: - Add some tests for how ksh handles backslashes in each editing mode to test for the bugs fixed by this commit. Fixes #56.
2020-07-03 19:08:00 +00:00
2020-07-03:
- Backslashes are no longer escaped in the raw Bourne Shell-like editing
mode in multibyte locales, i.e. backslashes are no longer treated like
Control-V if the emacs and vi modes are disabled.
- Deleting a backslash in vi mode with Control-H or Backspace now only
escapes a backslash if it was the previous input. This means erasing a
string such as 'ab\\\' will only cause the first backslash to escape a
Backspace as '^?', like in emacs mode.
- An odd interaction with Backspace when the last character of a separate
buffer created with Shift-C was '\' has been fixed. '^?' will no longer
be output repeatedly when attempting to erase a separate buffer with
a Backspace. Note that buffers created with Shift-C are not meant to be
erasable:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_13_49
- The 'kill' builtin now supports the SIGINFO signal (on operating systems
with support for SIGINFO).
2020-07-02:
- Fixed a crash that occurred if a directory named '.paths' existed in any
directory listed in $PATH. The fix was to only read '.paths' if it is a
regular file or a symlink to a regular file.
2020-06-30:
- 'read -u' will no longer crash with a memory fault when given an out of
range or negative file descriptor.
- The '=~' operator no longer raises an error if a regular expression
combines the '{x}' quantifier with a sub-expression.
Fix BUG_CASELIT: pattern matching as literal string in 'case' This fixes an undocumented 'case' pattern matching misbehaviour (labelled BUG_CASELIT in modernish) that goes back to the original Bourne shell, but wasn't discovered until 2018. If a pattern doesn't match as a pattern, it's tried again as a literal string. This breaks common validation use cases, such as: n='[0-9]' case $n in ( [0-9] ) echo "$n is a number" ;; esac would output "[0-9] is a number" as the literal string fallback matches the pattern. As this misbehaviour was never documented anywhere (not for Bourne, ksh88, or ksh93), and it was never replicated in other shells (not even in ksh88 clones pdksh and mksh), it is unlikely any scripts rely on it. Of course, a literal string fallback, should it be needed, is trivial to implement correctly without this breakage: case $n in ( [0-9] | "[0-9]") echo "$n is a number or the number pattern" ;; esac src/cmd/ksh93/sh/xec.c: - Remove trim_eq() function responsible for implementing the misbehaviour described above. NEWS: - Added. Document this bugfix. Ref.: - The problem: thread starting at https://www.mail-archive.com/austin-group-l@opengroup.org/msg02127.html - The solution, thanks to George Koehler: comments/commits in https://github.com/att/ast/issues/476 - Modernish BUG_CASELIT bug test & documentation: https://github.com/modernish/modernish/commit/b2024ae3 (cherry picked from commit 8d6c8ce69884767a160c1e20049e77bdd849c248 with some extra edits to NEWS to upate the info for this reboot)
2020-06-11 15:14:31 +00:00
2020-06-28:
- Variables created with 'typeset -RF' no longer cause a memory fault
when accessed.
- Unsetting an array that was turned into a compound variable will no
longer cause silent memory corruption.
- Variables created with 'readonly' in functions are now set to the
specified value instead of nothing. Note that 'readonly' does not
create a function-local scope, unlike 'typeset -r' which does.
2020-06-26:
- Changing to a directory that has a name starting with a '.' will no
longer fail if preceded by '../' (i.e. 'cd ../.local' will now work).
2020-06-24:
- Fixed buggy tab completion of tilde-expanded paths such as
~/some in 'vi' mode.
- In the raw/default Bourne Shell-like editing mode that occurs when neither
the 'emacs' nor the 'vi' shell option is active:
* tab completion is now correctly disabled, instead of enabled and broken;
* entering tab characters now moves the cursor the correct amount.
2020-06-23:
- Fixed a bug that caused combining process substitution with redirection
to create a bizarre file in the user's current working directory.
- Using process substitution while the shell is interactive no longer
causes the process ID of the asynchronous process to be printed.
2020-06-22:
- The 'stop' and 'suspend' default aliases have been converted into regular
built-in commands, so that 'unalias -a' does not remove them, 'suspend'
can do a couple of sanity checks, and something like
cmd=stop; $cmd $!
will now work. See 'stop --man' and 'suspend --man' for more information.
- Fixed a bug that caused the kill and stop commands to segfault when given
a non-existent job.
- Nested functions no longer ignore variable assignments that were prefixed
to their parent function, i.e. 'VAR=foo func' will now set $VAR to 'foo'
in the scope of any nested function 'func' runs.
2020-06-20:
- Fixed a bug that caused setting the following variables as readonly in
a virtual subshell to affect the environment outside of the subshell:
$_
${.sh.name}
${.sh.subscript}
${.sh.level}
$RANDOM
$LINENO
- Fixed two bugs that caused `unset .sh.lineno` to always produce a memory
fault and `(unset .sh.level)` to memory fault when run in nested
functions.
2020-06-18:
- A two decade old bug that caused 'whence -a' to base the path of
tracked aliases on the user's current working directory has been
fixed. Now the real path to tracked aliases is shown when '-a' is
passed to the whence command.
2020-06-17:
- A bug in 'unset -f' was fixed that prevented shell functions from
unsetting themselves while they were running. A POSIX function no longer
crashes when doing so, and a KornShell-style function no longer silently
ignores an 'unset -f' on itself. A function of either form now continues
running after unsetting itself, and is removed at the end of the run.
2020-06-16:
- Passing the '-d' flag to the read builtin will no longer cause the '-r'
flag to be discarded when 'read -r -d' is run.
- Fix BUG_CMDSPASGN: preceding a "special builtin"[*] with 'command' now
prevents preceding invocation-local variable assignments from becoming global.
[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
2020-06-15:
- The 'source' alias has been converted into a regular built-in command.
Remove a buggy optimization for variables in subshells This bug was originally reported by @lijog in att/ast#7 and has been reported again in #15. KSH does not save the state of a variable if it is in a newer scope. This is because of an optimization in sh_assignok first introduced in ksh93t+ 2010-05-24. Here is the code change in that version: return(np); /* don't bother to save if in newer scope */ - if(!(rp=shp->st.real_fun) || !(dp=rp->sdict)) - dp = sp->var; - if(np->nvenv && !nv_isattr(np,NV_MINIMAL|NV_EXPORT) && shp->last_root) - dp = shp->last_root; - if((mp=nv_search((char*)np,dp,HASH_BUCKET))!=np) - { - if(mp || !np->nvfun || np->nvfun->subshell>=sh.subshell) - return(np); - } + if(sp->var!=shp->var_tree && shp->last_root==shp->var_tree) + return(np); if((ap=nv_arrayptr(np)) && (mp=nv_opensub(np))) { This change was originally made to replace a buggier optimization. However, the current optimization causes variables set in subshells to wrongly affect the environment outside of the subshell, as the variable does not get set back to its original value. This patch simply removes the buggy optimization to fix this problem. src/cmd/ksh93/sh/subshell.c: - Remove a buggy optimization that caused variables set in subshells to affect the environment outside of the subshell. src/cmd/ksh93/tests/subshell.sh: - Add a regression test for setting variables in subshells. This test has to be run from the disk after being created with a here document because it always returns the expected result when run directly in the regression test script.
2020-06-15 13:43:37 +00:00
- Functions that set variables in a virtual subshell will no longer affect
variables of the same name outside of the virtual subshell's environment.
- Terse usage messages written by builtin commands now point the user to
the --help and --man options for more information.
2020-06-14:
- 'read -S' is now able to correctly handle strings with double quotes
nested inside of double quotes.
2020-06-13:
2020-06-14 04:28:38 +00:00
- Fixed a timezone name determination bug on FreeBSD that caused the
output from `LC_ALL=C printf '%T' now` to print the wrong time zone name.
2020-06-11:
- Fixed a bug that caused running 'builtin -d' on a special builtin to
delete it. The man page for the 'builtin' command documents that special
builtins cannot be deleted.
- POSIX compliance fix: It is now possible to set shell functions named
'alias' or 'unalias', overriding the commands by the same names. In
technical terms, they are now regular builtins, not special builtins.
Make 'redirect' a regular builtin instead of an alias of 'exec' This commit converts the redirect='command exec' alias to a regular 'redirect' builtin command that only accepts I/O redirections, which persist as in 'exec'. This means that: * 'unlias -a' no longer removes the 'redirect' command; * users no longer accidentally get logged out of their shells if they type something intuitive but wrong, like 'redirect ls >file'. This should not introduce any legitimate change in behaviour. If someone did accidentally pass non-redirection arguments to 'redirect', unexpected behaviour would occur; this now produces an 'incorrect syntax' error. src/cmd/ksh93/bltins/misc.c: b_exec(): - Recognise 'redirect' when parsing options. - If invoked as 'redirect', produce error if there are arguments. src/cmd/ksh93/data/aliases.c: - Remove redirect='command exec' alias. src/cmd/ksh93/data/builtins.c: - Update/improve comments re ordering. - Add 'redirect' builtin entry. - sh_optexec[]: Abbreviate redirection-related documentation; refer to redirect(1) instead. - sh_optredirect[]: Add documentation. src/cmd/ksh93/include/builtins.h: - Add SYSREDIR parser ID, renumbering those following it. - Improve comments. - Add extern sh_optredirect[]. src/cmd/ksh93/sh.1: - exec: Abbreviate redirection-related documentation; refer to 'redirect' instead. - redirect: Add documentation. src/cmd/ksh93/sh/xec.c: - Recognise SYSREDIR parser ID in addition to SYSEXEC when determining whether to make redirections persistent. src/cmd/ksh93/tests/io.sh: - To regress-test the new builtin, change most 'command exec' uses to 'redirect'. - Add tests verifying the exit behaviour of 'exec', 'command exec', 'redirect' on redirections.
2020-06-12 02:17:14 +00:00
- The redirect='command exec' alias has been converted to a regular
'redirect' builtin command that only accepts I/O redirections, which
persist as in 'exec'. This means that:
* 'unlias -a' no longer removes the 'redirect' command;
* users no longer accidentally get logged out of their shells if
they type something intuitive but wrong, like 'redirect ls >file'.
Remove 'login' and 'newgrp' builtins: not sane default behaviour This commit removes the undocumented 'login' and 'newgrp' builtin commands. They already stopped blocking shell functions by that name by changing from special to regular builtins in 04b91718 (a change I forgot to mention in that commit message), but there is another obnoxious aspect to these: being glorified hooks into 'exec', they replaced your shell session with the external commands by the same name. This makes argument and error checking impossible, so if you made so much as a typo, you would be immediately logged out. Even if that behaviour is wanted by a few, having it as the default is user-hostile enough to be called a bug. It also violates the POSIX definition of the 'newgrp' utility which explicitly says that it "shall create a new shell execution environment", not replace the existing one. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/newgrp.html Users who do want this behaviour can easily restore it by setting: alias login='exec login' alias newgrp='exec newgrp' src/cmd/ksh93/bltins/misc.c: - As there is no more 'login' builtin, combine b_exec() and B_login() functions, which allows eliminating a few variables. Note that most of 'exec' was actually implemented in B_login()! src/cmd/ksh93/data/builtins.c: - Remove "login" and "newgrp" table entries. src/cmd/ksh93/include/builtins.h: - Remove SYSLOGIN parser ID. As this was the first, all the others needed renumbering. src/cmd/ksh93/sh/xec.c: - Remove SYSLOGIN parser check that made 'login' and 'newgrp' act like 'exec' and replace the shell.
2020-06-12 04:57:57 +00:00
- The undocumented 'login' and 'newgrp' builtin commands have been removed.
These replaced your shell session with the external commands by the same
name, as in 'exec'. If an error occurred (e.g. due to a typo), you would
end up immediately logged out.
If you do want this behaviour, you can restore it by setting:
alias login='exec login'
alias newgrp='exec newgrp'
Replace the hash alias with a proper builtin This commit replaces the old hash alias with a proper builtin. I based this builtin off of the code alias uses for handling `alias -t --`, but with the hack for `--` removed as it has no use in the new builtin. `alias -t --` will no longer work, that hack is now gone. While I was testing this builtin, I found a bug with hash tables in non-forking subshells. If the hash table of a non-forking subshell is changed, the parent shell's hash table is also changed. As an example, running `(hash -r)` was resetting the parent shell's hash table. The workaround is to force the subshell to fork if the hash table will be changed. src/cmd/ksh93/bltins/typeset.c: - Move the code for hash out of the alias builtin into a dedicated hash builtin. `alias -t --` is no longer supported. src/cmd/ksh93/data/aliases.c: - Remove the old alias for hash from the table of predefined aliases. src/cmd/ksh93/data/builtins.c: - Fix the broken entry for the hash builtin and add a man page for the new builtin. src/cmd/ksh93/sh.1: - Replace the entry for the hash alias with a more detailed entry for the hash builtin. src/cmd/ksh93/sh/name.c: - Force non-forking subshells to fork if the PATH is being reset to workaround a bug with the hash tree. src/cmd/ksh93/tests/alias.sh: - Add a regression test for resetting a hash table, then adding a utility to the refreshed hash table. src/cmd/ksh93/tests/subshell.sh: - Add regression tests for changing the hash table in subshells. (cherry picked from commit d8428a833afe9270b61745ba3d6df355fe1d5499)
2020-06-10 11:00:35 +00:00
2020-06-10:
- The 'hash' utility is now a regular builtin instead of an alias to
'alias -t --'. The functionality of the old command has been removed
from the alias builtin.
- Changing the hash table in a subshell will no longer affect the parent
shell's hash table. This fix applies to the hash utility and when the
PATH is reset manually.
- 'set +r' is no longer able to unset the restricted option. This change
makes the behavior of 'set +r' identical to 'set +o restricted'.
The unalias builtin should return an error for non-existent aliases This commit fixes a bug that caused unalias to return a zero status when it tries to remove an alias twice. The following set of commands will no longer end with an error: $ alias foo=bar $ unalias foo $ unalias foo && echo 'Error' This commit is based on the fix present in ksh2020, but it has been extended with another bugfix. The initial fix for this problem tried to remove aliases from the alias tree without accounting for NV_NOFREE. This caused any attempt to remove a predefined aliases (e.g. `unalias float`) to trigger an error with free, as all predefined aliases are in read-only memory. The fix for this problem is to set NV_NOFREE when removing aliases from the alias tree, but only if the alias is in read-only memory. All other aliases must be freed from memory to prevent memory leaks. I'll also note that I am using an `isalias` variable rather than the `type` enum from ksh2020, as the `VARIABLE` value is never used and was replaced with a bool called `aliases` in the ksh2020 release. The `isalias` variable is an int as the ksh93u+ codebase does not use C99 bools. Previous discussion: https://github.com/att/ast/issues/909 - src/cmd/ksh93/bltins/typeset.c: Remove aliases from the alias tree by using nv_delete. NV_NOFREE is only used when it is necessary. - src/cmd/ksh93/tests/alias.sh: Add two regression tests for the bugs fixed by this commit. (cherry picked from commit 16d5ea9b52ba51f9d1bca115ce8f4f18e97abbc4)
2020-06-09 15:31:00 +00:00
2020-06-09:
- The 'unalias' builtin will now return a non-zero status if it tries
to remove a previously set alias that is not currently set.
2020-06-08:
- Fix an issue with the up arrow key in Emacs editing mode.
Emacs editing mode is bugged in ksh93u+ and ksh2020. Let's
say you were to run the following commands after starting
a fresh instance of ksh:
$ alias foo='true'
$ unalias foo
If you type 'a' and then press the up arrow on your keyboard,
ksh will complete 'a' to `alias foo='true'` by doing a reverse
search for the last command that starts with 'a'.
Run the alias command again, then type 'u' and press the up
arrow key again. If ksh is in Vi mode, you will get `unalias foo`,
but in Emacs mode you will get `alias foo='true'` again.
All subsequent commands were ignored as ksh was saving the first
command and only based later searches off of it.
- If 'set -u'/'set -o nounset' is active, then the shell now errors out if a
nonexistent positional parameter such as $1, $2, ... is accessed, as other
shells do and POSIX requires. (This does *not* apply to "$@" and "$*".)
- If 'set -u'/'set -o nounset' is active, then the shell now errors out if $!
is accessed before the shell has launched any background process.
- Removed support for an obscure early 1990s Bell Labs file system research
project called 3DFS, which has not existed for decades. This removes:
- an obnoxious default alias 2d='set -f;_2d' that turned off your file name
wildcard expansion and then tried to run a nonexistent '_2d' command
- undocumented builtins 'vmap' and 'vpath' that only printed error messages
- a non-functional -V unary operator for the test and [[ commands
Fix signal handling due to exit status > 256 This fixes two bugs: issuing the 'exit' command with a value > 256 would cause ksh 93u+ to kill itself with the corresponding signal (try 'exit 265' to SIGKILL your interactive shell), and, if the last command of a script exits due to a signal, the shell would repeat that signal to itself, causing any parent ksh to also be killed. Discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1469624 https://rainbow.chard.org/2017/03/21/ksh-deliberately-segfaults-if-the-last-command-in-a-script-crashes/ This commit is loosely based on a patch applied to the 93v- beta and the abandoned ksh2020, but that patch was incomplete & broken: $ ksh-2020.0.0 -c 'exit 265'; echo $? 137 Expected: 9. Since the exit was *not* due to a signal, the value should simply be cropped to the 8 bits supported by the OS. src/cmd/ksh93/bltins/cflow.c: b_exit(): - For the 'exit' builtin command, bitwise-AND the argument to 'exit' with SH_EXITMASK (8 bits, crop to 0-255) before passing it on to sh_exit(). This restores the behaviour of <=2011 ksh93 versions and is in line with all other POSIX shells. It also fixes this bogosity: $ (exit 265); echo $? # non-forked subshell 265 $ (ulimit -t unlimited; exit 265); echo $? # forked subshell 9 Forked or non-forked should make no difference at all (see commit message a0e0e29e for why). src/cmd/ksh93/sh/fault.c: sh_done(): - If the current exit status is equal to the status for the last signal that was received from a child process, remove the SH_EXITSIG (9th) bit, so that the shell doesn't kill itself. - If the shell's last child process exits due to a signal, exit with a portable 8-bit exit status (128 + signal number). This avoids the exit status being < 128 by being cropped to 8 bits. src/cmd/ksh93/tests/signal.sh: - Add regression test for exit with status > 256. - Add regression test verifying the shell no longer kills itself. (cherry picked from commit 98e0fc94393e175ce6adfee390327c320795bf12)
2020-06-08 10:23:37 +00:00
- If the last program run by a ksh script exits with a signal (e.g. crashed),
ksh itself now exits normally instead of repeating that same signal.
In addition, using 'exit x' for x > 256 no longer makes ksh issue a signal.
POSIX compliance fix: make 'times' a proper builtin As of this commit, the 'times' command is a POSIX-compliant special builtin command instead of an alias that doesn't produce the required output. It displays the accumulated user and system CPU times, one line with the times used by the shell and another with those used by all of the shell's child processes. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_27 This was originally written by Kurtis Rader and is now backported and tweaked from the abandoned ksh2020 branch. I chose an earlier and simpler version[*1] that uses times(3), with a precision of hundredths of seconds, so it outputs the same precision as mksh and zsh. Rader later wrote another version[*2] that uses getrusage(2), giving it the same millisecond precision as bash. But that required adding a feature test and a fallback to the old version, which is non-trivial in the old INIT/iffe system. This simpler version is enough to gain POSIX compliance and I think it will do very nicely in this stable bugfix branch. [*1] https://github.com/att/ast/pull/1332 [*2] https://github.com/att/ast/commit/038045f6 src/cmd/ksh93/bltins/misc.c - Add b_times() function for 'times' builtin. - Note we include <times.h>, not <sys/times.h>, so that we use the AST feature-tested version with fallback on systems that need it. src/cmd/ksh93/data/aliases.c: - Remove times='{ { time;} 2>&1;}' builtin alias. src/cmd/ksh93/data/builtins.c, src/cmd/ksh93/include/builtins.h: - Add entry for 'times' special builtin. - Add --help/--man info for same. src/cmd/ksh93/sh.1: - Update manual page. src/cmd/ksh93/tests/builtins.sh: - Add a couple of simple regression tests. (cherry picked from commit ebf71e619eb298ec1cf6b81d1828fa7cdf6e9203)
2020-06-06 19:25:59 +00:00
2020-06-06:
- The 'times' command is now a builtin command that conforms to POSIX
instead of an alias for the 'time' command. It displays the accumulated
user and system CPU times, one line with the times used by the shell and
another with those used by all of the shell's child processes.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_27
POSIX compliance: rm harmful default aliases 'command '/'nohup ' Continuing alias substitution after 'command' (due to the final space in the alias) is inherently broken and doing so by default is incompatible with the POSIX standard, as aliases may contain arbitrary shell grammar. For instance, until the previous commit, the POSIX standard 'times' command was an alias: times='{ { time;} 2>&1;}' -- and so, of course, 'command times' gave a syntax error, although this is a perfectly valid POSIX idiom that must be supported. 'command' is specified by POSIX as a regular builtin, not an alias. Therefore it should always bypass aliases just as it bypasses functions to expose standard builtin and external commands. I can only imagine that the reason for this command='command ' alias was that some standard commands themselves were implemented as aliases, and POSIX requires that standard commands are accessible with the 'command' prefix. But implementing standard commands as aliases is itself inherently broken. It never worked for 'command times', as shown; and in any case, removing all aliases with 'unalias -a' should not get rid of standard commands. Similarly, the default alias nohup='nohup ' is also harmful. Anyone who really wants to keep this behaviour can just define these aliases themselves in their script or ~/.kshrc file. src/cmd/ksh93/data/aliases.c: - Remove default alias command='command '. - Remove default alias nohup='nohup '. src/cmd/ksh93/sh.1 - Remove the above default aliases from the list. - Mention that the 'command' builtin does not search for aliases. (cherry picked from commit 5cfe7c4e2015b7445da24983af5008035c4b6e1e)
2020-06-07 00:36:54 +00:00
- The default aliases command='command ' and nohup='nohup ' have been
removed because they caused breakage in an attempt to circumvent other
breakage which is being fixed. In the unlikely even that anyone still
needs alias substitution to continue on the command argument following
'command' or 'nohup', it's easy to set these aliases yourself.
Fix unsetting special vars in subshells (re: efa31503, 8b7f8f9b) This fixes (or at least works around) a bug that caused special variables such as PATH, LANG, LC_ALL, LINENO, etc. to lose their effect after being unset in a subshell. For example: (unset PATH; PATH=/dev/null; ls); : wrongly ran 'ls' (unset LC_ALL; LC_ALL=badlocale); : failed to print a diagnostic This is yet another problem with non-forking/virtual subshells. If you forced the subshell to fork (one way of doing this is using the 'ulimit' builtin, e.g. ulimit -t unlimited) before unsetting the special variable, the problem vanished. I've tried to localise the problem. I suspect the sh_assignok() function, which is called from unall(), is to blame. This function is supposed to make a copy of a variable node in the virtual subshell's variable tree. Apparently, it fails to copy the associated permanent discipline function settings (stored in the np->nvfun->disc pointer) that gave these variables their special effect, and which survive unset. However, my attempts to fix that have been unsuccessful. If anyone can figure out a fix, please send a patch/pull request! Data point: This bug existed in 93u 2011-02-08, but did not yet exist in M-1993-12-28-s+. So it is a regression. Meanwhile, pending a proper fix, this commit adds a safe workaround: it forces a non-forked subshell to fork before unsetting such a special variable. src/cmd/ksh93/bltins/typeset.c: unall(): - If we're in a non-forked, non-${ ...; } subshell, then before unsetting any variable, check for variables with internal trap/discipline functions, and call sh_subfork() if any are found. To avoid crashing, this must be done before calling sh_pushcontext(), so we need to loop through the args separately. src/cmd/ksh93/tests/variables.sh: - Remove the 'ulimit' that forced the fork; we do this in C now. (cherry picked from commit 21b1a67156582e3cbd36936f4af908bb45211a4b)
2020-06-05 13:31:26 +00:00
2020-06-05:
- Fix a bug that caused special variables such as PATH, LANG, LC_ALL,
etc. to lose their effect after being unset in a subshell. For example:
(unset PATH; PATH=/dev/null; ls); : wrongly ran 'ls'
(unset LC_ALL; LC_ALL=badlocale); : failed to print a diagnostic
This also fixes BUG_KUNSETIFS: unsetting IFS in a subshell failed if IFS
was set to the empty value in the parent shell.
Fix unsetting special vars in subshells (re: efa31503, 8b7f8f9b) This fixes (or at least works around) a bug that caused special variables such as PATH, LANG, LC_ALL, LINENO, etc. to lose their effect after being unset in a subshell. For example: (unset PATH; PATH=/dev/null; ls); : wrongly ran 'ls' (unset LC_ALL; LC_ALL=badlocale); : failed to print a diagnostic This is yet another problem with non-forking/virtual subshells. If you forced the subshell to fork (one way of doing this is using the 'ulimit' builtin, e.g. ulimit -t unlimited) before unsetting the special variable, the problem vanished. I've tried to localise the problem. I suspect the sh_assignok() function, which is called from unall(), is to blame. This function is supposed to make a copy of a variable node in the virtual subshell's variable tree. Apparently, it fails to copy the associated permanent discipline function settings (stored in the np->nvfun->disc pointer) that gave these variables their special effect, and which survive unset. However, my attempts to fix that have been unsuccessful. If anyone can figure out a fix, please send a patch/pull request! Data point: This bug existed in 93u 2011-02-08, but did not yet exist in M-1993-12-28-s+. So it is a regression. Meanwhile, pending a proper fix, this commit adds a safe workaround: it forces a non-forked subshell to fork before unsetting such a special variable. src/cmd/ksh93/bltins/typeset.c: unall(): - If we're in a non-forked, non-${ ...; } subshell, then before unsetting any variable, check for variables with internal trap/discipline functions, and call sh_subfork() if any are found. To avoid crashing, this must be done before calling sh_pushcontext(), so we need to loop through the args separately. src/cmd/ksh93/tests/variables.sh: - Remove the 'ulimit' that forced the fork; we do this in C now. (cherry picked from commit 21b1a67156582e3cbd36936f4af908bb45211a4b)
2020-06-05 13:31:26 +00:00
- Fix crashes on some systems, including at least a crash in 'print -v' on
macOS, by eliminating an invalid/undefined use of memccpy() on overlapping
buffers in the commonly used sfputr() function.
Fix ${.sh.subshell} counter to actually count level of subshells This counter is documented as follows: "The current depth for subshells and command substitution." But before this commit, the actual behaviour was that the counter was reset to zero whenever a subshell forked for any reason: a pipe, background job, running 'ulimit', redirecting stdout in a command substitution, and more. This behaviour was: 1. Not consistent with the documentation. Non-forked (a.k.a. virtual) subshells are an internal implementation detail which scripts should not have to be concerned with. The manual page doesn't mention them at all. 2. Inherently broken. Since a subshell may fork for any number of reasons, even mid-run, and those reasons may change with bugfixes and further development, scripts have never actually been able to rely on the value of ${.sh.subshell}. So, this commit fixes the counter to count the levels of all subshells, both virtual and forked. src/cmd/ksh93/sh/xec.c: _sh_fork(): - Increase ${.sh.subshell} whenever we fork. src/cmd/ksh93/sh/subshell.c: - sh_subfork(): * Fix comment to properly explain what it does. It doesn't "create" a subshell, it forks off an existing virtual subshell. * Don't zero ${.sh.subshell}. Instead, since sh_fork() increases it but we're forking an existing subshell, undo the increase. - sh_subshell(): * Remove 'int16_t subshell' variable. It was unnecessary and mostly unused. It was also the wrong type: it was assigned the value from shp->subshell which is of type short. * Increase and decrease the level of virtual subshells and ${.sh.subshell} independently. src/cmd/ksh93/tests/variables.sh: - Add regression tests for ${.sh.subshell} in virtual and forked subshells of several kinds: comsub, parentheses, pipe, bg job. - Undo wrong error test count fix from 04b4aef0. (cherry picked from commit a0e0e29e7e0dbf21e4b3958ae02bde6665fb2696)
2020-06-05 19:39:47 +00:00
- Fix the ${.sh.subshell} level counter; it is no longer reset to zero when a
non-forked subshell happens to fork into a separate process for some reason
(an internal implementation detail that should be unnoticeable to scripts).
Fix BUG_KBGPID: $! was not updated under certain conditions The $! special parameter was not set if a background job (somecommand &) or co-process (somecommand |&) was launched as the only command within a braces block with an attached redirection, for example: { somecommand & } >&2 With the bug, $! was unchanged; now it contains the PID of somecommand. Ref.: https://github.com/att/ast/issues/1357 src/cmd/ksh93/sh/parse.c: item(): - When processing redirections following a compound command, always create a parent node with the TSETIO (I/O redirection) token. Before this commit, if the last command was of type TFORK (and the last command only tested as TFORK if the bg job or coprocess was the only command in a braces block, because the ksh parser optimises away the braces in that case), then the parent node was created with the TFORK token instead. I have no idea what David Korn's intention was with that, but this is clearly very wrong. Creating another TFORK node when parsing the redirection caused sh_exec() in sh/xec.c to execute the redirection in an extra forked, non-background subshell. Since redirections are executed before anything else, this subshell is what then launched the background job between the braces, so $! (a.k.a. shp->bckpid) was updated in that subshell only, and never in the main shell. The extra subshell also prevented the background job from being noticed by job control on interactive shells. So, the fix is simply to remove the broken test for TFORK. src/cmd/ksh93/tests/variables.sh: - Add regression tests for a bg job and a co-process as the only command within a braces block with attached redirection. (cherry picked from commit ffe5df30e69f7b596941a98498014d8e838861f2)
2020-06-04 03:19:59 +00:00
2020-06-04:
- Fix BUG_KBGPID: the $! special parameter was not set if a background job
(somecommand &) or co-process (somecommand |&) was launched as the only
command within a braces block with an attached redirection, for example:
{
somecommand &
} >&2
With the bug, $! was unchanged; now it contains the PID of somecommand.
2020-05-31:
- Fix a bug in autoloading functions. Directories in the path search list
which should be skipped (e.g. because they don't exist) did not interact
correctly with autoloaded functions, so that a function to autoload was
not always found correctly.
Details: https://github.com/att/ast/issues/1454
Fix 'test'/'[' exit status >1 on error in arithmetic expression Fix BUG_TESTERR1A: POSIX non-compliance of 'test'/'[' exit status on error. The command now returns status 2 instead of 1 when given an invalid number or arithmetic expression, e.g.: [ 123 -eq 123x ] The problem was that the test builtin (b_test()) calls the generic arithmetic evaluation subsystem (sh/arith.c, sh/streval.c) which has no awareness of the test builtin. A simple solution would be to always make the arithmetic subsystem use an exit status > 1 for arithmetic errors, but globally changing this may cause backwards compatibility issues. So it's best to change the behaviour of the 'test' builtin only. This requires the arithmetic subsystem to be aware of whether it was called from the 'test' builtin or not. To that end, this commit adds a global flag and overrides the ERROR_exit macro where needed. src/cmd/ksh93/include/defs.h, src/cmd/ksh93/sh/defs.c: - Declare and initialise a global sh_in_test_builtin flag. - Declare internal function for ERROR_exit override in test.c. src/cmd/ksh93/bltins/test.c: - Add override for ERROR_exit macro using a function that checks if the exit status is at least 2 if the error occurred while running the test builtin. - b_test(): Set sh_in_test_builtin flag while running test builtin. src/cmd/ksh93/sh/arith.c, src/cmd/ksh93/sh/streval.c: - Override ERROR_exit macro using function from test.c. src/cmd/ksh93/tests/bracket.sh: - Add regression test verifying status > 1 on arith error in test. (cherry picked from commit 5eeae5eb9fd5ed961a5096764ad11ab870a223a9)
2020-05-30 14:21:30 +00:00
2020-05-30:
- Fix POSIX compliance of 'test'/'[' exit status on error. The command now
returns status 2 instead of 1 when given an invalid number or arithmetic
expression, e.g.:
[ 123 -eq 123x ]; echo $?
now outputs 2 instead of 1.
Fix redefining & unsetting functions in subshells (BUG_FNSUBSH) Functions can now be correctly redefined and unset in subshell environments (such as ( ... ), $(command substitutions), etc). Before this fix, attempts to do this were silently ignored (!!!), causing the wrong code (i.e.: the function by the same name from the parent shell environment) to be executed. Redefining and unsetting functions within "shared" command substitutions of the form '${ ...; }' is also fixed. Prior discussion: https://github.com/att/ast/issues/73 src/cmd/ksh93/sh/parse.c: - A fix from George Koelher (URL above). He writes: | The parser can set t->comnamp to the wrong function. | Suppose that the shell has executed | foo() { echo WRONG; } | and is now parsing | (foo() { echo ok; } && foo) | The parser was setting t->comnamp to the wrong foo. [This | fix] doesn't set t->comnamp unless it was a builtin. Now the | subshell can't call t->comnamp, so it looks for foo and finds | the ok foo in the subshell's function tree. src/cmd/ksh93/bltins/typeset.c: - Unsetting functions in a virtual/non-forked subshell still doesn't work: nv_open() fails to find the function. To work around this problem, make 'unset -f' fork the subshell into its own process with sh_subfork(). - The workaround exposed another bug: if we unset a function in a subshell tree that overrode a function by the same name in the main shell, then nv_delete() exposes the function from the main shell scope. Since 'unset -f' now always forks a subshell, the fix is to simply walk though troot's parent views and delete any such zombie functions as well. (Without this, the 4 'more fun' tests in tests/subshell.sh fail.) src/cmd/ksh93/sh/subshell.c: sh_subfuntree(): - Fix function (re)definitions and unsetting in "shared" command substitutions of the form '${ commandlist; }' (i.e.: if sp->shp->subshare is true). Though internally this is a weird form of virtual subshell, the manual page says it does not execute in a subshell (meaning, all changes must survive it), so a subshell function tree must not be created for these. src/cmd/ksh93/tests/subshell.sh: - Add regression tests related to these bugfixes. Test unsetting and redefining a function in all three forms of virtual subshell. (cherry picked from commit dde387825ab1bbd9f2eafc5dc38d5fd0bf9c3652)
2020-05-29 07:27:20 +00:00
2020-05-29:
- Fix BUG_FNSUBSH: functions can now be correctly redefined and unset in
subshell environments (such as ( ... ), $(command substitutions), etc).
Before this fix, this was silently ignored, causing the function by the
same name from the parent shell environment to be executed instead.
fn() { echo mainsh; }
(fn() { echo subsh; }; fn); fn
This now correctly outputs "subsh mainsh" instead of "mainsh mainsh".
ls() { echo "ls executed"; }
(unset -f ls; ls); ls
This now correctly lists your directory and then prints "ls executed",
instead of printing "ls executed" twice.
2020-05-29 07:27:53 +00:00
- Fix a similar bug with aliases. These can now be correctly unset
in subshell environments.
2020-05-21:
- Fix truncating of files with the combined redirections '<>;file' and
'<#pattern'. The bug was caused by out-of-sync streams.
Details and discussion: https://github.com/att/ast/issues/61
- Patched code injection vulnerability CVE-2019-14868. As a result, you can
no longer use expressions in imported numeric environment variables; only
integer literals are allowed.
Fix bugs in testing if a parameter is set This fixes three related bugs: 1. Expansions like ${var+set} remained static when used within a 'for', 'while' or 'until' loop; the expansions din't change along with the state of the variable, so they could not be used to check whether a variable is set within a loop if the state of that variable changed in the course of the loop. (BUG_ISSETLOOP) 2. ${IFS+s} always yielded 's', and [[ -v IFS ]] always yielded true, even if IFS is unset. (BUG_IFSISSET) 3. IFS was incorrectly exempt from '-u' ('-o nounset') checks. src/cmd/ksh93/sh/macro.c: varsub(): - When getting a node pointer (np) to the parameter to test, special-case IFS by checking if it has a value and not setting the pointer if not. The node to IFS always exists, even after 'unset -v IFS', so before this fix it always followed the code path for a parameter that is set. This fixes BUG_IFSISSET for ${IFS+s} and also fixes set -u (-o nounset) with IFS. - Before using the 'nv_isnull' macro to check if a regular variable is set, call nv_optimize() if needed. This fixes BUG_ISSETLOOP. Idea from Kurtis Rader: https://github.com/att/ast/issues/1090 Of course this only works if SHOPT_OPTIMIZE==1 (the default), but if not, then this bug is not triggered in the first place. - Add some comments for future reference. src/cmd/ksh93/bltins/test.c: test_unop(): - Fix BUG_IFSISSET for [[ -v IFS ]]. The nv_optimize() method doesn't seem to have any effect here, so the only way that I can figure out is to special-case IFS, nv_getval()'ing it to check if IFS has a value in the current scope. src/cmd/ksh93/tests/variables.sh: - Add regression tests for checking if a varariable is set within a loop, within and outside a function with that variable made local (to check if the scope is honoured). Repeat these tests for a regular variable and for IFS, for ${foo+set} and [[ -v foo ]]. (cherry picked from commit a2cf79cb98fa3e47eca85d9049d1d831636c9b16)
2020-05-20 14:50:43 +00:00
2020-05-20:
- Fix BUG_ISSETLOOP. Expansions like ${var+set} remained static when used
within a 'for', 'while' or 'until' loop; the expansions din't change along
with the state of the variable, so they could not be used to check whether a
variable is set within a loop if the state of that variable changed in the
course of the loop.
- Fix BUG_IFSISSET. ${IFS+s} always yielded 's', and [[ -v IFS ]] always
yielded true, even if IFS is unset. This applied to IFS only.
2020-05-19:
- Fix 'command -p'. The -p option causes the operating system's standard
utilities path (as output by 'getconf PATH') to be searched instead of $PATH.
Before this fix, this was broken on non-interactive shells as the internal
variable holding the default PATH value was not correctly initialised.
Fix 'test -t 1' in $(command substitutions) Standard output (FD 1) tested as being on a terminal within a command substitution, which makes no sense as the command substitution is supposed to be catching standard output. ksh -c 'v=$(echo begincomsub [ -t 1 ] && echo oops echo endcomsub) echo "$v"' This should not output "oops". This is one of the many bugs with ksh93 virtual (non-forked) subshells. On the abandoned Vashist/Rader ksh2020 branch, this bug was fixed by changing quite a lot of code, which introduced and/or exposed another bug: https://github.com/att/ast/issues/1079 https://github.com/att/ast/commit/8e1e405e https://github.com/att/ast/issues/1088 That issue was unresolved when the ksh2020 branch was abandoned. The safer and more conservative fix is simply forcing the subshell to fork if we're in a non-forked command substitution and testing '-t 1'. It is hard to imagine a situation where this would cause a noticable performance hit. Note that this fix does not affect ksh93-specific "shared" non-subshell ${ command substitutions; } which are executed in the main shell environment, so that variables survive, etcetera. 'test -t 1' continues to wrongly return true there, but command substitutions of that form cannot be forked because that would defeat their purpose. src/cmd/ksh93/bltins/test.c: - Fix 'test -t 1', '[ -t 1 ]' and '[[ -t 1 ]]' by forking the current subshell if it is a virtual/non-forked subshell (shp->subshell), and a command substitution (shp->comsub), but NOT a "shared" ${ command substitution; } (!shp->subshare). src/cmd/ksh93/tests/bracket.sh: - Add two regression tests for this issue, which were adapted from the Vashist/Rader ksh2020 branch. NEWS, src/cmd/ksh93/include/version.h: - Update. (cherry picked from commit b8ef05e457ead65b83417699b8dd8632f855e2fa)
2020-05-16 19:06:49 +00:00
2020-05-16:
- Fix 'test -t 1', '[ -t 1 ]', '[[ -t 1 ]]' in command substitutions.
Standard output (file descriptor 1) tested as being on a terminal within a
command substitution, which makes no sense as the command substitution is
supposed to be catching standard output.
v=$(echo begincomsub
[ -t 1 ] && echo oops
echo endcomsub)
echo "$v"
This now does not output "oops".
2020-05-14:
- Fix syncing history when print -s -f is used. For example, the
following now correctly adds a 'cd' command to the history:
print -s -f 'cd -- %q\n' "$PWD"
Ref.: https://github.com/att/ast/issues/425
https://github.com/att/ast/pull/442
- Fix BUG_PUTIOERR: Output builtins now correctly detect
input/output errors. This allows scripts to check for a nonzero exit
status on the 'print', 'printf' and 'echo' builtins and prevent possible
infinite loops if SIGPIPE is ignored.
- Add a convenient bin/run_ksh_tests script to the source tree that
sets up the necessary environment and runs the ksh regression tests.
Fix BUG_CASELIT: pattern matching as literal string in 'case' This fixes an undocumented 'case' pattern matching misbehaviour (labelled BUG_CASELIT in modernish) that goes back to the original Bourne shell, but wasn't discovered until 2018. If a pattern doesn't match as a pattern, it's tried again as a literal string. This breaks common validation use cases, such as: n='[0-9]' case $n in ( [0-9] ) echo "$n is a number" ;; esac would output "[0-9] is a number" as the literal string fallback matches the pattern. As this misbehaviour was never documented anywhere (not for Bourne, ksh88, or ksh93), and it was never replicated in other shells (not even in ksh88 clones pdksh and mksh), it is unlikely any scripts rely on it. Of course, a literal string fallback, should it be needed, is trivial to implement correctly without this breakage: case $n in ( [0-9] | "[0-9]") echo "$n is a number or the number pattern" ;; esac src/cmd/ksh93/sh/xec.c: - Remove trim_eq() function responsible for implementing the misbehaviour described above. NEWS: - Added. Document this bugfix. Ref.: - The problem: thread starting at https://www.mail-archive.com/austin-group-l@opengroup.org/msg02127.html - The solution, thanks to George Koehler: comments/commits in https://github.com/att/ast/issues/476 - Modernish BUG_CASELIT bug test & documentation: https://github.com/modernish/modernish/commit/b2024ae3 (cherry picked from commit 8d6c8ce69884767a160c1e20049e77bdd849c248 with some extra edits to NEWS to upate the info for this reboot)
2020-06-11 15:14:31 +00:00
2020-05-13:
- Fix BUG_CASELIT: an undocumented 'case' pattern matching misbehaviour that
goes back to the original Bourne shell, but wasn't discovered until 2018.
If a pattern doesn't match as a pattern, it was tried again as a literal
string. This broke common validation use cases, e.g.:
n='[0-9]'
case $n in
( [0-9] ) echo "$n is a number" ;;
esac
would output "[0-9] is a number" as the literal string fallback matches the
pattern. As this misbehaviour was never documented anywhere (not for Bourne,
ksh88, or ksh93), and it was never replicated in other shells (not even in
ksh88 clones pdksh and mksh), it is unlikely any scripts rely on it.
Of course, a literal string fallback, should it be needed, is trivial to
implement correctly without this breakage:
case $n in
( [0-9] | "[0-9]") echo "$n is a number or the number pattern" ;;
esac
Ref.: https://github.com/att/ast/issues/476
- Fix BUG_REDIRIO: ksh used to redirect standard output by default when no
file descriptor was specified with the rarely used '<>' reading/writing
redirection operator. It now redirects standard input by default, as POSIX
specifies and as all other POSIX shells do. To redirect standard output
for reading and writing, you now need '1<>'.
Ref.: https://github.com/att/ast/issues/75
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_07