mirror of
git://git.code.sf.net/p/cdesktopenv/code
synced 2025-02-13 11:42:21 +00:00
6a4972069f
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)
25 lines
1.1 KiB
Text
25 lines
1.1 KiB
Text
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
|