[pSub]

SC2117 used the argument count to decide whether su runs a command. That allowed 'su -c foo' but flagged the equivalent long form 'su --command=foo'. Instead, look for the command option itself: -c, -cfoo, short option clusters like -lc, --command or --command=foo.

[e-kwsm]

In BSD implementation -c can be class:

-c class
Use the settings of the specified login class. The login class must be defined in login.conf(5). Only allowed for the super-user.

su -m -c staff operator -c 'shutdown -p now'
Same as above, but the target command is run with the resource limits of the login class "staff". Note: in this example, the first -c option applies to su while the second is an argument to the shell being invoked.

https://man.freebsd.org/cgi/man.cgi?query=su&sektion=1&format=html

[pSub]

This would mean, that we miss a warning for su -c staff operator on BSD, right?. Not sure if it would make sense / is possible to do different checks depending on the OS. I couldn't find an example in shellcheck.
From my perspective this PR is still an improvement over the current state.

[e-kwsm]

I have no BSD machines, but IIUC su -c staff operator starts an interactive session as operator with setting of class staff. su --command foo is not ambiguous, though it is not portable.
sudo and doas are preferable, I think.

[slycordinator]

This would mean, that we miss a warning for su -c staff operator on BSD, right?. Not sure if it would make sense / is possible to do different checks depending on the OS. I couldn't find an example in shellcheck. From my perspective this PR is still an improvement over the current state.

If the checks were to depend on OS, this raises questions:

• Which OS should be assumed when run in Windows (like in the vscode extension)?
• Should we have checks default to where the recommendations can ensure that the scripts aren't portable?

[e-kwsm]

Unfortunately su implementation varies between Linux and BSD as it is not specified in POSIX, and sudo and doas are not always avaiable.

In BSD, su -c cmd tries to start an interactive session with class of cmd but does not execute cmd; su root -c cmd is portable.

$ uname -sr
OpenBSD 8.0
$ su -c whoami
su: only the superuser may specify a login class
$ su root -c whoami
root
$ su -
# su -c whoami
su: no such login class: whoami
# su -c build  # start an interactive session as root (implied) with class of build
# exit
# su -c build root  # the same as above
# exit
# su root -c whoami
root
# su -c build root -c whoami
root

shellcheck targets BSD and macOS as you can see in README. There are issues expressing concerns about portability between GNU Linux and BSD e.g. #2902.

In that sense the current message does not care portability either:

$ shellcheck -s sh -f gcc - <<< 'su alice'
-:1:1: note: To run commands as another user, use su -c or sudo. [SC2117]

command	run command on Linux	run command on BSD
su -c cmd	Y	N
su -c cmd foo	Y	N
su foo -c cmd	Y	Y
su -c bar foo -c cmd	Y§	Y
su --command cmd	Y	N

§ silently ignores -c bar

[e-kwsm]

su -c foo        # SC2117 on BSD
su root -c foo   # better
su --command foo # this does not work on BSD, but should SC2117 cover it?

# atm shellcheck does not validate options to su
#su -z foo  # invalid option