You are not logged in.
Is checkbashisms expected to flag potential syntax that may not actually be bashisms, with the idea being that if one can rule out that all items flagged are actually OK, then dash can be used as /bin/sh?
For example checkbashisms is reporting:
possible bashism in /usr/bin/xdg-desktop-icon line 276 (alternative test command (
[[ foo ]]should be
[ foo ]And it shows the code in question as:
command="$(grep -E "^Exec(\[[^]=]*])?=" "$file" | cut -d= -f 2- | first_word)"So it appears to be flagging
[[which in its context:
Exec(...)does not appear to be a test (conditional) command.
Last edited by Gregory_M (2025-11-24 23:52:42)
Offline
Is checkbashisms expected to flag potential syntax that may not actually be bashisms, with the idea being that if one can rule out that all items flagged are actually OK, then dash can be used as /bin/sh?
Excluding false positives does mean they are not issues. It is more difficult to exclude false negatives.
Offline
Excluding false positives does mean they are not issues. It is more difficult to exclude false negatives.
Thank you for response.
I will clarify my question. Does checkbashisms sometimes report findings that are not necessarily bashisms, such that the checkbashisms output results should be reviewed to determine whether reported item(s) are indeed bashisms?
Last edited by Gregory_M (2025-11-25 00:12:40)
Offline
You provided an example where checkbashisms reported something that was not a bashism. So, yes...
Offline
You provided an example where checkbashisms reported something that was not a bashism...
Thank you kindly for confirming my example.
Last edited by Gregory_M (2025-11-25 22:44:24)
Offline
have you tried shellcheck instead?
Offline
the idea being that if one can rule out that all items flagged are actually OK, then dash can be used as /bin/sh?
False positives are way less critical and easier to deal with, so a smart tool will bias there but, there's no guarantee and you need expect them all to miss some false-negatives.
As you figured from your false-positive, they're more or less running basic greps.
The purpose is to assist you w/ automated checks, not to verify and validate code.
Offline
False positives are way less critical and easier to deal with, so a smart tool will bias there but, there's no guarantee and you need expect them all to miss some false-negatives.
The purpose is to assist you w/ automated checks, not to verify and validate code.
OK. Thank You.
@Allan also spoke of false negatives.
Does "false negative" refer to an actual bashism that is only used if a check in the containing script determines that the shell supports it?
Last edited by Gregory_M (2025-11-25 22:59:21)
Offline
https://en.wikipedia.org/wiki/False_pos … tive_error just means that the check misses actual bashisms in the script (because of quoting, line breaks, evaluation, variable expansion, …)
Offline
have you tried shellcheck instead?
I wasn't aware of it. Thank you for making me aware of it.
Offline
https://en.wikipedia.org/wiki/False_pos … tive_error just means that the check misses actual bashisms in the script (because of quoting, line breaks, evaluation, variable expansion, …)
Thanks much.
Offline