[SC2120] False positive when a function is called by trap with arguments

[Frederick888]

For bugs

• Rule Id (if any, e.g. SC1000): SC2120
• My shellcheck version (shellcheck --version or "online"): online
• The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

For new checks and feature suggestions

• https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
• I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

#!/usr/bin/env bash

clean_up() {
        local code=$?
        printf 'Cleaning up!\n'
        if [[ -n "$1" ]]; then
                printf 'Invoked due to error %d on line %d\n' "$code" "$1"
                exit "$code"
        fi
        exit 0
}

trap 'clean_up $LINENO' ERR SIGINT SIGTERM SIGQUIT

if [[ -z "$INPUT" ]]; then
        printf 'Missing input!\n'
        clean_up
fi

# do something

Here's what shellcheck currently says:

Line 3:
clean_up() {
^-- SC2120 (warning): clean_up references arguments, but none are ever passed.
 
Line 17:
        clean_up
        ^-- SC2119 (info): Use clean_up "$@" if function's $1 should mean script's $1.

Here's what I wanted or expected to see:

No SC2120 error as trap 'clean_up $LINENO' ERR SIGINT SIGTERM SIGQUIT can call clean_up with an argument.

[wileyhy]

What you seem to be trying to do is trigger the trap from within the if-fi structure if the length of INPUT is zero (which could include a nul character). To do so, you'd have to put a command there, rather than `clean_up` after `printf`, which can send the script process a signal which you've already defined as caught using the `trap` builtin. For instance, `kill -s INT` would trigger the trap, or a similar command using `/bin/kill`. As an aside, both the `exit` builtin and (assuming "Halt" is undefined) `echo ${Halt:?}` will send SIGEXIT to the script's process. greycat's page on traps can be helpful. https://mywiki.wooledge.org/SignalTrap Wiley

…

On Tue, Sep 3, 2024, 3:30 AM Frederick Zhang ***@***.***> wrote: For bugs - Rule Id (if any, e.g. SC1000): SC2119, SC2120 - My shellcheck version (shellcheck --version or "online"): online - The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086) - I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit For new checks and feature suggestions - https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this - I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related Here's a snippet or screenshot that shows the problem: #!/usr/bin/env bash clean_up() { local code=$? printf 'Cleaning up!\n' if [[ -n "$1" ]]; then printf 'Invoked due to error %d on line %d\n' "$code" "$1" exit "$code" fi exit 0 } trap 'clean_up $LINENO' ERR SIGINT SIGTERM SIGQUIT if [[ -z "$INPUT" ]]; then printf 'Missing input!\n' clean_upfi # do something Here's what shellcheck currently says: Line 3: clean_up() { ^-- SC2120 (warning): clean_up references arguments, but none are ever passed. Line 17: clean_up ^-- SC2119 (info): Use clean_up "$@" if function's $1 should mean script's $1. Here's what I wanted or expected to see: No errors as trap 'clean_up $LINENO' ERR SIGINT SIGTERM SIGQUIT can call clean_up with an argument. — Reply to this email directly, view it on GitHub <#3052>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUF2F22HZ44FSVDZOAYDPBTZUWFUJAVCNFSM6AAAAABNR2J73GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYDENJQHAYDOMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Frederick888]

@wileyhy No, in my example clean_up is something that can be called directly when an expected/handled issue arises to clean up and exit, or called when an unexpected error / interruption happens (during # do something). I did not want to trigger the trap from within if-fi.

Anyway, I fail to see how that's related to this issue report. clean_up can be called with an argument nevertheless.