kill: fix the fail to use only least significant bits to identify signal with -l

[Felle33]

This pull request solves the issue number #7218.
Fixes #7218

[Felle33]

With this pull request the tests/misc/kill.sh passes. Should I modify some file or is it just fine as it is?

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/misc/kill is no longer failing!

[sylvestre]

Please document this magic number :)

[cakebaker]

I think it is not entirely correct, because it recognizes, for example, 111 (= b1101111) as a TERM signal whereas GNU kill doesn't recognize it.

[Felle33]

Yes you are right. I have done some tests and the range of number accepted goes from 0 to 64 and from 128 to 192 (both endings included). It is like they are managing the same signals but mapped 2 times.
I noticed also that we don't manage the name of the signals from 32 to 64 (and therefore also from 160 to 192).

[Felle33]

I could add this feature in this pull request or should I open a new one?

[cakebaker]

I would create a new PR. There is also a ticket for it: #6218

[sylvestre]

With this pull request the tests/misc/kill.sh passes. Should I modify some file or is it just fine as it is?

You can update utils/why-error.md but no worries if you don't

[cakebaker]

While this works, I think using a regex is a bit overkill and you can simplify it by using either stdout_is or stdout_contains.

[Felle33]

Thank you, I have just seen the function stdout_only, what do you think?

[cakebaker]

Yes, that's also fine.

[Felle33]

I tried to come up with a solution, take for example the signal EXIT (0):
with some tests, I noticed that it appears when the argument is 0 128 256 512 768 1024 and so on; it is repeated with a mod 128.
For this reason, we should only check only the low 7 bits

[cakebaker]

I think you are close :) It looks like it's mod 256 for numbers >= 256 and not mod 128:

$ ../gnu/src/kill -l $(seq 0 128 2560)
EXIT
EXIT
EXIT
kill: ‘384’: invalid signal
EXIT
kill: ‘640’: invalid signal
EXIT
kill: ‘896’: invalid signal
EXIT
kill: ‘1152’: invalid signal
EXIT
kill: ‘1408’: invalid signal
EXIT
kill: ‘1664’: invalid signal
EXIT
kill: ‘1920’: invalid signal
EXIT
kill: ‘2176’: invalid signal
EXIT
kill: ‘2432’: invalid signal
EXIT

[sylvestre]

is it a bug or a feature ?

[cakebaker]

@sylvestre I think it's a feature. This is the relevant part of the corresponding GNU kill test:

# Verify we only consider the lower "signal" bits,
# to support ksh which just adds 256 to the signal value
STD_TERM_STATUS=$(expr "$SIGTERM" + 128)
KSH_TERM_STATUS=$(expr "$SIGTERM" + 256)
test $(env kill -l $STD_TERM_STATUS $KSH_TERM_STATUS | uniq) = TERM || fail=1

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/misc/kill is no longer failing!

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/misc/stdbuf (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/misc/usage_vs_getopt (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/misc/kill is no longer failing!
Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)

[cakebaker]

Congrats! The gnu test tests/misc/kill is no longer failing!

Well done and thanks :)

[Felle33]

Thanks for your patience...it was a journey :)

[sylvestre]

only two days, kudos :)