You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a DEBUG trap is registered in a parent shell and then a child shell is invoked to run a script without a shebang, the DEBUG trap is not reset in the forked shell.
My understanding is that when a subshell is entered, traps should be set to the default actions (POSIX 2004 reference).
My understanding is that the following happens when running the above mentioned example test.sh:
Function path_spawn() (src/cmd/ksh93/sh/path.c) is executed to spawn ./test.sh.
It ends up running the execve("./test.sh", ...) syscall which returns ENOEXEC because of the missing shebang.
Function path_spawn() recognizes this failure and instead forks the running ksh process to execute the script: path_spawn() -> exscript().
Function exscript() ends up passing control via a series of long jumps to sh_main() (src/cmd/ksh93/sh/main.c) which calls sh_reinit() (src/cmd/ksh93/sh/init.c).
Function sh_reinit() re-initializes the shell to a clean state. It removes the user-defined function log_debug() and clears also some knowledge of trap handlers, in particular it calls sh_sigreset().
Function sh_sigreset() contains the following code:
The loop starts from SH_DEBUGTRAP-1 and so the DEBUG trap is not reset.
The script invokes command echo test which triggers the debug handler and ksh reports that log_debug() is not available.
Naively, my initial impression was that the above loop should start from SH_DEBUGTRAP and not SH_DEBUGTRAP-1 because the trap array is declared in src/cmd/ksh93/include/defs.h as char *trap[SH_DEBUGTRAP+1]. However, a colleague pointed out to me that this might not be a simple off-by-one error because the code was consciously changed from SH_DEBUGTRAP to SH_DEBUGTRAP-1 in ksh93t. Unfortunately, it is not clear to me from its changelog why this was done.
The text was updated successfully, but these errors were encountered:
Description of problem:
When a DEBUG trap is registered in a parent shell and then a child shell is invoked to run a script without a shebang, the DEBUG trap is not reset in the forked shell.
My understanding is that when a subshell is entered, traps should be set to the default actions (POSIX 2004 reference).
Ksh version:
How reproducible:
Always.
Steps to reproduce:
Note: When invoking a script with a proper shebang, the DEBUG trap is reset:
Actual results:
DEBUG trap remains set in a child shell.
Expected results:
DEBUG trap is not set in a child shell.
Additional info:
My understanding is that the following happens when running the above mentioned example
test.sh
:Function
path_spawn()
(src/cmd/ksh93/sh/path.c
) is executed to spawn./test.sh
.It ends up running the
execve("./test.sh", ...)
syscall which returnsENOEXEC
because of the missing shebang.Function
path_spawn()
recognizes this failure and instead forks the running ksh process to execute the script:path_spawn()
->exscript()
.Function
exscript()
ends up passing control via a series of long jumps tosh_main()
(src/cmd/ksh93/sh/main.c
) which callssh_reinit()
(src/cmd/ksh93/sh/init.c
).Function
sh_reinit()
re-initializes the shell to a clean state. It removes the user-defined functionlog_debug()
and clears also some knowledge of trap handlers, in particular it callssh_sigreset()
.Function
sh_sigreset()
contains the following code:The loop starts from
SH_DEBUGTRAP-1
and so the DEBUG trap is not reset.The script invokes command
echo test
which triggers the debug handler and ksh reports thatlog_debug()
is not available.Naively, my initial impression was that the above loop should start from
SH_DEBUGTRAP
and notSH_DEBUGTRAP-1
because the trap array is declared insrc/cmd/ksh93/include/defs.h
aschar *trap[SH_DEBUGTRAP+1]
. However, a colleague pointed out to me that this might not be a simple off-by-one error because the code was consciously changed fromSH_DEBUGTRAP
toSH_DEBUGTRAP-1
in ksh93t. Unfortunately, it is not clear to me from its changelog why this was done.The text was updated successfully, but these errors were encountered: