1
0
Fork 0
mirror of git://git.code.sf.net/p/zsh/code synced 2024-05-16 21:16:05 +02:00
zsh/Test/B11kill.ztst

87 lines
2.0 KiB
Plaintext
Raw Normal View History

# Tests for the kill builtin.
#
# The exit codes 11 and 19 in this file don't mean anything special; they're
# just exit codes which are specific enough that the failure of `kill` itself
# can be differentiated from exiting due to executing a trap.
%test
# Correct invocation
if zmodload zsh/system &>/dev/null; then
(
trap 'exit 19' TERM
kill $sysparams[pid]
)
else
ZTST_skip='Cannot zmodload zsh/system, skipping kill with no sigspec'
fi
19:kill with no sigspec
if zmodload zsh/system &>/dev/null; then
(
trap 'exit 11' USR1
kill -USR1 $sysparams[pid]
)
else
ZTST_skip='Cannot zmodload zsh/system, skipping kill with sigspec'
fi
11:kill with sigspec
# Incorrect invocation
(
kill a b c
)
3:kill with multiple wrong inputs should increment status
?(eval):kill:2: illegal pid: a
?(eval):kill:2: illegal pid: b
?(eval):kill:2: illegal pid: c
(
kill -INT a b c
)
3:kill with sigspec and wrong inputs should increment status
?(eval):kill:2: illegal pid: a
?(eval):kill:2: illegal pid: b
?(eval):kill:2: illegal pid: c
(
kill
)
1:kill with no arguments
?(eval):kill:2: not enough arguments
(
kill -INT
)
1:kill with sigspec only
?(eval):kill:2: not enough arguments
# Regression tests: `kill ''` should not result in `kill 0`.
#
# We use SIGURG where an explicit sigspec can be provided as:
#
# 1. By default it's non-terminal, so even if we regress, we won't kill the
# test runner and other processes in the process group since we'll stop
# running this test before we get to the plain kill (and thus SIGTERM)
# cases;
# 2. It's also unlikely to be sent for any other reason during the process
# lifetime, so the test shouldn't be flaky.
(
trap 'exit 11' URG
kill -URG ''
)
45453: builtins: kill: Do not signal current process group when pid is empty The following case was encountered in the wild: % zsh; echo "$?" % trap 'exit 5' TERM % kill '' 5 This behaviour seems more likely to be the result of bugs in programs (e.g. `kill -9 "$unsetvar") rather than being desirable behaviour to me. It also seems unintentional judging by the code and documentation, since it comes about as a result of the fact that: - `isanum` returns true for empty strings (since an empty string technically only consists of digits and minuses...); - `atoi`, when passed a pointer to an invalid number, returns 0; - `kill(0, signal)` sends the signal in question to all processes in the current process group. There are (at least) two ways to solve this issue: 1. Add special handling to `kill` to avoid this case. See this patch[0] for a version that does that. 2. Change how isanum behaves. Since the only two call sites that use it both seem like they should handle the case where the input char array is empty, that seems like a reasonable overall change to me.[1] After this patch: % trap 'exit 5' TERM % kill '' kill: illegal pid: The regression test for `kill` without a sigspec is also included in this commit, as previously it's not possible to test it trivially as it would still kill the test runner in expected-to-fail mode; see discussion in workers/45449. 0: workers/45426: https://www.zsh.org/mla/workers/2020/msg00251.html 1: The other call site using isanum() is the fg builtin, but in that case we just fail later since we can't find any job named '', so no big deal either way. It's the kill case which is more concerning.
2020-02-17 16:12:11 +01:00
1:kill with empty pid and sigspec should not send signal to current process group
?(eval):kill:3: illegal pid:
45453: builtins: kill: Do not signal current process group when pid is empty The following case was encountered in the wild: % zsh; echo "$?" % trap 'exit 5' TERM % kill '' 5 This behaviour seems more likely to be the result of bugs in programs (e.g. `kill -9 "$unsetvar") rather than being desirable behaviour to me. It also seems unintentional judging by the code and documentation, since it comes about as a result of the fact that: - `isanum` returns true for empty strings (since an empty string technically only consists of digits and minuses...); - `atoi`, when passed a pointer to an invalid number, returns 0; - `kill(0, signal)` sends the signal in question to all processes in the current process group. There are (at least) two ways to solve this issue: 1. Add special handling to `kill` to avoid this case. See this patch[0] for a version that does that. 2. Change how isanum behaves. Since the only two call sites that use it both seem like they should handle the case where the input char array is empty, that seems like a reasonable overall change to me.[1] After this patch: % trap 'exit 5' TERM % kill '' kill: illegal pid: The regression test for `kill` without a sigspec is also included in this commit, as previously it's not possible to test it trivially as it would still kill the test runner in expected-to-fail mode; see discussion in workers/45449. 0: workers/45426: https://www.zsh.org/mla/workers/2020/msg00251.html 1: The other call site using isanum() is the fg builtin, but in that case we just fail later since we can't find any job named '', so no big deal either way. It's the kill case which is more concerning.
2020-02-17 16:12:11 +01:00
(
trap 'exit 19' TERM
kill ''
)
1:Plain kill with empty pid should not send signal to current process group
?(eval):kill:3: illegal pid: