• Re: shellcheck: What does this mean?

    From Janis Papanagnou@21:1/5 to Kenny McCormack on Sat Nov 20 02:58:32 2021
    On 20.11.2021 02:20, Kenny McCormack wrote:
    I use shellcheck to check over my bash shell scripts. Most of what it generates is noise, but every so often, it produces something useful - something that should be fixed/cleaned up.

    I recently added some code to the script and ran shellcheck on it, and it generated the output below:

    --- Cut here ---
    In myScript line 145:
    [[ "$REPLY" =~ ^\^ ]] && REPLY="title not like '%${REPLY:1}%'"
    ^-- SC1001: This \^ will be a regular '^' in this context.
    ^-- SC2089: Quotes/backslashes will be treated literally. Use an array.
    --- Cut here ---

    The intent is to check to see if $REPLY starts with a ^ and if so, change
    it to the indicated string (yes, I am building up a SQL query). In my testing, I determined that the right syntax in a Bash =~ test, to check for
    a leading ^, is ^\^. So, what is the SC1001 complaining about? Isn't that the right syntax to use?

    My interpretation is that ^^ is sufficient since there's just one
    single ^ to indicate the start of the line and the second ^ thus
    not interpreted as another start of line but taken literally.
    I read the message just as suggestion to simplify the expression.

    Apropos simplifying; I'd probably use the simpler shell patterns
    here [[ $REPLY == ^* ]] && ... instead of regexp (looks more straightforward to me without explicit anchor; YMMV).


    Second, I don't understand the second error at all. What does "Use an
    array" mean?

    The tool seems to have got confused and provides a suggestion for
    a non-existing problem, maybe?


    Note that the script works fine. There's nothing really wrong with it at all.

    Looks quite fine to me.

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to All on Sat Nov 20 01:20:13 2021
    I use shellcheck to check over my bash shell scripts. Most of what it generates is noise, but every so often, it produces something useful - something that should be fixed/cleaned up.

    I recently added some code to the script and ran shellcheck on it, and it generated the output below:

    --- Cut here ---
    In myScript line 145:
    [[ "$REPLY" =~ ^\^ ]] && REPLY="title not like '%${REPLY:1}%'"
    ^-- SC1001: This \^ will be a regular '^' in this context.
    ^-- SC2089: Quotes/backslashes will be treated literally. Use an array.
    --- Cut here ---

    The intent is to check to see if $REPLY starts with a ^ and if so, change
    it to the indicated string (yes, I am building up a SQL query). In my
    testing, I determined that the right syntax in a Bash =~ test, to check for
    a leading ^, is ^\^. So, what is the SC1001 complaining about? Isn't that
    the right syntax to use?

    Second, I don't understand the second error at all. What does "Use an
    array" mean?

    Note that the script works fine. There's nothing really wrong with it at all.

    --
    The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with
  • From =?UTF-8?B?T8SfdXo=?=@21:1/5 to Kenny McCormack on Fri Nov 19 21:49:47 2021
    On Saturday, November 20, 2021 at 4:20:18 AM UTC+3, Kenny McCormack wrote:
    In myScript line 145:
    [[ "$REPLY" =~ ^\^ ]] && REPLY="title not like '%${REPLY:1}%'"
    ^-- SC1001: This \^ will be a regular '^' in this context.
    ^-- SC2089: Quotes/backslashes will be treated literally. Use an array.
    --- Cut here ---

    Looks like a bug in shellcheck.

    The intent is to check to see if $REPLY starts with a ^ and if so, change
    it to the indicated string (yes, I am building up a SQL query). In my testing, I determined that the right syntax in a Bash =~ test, to check for
    a leading ^, is ^\^. So, what is the SC1001 complaining about? Isn't that
    the right syntax to use?

    It is; the righthand side of `=~' is an ERE and when not inside a bracket expression, an unescaped `^' is an ERE anchoring operator. I'd do `[[ $REPLY = ^* ]]' in this case, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to janis_papanagnou@hotmail.com on Sat Nov 20 10:50:23 2021
    In article <sn9ko9$g1n$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
    ...
    My interpretation is that ^^ is sufficient since there's just one
    single ^ to indicate the start of the line and the second ^ thus
    not interpreted as another start of line but taken literally.
    I read the message just as suggestion to simplify the expression.

    In my testing, ^^ didn't work. It matched anything, not just a leading ^.

    It is possible I didn't test thoroughly enough, but it seemed that the \
    was necessary.

    BTW, now that I think about it, I should probably replace this with a case statement, since I'm actually matching for more than one leading char.
    I.e.:

    case $REPLY in
    ^*) ...
    %*) ...
    ...
    esac

    'case' tends to have fewer surprises than other constructs.

    --
    The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
    http://user.xmission.com/~gazelle/Sigs/Voltaire

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Kenny McCormack on Sat Nov 20 17:53:33 2021
    On 20.11.2021 11:50, Kenny McCormack wrote:
    In article <sn9ko9$g1n$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
    ...
    My interpretation is that ^^ is sufficient since there's just one
    single ^ to indicate the start of the line and the second ^ thus
    not interpreted as another start of line but taken literally.
    I read the message just as suggestion to simplify the expression.

    In my testing, ^^ didn't work. It matched anything, not just a leading ^.

    You are right, and I cannot explain it, it's strange. - Anyone?

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOpYSBHcmlz?=@21:1/5 to All on Sun Nov 21 20:10:08 2021
    TGUgMjAvMTEvMjAyMSDDoCAwMjoyMCwgS2VubnkgTWNDb3JtYWNrIMOpY3JpdmFpdOKArzoN Cj4gLS0tIEN1dCBoZXJlIC0tLQ0KPiBJbiBteVNjcmlwdCBsaW5lIDE0NToNCj4gICAgICAg ICAgICAgIFtbICIkUkVQTFkiID1+IF5cXiBdXSAmJiBSRVBMWT0idGl0bGUgbm90IGxpa2Ug JyUke1JFUExZOjF9JSciDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXi0tIFND MTAwMTogVGhpcyBcXiB3aWxsIGJlIGEgcmVndWxhciAnXicgaW4gdGhpcyBjb250ZXh0Lg0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeLS0gU0My MDg5OiBRdW90ZXMvYmFja3NsYXNoZXMgd2lsbCBiZSB0cmVhdGVkIGxpdGVyYWxseS4gVXNl IGFuIGFycmF5Lg0KPiAtLS0gQ3V0IGhlcmUgLS0tDQoNCkNvdWxkIG5vdCByZXByb2R1Y2Ug YnkgY2hlY2tpbmcgdGhpcyBsaW5lIG9mIGNvZGUgd2l0aCANCmh0dHBzOi8vd3d3LnNoZWxs Y2hlY2submV0Lw0KDQpCZWZvcmUgcmVwb3J0aW5nIGlzc3VlLCB0cnkgdG8gcmVwcm9kdWNl IHdpdGggc2hlbGxjaGVjay5uZXQuDQoNClRoZSBzaGVsbGNoZWNrIHZlcnNpb24gdXNlZCwg bWlnaHQgYmUgb2Jzb2xldGUgYW5kIHRoZSBpc3N1ZSBmaXhlZCBhbHJlYWR5Lg0KDQpBbHNv LCBuZXh0IHRpbWUgZG9uJ3QgZm9yZ2V0IHRvIGFsc28gc2hvdyB0aGUgc2hlbGwgc2NyaXB0 J3MgdGhlIHNoZWJhbmcgDQpsaW5lIGFuZCBzaGVsbGNoZWNrIHZlcnNpb24gdXNlZC4NCg0K LS0gDQpMZWENCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)