-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ksh93: assignments preceding "command (special builtin)" persist [BUG_CMDSPASGN] #72
Comments
command special_builtin
persist
Already fixed in the beta. Sorry for the noise. |
JohnoKing
added a commit
to JohnoKing/ksh
that referenced
this issue
Jun 16, 2020
Ksh was not checking for `command` when running a special builtin, which caused preceding invocation-local variable assignments to become global. This is the reproducer from the att#72: $ foo=BUG command eval ':' $ echo "$foo" This no longer prints 'BUG', as ksh now makes sure the command builtin is not running a special builtin before making invocation-local variable assignments global. src/cmd/ksh93/sh/xec.c: - Backport the bugfix for BUG_CMDSPASGN from ksh93v- 2013-10-10-alpha. src/cmd/ksh93/tests/builtins.sh: - Add a regression test based on the reproducer in att#72.
McDutchie
pushed a commit
to ksh93/ksh
that referenced
this issue
Jun 16, 2020
Ksh was not checking for `command` when running a special builtin, which caused preceding invocation-local variable assignments to become global. This is the reproducer from the att#72: $ foo=BUG command eval ':' $ echo "$foo" This no longer prints 'BUG', as ksh now makes sure the command builtin is not running a special builtin before making invocation-local variable assignments global. src/cmd/ksh93/sh/xec.c: - Backport the bugfix for BUG_CMDSPASGN from ksh93v- 2013-10-10-alpha. src/cmd/ksh93/tests/builtins.sh: - Add a regression test based on the reproducer in att#72.
citrus-it
pushed a commit
to citrus-it/ast
that referenced
this issue
Apr 15, 2021
This commit backports the required fixes from ksh2020 for using millisecond precision with the 'time' keyword. The bugfix refactors a decent amount of code to rely on the BSD 'timeradd' and 'timersub' macros for calculating the total amount of time elapsed (as these aren't standard, they are selectively implemented in an iffe feature test for platforms without them). getrusage(3) is now preferred since it usually has higher precision than times(3) (the latter is used as a fallback). There are three other fixes as well: src/lib/libast/features/time: - Test for getrusage with an iffe feature test rather than assume _sys_times == _lib_getrusage. src/cmd/ksh93/sh/xec.c: - A single percent at the end of a format specifier is now treated as a literal '%' (like in Bash). - Zero-pad seconds if seconds < 10. This was already done for the times builtin in commit 5c677a4, although it wasn't applied to the time keyword. - Backport the ksh2020 bugfix for the time keyword by using timeradd and timersub with gettimeofday (which is used with a timeofday macro). Prefer getrusage when it is available. - Allow compiling without the 'timeofday' ifdef for better portability. This is the order of priority for getting the elapsed time: 1) getrusage (most precise) 2) times + gettimeofday (best fallback) 3) only times (doesn't support millisecond precision) This was tested by using debug '#undef' statements in xec.c. src/cmd/ksh93/features/time: - Implement feature tests for the 'timeradd' and 'timersub' macros. - Do a feature test for getrusage like in the libast time test. src/cmd/ksh93/tests/basic.sh: - Add test for millisecond precision. - Add test for handling of '%' at the end of a format specifier. - Add test for locale-specific radix point.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Preceding a special builtin by
command
does not stop preceding invocation-local variable assignments from becoming global.For instance:
Output:
BUG
eval
is a special builtin, andcommand
apparently fails to disable its 'special' properties, so thefoo
assignment wrongly persists beyond the command.The text was updated successfully, but these errors were encountered: