4 ms·

FWIW shellcheck complains about many false positives.

gravitas 6y ago
But in this case, their code is comparing strings to ints like on line 126: while [[ "$#" -gt 0 ]]; do Spot checking code for basic bash mistakes like this tends to tell me the quality of the code overall, as these are basic mistakes. $0.02
- hk__2 6y ago
  If $# is a number, aren’t "$#" and $# exactly the same in Bash? Enclosing things in double quotes doesn’t change their type, since everything is already treated as a string. https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html https://www.gnu.org/software/bash/manual/html_node/Double-Qu...
  - pizza234 6y ago
    It's true, but you're semantically overloading the variable syntax (by hinting that it's treated as string). Plus, left and single operands, in bash conditions, don't require quoting, so a lean style is actually not to use them at all.
    - tempodox 6y ago
      > …left and single operands… That's false: x='foo bar'; [ $x = 'foo bar' ]; echo $? -bash: [: too many arguments x='foo bar'; [ "$x" = 'foo bar' ]; echo $? 0
      - gravitas 6y ago
        As I replied to your other comment, you cannot just replace [[ with [ and get the same behaviour. If you use the actual bash builtin [[ which we're discussing, it works as expected. Also, please use == when comparing, = is an assignment operator (in almost every programming language).
        tempodox 6y ago
        My bad. I interpreted “bash conditions” differently.
  - gravitas 6y ago
    While the other reply to you is correct, the actual answer to your question is No -- bash interprets leading 0s (zeros) in the C sense, it indicates octal not decimal. So this very small bash will fail for you: X="08" if [[ "$X" -eq 8 ]]; then echo Y fi Use `bash -x` to run it in debug mode: $ bash -x test.sh + X=08 + [[ 08 -eq 8 ]] test.sh: line 2: [[: 08: value too great for base (error token is "08") This comes into play if you're dealing with things like IPv4 address, where it is technically allowable to have leading zeros, however by convention it's never done because of code traps which see those leading zeros as octal mode, not decimal.
    - tempodox 6y ago
      Your example only demonstrates the effect of `[[`. If you replace it with `[` the error won't occur. In both cases double-quoting (or not) `$X` makes no difference in the context of your example.
      - gravitas 6y ago
        [ is an external program called "test" and [[ is a bash builtin, they have many different behaviours beyond just trying to use one to prove the other wrong on a random internet comment.
        tempodox 6y ago
        I merely used that to show that the error message was tied to `[[` and not to the use of double quotes (which your parent comment was asking about).
- abathur 6y ago
  Is this actually a shellcheck error? It just evaluates to the integer number of arguments in $@, so I doubt it is (and I doubt it matters whether it's quoted? unless there's a bash back-compat issue here?)
- dougwbrunton 6y ago
  Is there a bug in the command line parsing there? I can't see it.
  - tempodox 6y ago
    In this specific case it's more of a nitpick, I think. Even shellcheck won't demand double-quoting `$#` because everyone(?) knows that it'll always be a number and have no whitespace in it nor evaluate to an empty string.
pizza234 6y ago
Do you refer to shellcheck in general or in this specific case? I do a non-trivial amount of shell scripting, and there is only one warning I disable in shellcheck on a general basis (SC2016). The author of this script clearly doesn't like quoting where the underlying value is guaranteed not to include special characters (or space), although this is somewhat inconsistent with the fact that he's using quotes in several patterns where it's not needed (eg. left or single operands in bash conditionals, or in variables initialization). On can consider always quoting a defensive practice. In a fragile language like Bash, I personally think defensive practices are very important, so the first impression I get from a Bash program not adopting them is "not great".

But in this case, their code is comparing strings to ints like on line 126: while [[ "$#" -gt 0 ]]; do Spot checking code for basic bash mistakes like this tends to tell me the quality of the code overall, as these are basic mistakes. $0.02

hk__2 6y ago
If $# is a number, aren’t "$#" and $# exactly the same in Bash? Enclosing things in double quotes doesn’t change their type, since everything is already treated as a string. https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html https://www.gnu.org/software/bash/manual/html_node/Double-Qu...
- pizza234 6y ago
  It's true, but you're semantically overloading the variable syntax (by hinting that it's treated as string). Plus, left and single operands, in bash conditions, don't require quoting, so a lean style is actually not to use them at all.
  - tempodox 6y ago
    > …left and single operands… That's false: x='foo bar'; [ $x = 'foo bar' ]; echo $? -bash: [: too many arguments x='foo bar'; [ "$x" = 'foo bar' ]; echo $? 0
    - gravitas 6y ago
      As I replied to your other comment, you cannot just replace [[ with [ and get the same behaviour. If you use the actual bash builtin [[ which we're discussing, it works as expected. Also, please use == when comparing, = is an assignment operator (in almost every programming language).
      - tempodox 6y ago
        My bad. I interpreted “bash conditions” differently.
- gravitas 6y ago
  While the other reply to you is correct, the actual answer to your question is No -- bash interprets leading 0s (zeros) in the C sense, it indicates octal not decimal. So this very small bash will fail for you: X="08" if [[ "$X" -eq 8 ]]; then echo Y fi Use `bash -x` to run it in debug mode: $ bash -x test.sh + X=08 + [[ 08 -eq 8 ]] test.sh: line 2: [[: 08: value too great for base (error token is "08") This comes into play if you're dealing with things like IPv4 address, where it is technically allowable to have leading zeros, however by convention it's never done because of code traps which see those leading zeros as octal mode, not decimal.
  - tempodox 6y ago
    Your example only demonstrates the effect of `[[`. If you replace it with `[` the error won't occur. In both cases double-quoting (or not) `$X` makes no difference in the context of your example.
    - gravitas 6y ago
      [ is an external program called "test" and [[ is a bash builtin, they have many different behaviours beyond just trying to use one to prove the other wrong on a random internet comment.
      - tempodox 6y ago
        I merely used that to show that the error message was tied to `[[` and not to the use of double quotes (which your parent comment was asking about).
abathur 6y ago
Is this actually a shellcheck error? It just evaluates to the integer number of arguments in $@, so I doubt it is (and I doubt it matters whether it's quoted? unless there's a bash back-compat issue here?)
dougwbrunton 6y ago
Is there a bug in the command line parsing there? I can't see it.
- tempodox 6y ago
  In this specific case it's more of a nitpick, I think. Even shellcheck won't demand double-quoting `$#` because everyone(?) knows that it'll always be a number and have no whitespace in it nor evaluate to an empty string.

pizza234 6y ago

Do you refer to shellcheck in general or in this specific case? I do a non-trivial amount of shell scripting, and there is only one warning I disable in shellcheck on a general basis (SC2016). The author of this script clearly doesn't like quoting where the underlying value is guaranteed not to include special characters (or space), although this is somewhat inconsistent with the fact that he's using quotes in several patterns where it's not needed (eg. left or single operands in bash conditionals, or in variables initialization). On can consider always quoting a defensive practice. In a fragile language like Bash, I personally think defensive practices are very important, so the first impression I get from a Bash program not adopting them is "not great".