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.
|
|
|
|
|
For full details, see the git log at:
|
|
|
|
|
https://github.com/modernish/ksh
|
|
|
|
|
|
|
|
|
|
Any uppercase BUG_* names are modernish shell bug IDs.
|
|
|
|
|
|
|
|
|
|
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
|
2020-05-13 14:00:33 +00:00
|
|
|
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
|