Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
shellcheck: What does this mean?
221 views
Skip to first unread message
Kenny McCormack
Nov 19, 2021, 8:20:18 PM11/19/21
to
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 said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/EternalFlame
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 said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/EternalFlame
Janis Papanagnou
Nov 19, 2021, 8:58:38 PM11/19/21
to
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
> 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?
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?
a non-existing problem, maybe?
>
> Note that the script works fine. There's nothing really wrong with it at all.
Janis
Oğuz
Nov 20, 2021, 12:49:50 AM11/20/21
to
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.
> 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?
Kenny McCormack
Nov 20, 2021, 5:50:27 AM11/20/21
to
In article <sn9ko9$g1n$1...@dont-email.me>,
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
...
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
Janis Papanagnou <janis_pa...@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 ^.
>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.
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:
Janis Papanagnou
Nov 20, 2021, 11:53:38 AM11/20/21
to
On 20.11.2021 11:50, Kenny McCormack wrote:
> In article <sn9ko9$g1n$1...@dont-email.me>,
> Janis Papanagnou <janis_pa...@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?
> In article <sn9ko9$g1n$1...@dont-email.me>,
> Janis Papanagnou <janis_pa...@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 ^.
Janis
Léa Gris
Nov 21, 2021, 2:10:14 PM11/21/21
to
Le 20/11/2021 à 02:20, Kenny McCormack écrivait :
https://www.shellcheck.net/
Before reporting issue, try to reproduce with shellcheck.net.
The shellcheck version used, might be obsolete and the issue fixed already.
Also, next time don't forget to also show the shell script's the shebang
line and shellcheck version used.
--
Lea
> --- 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 ---
Could not reproduce by checking this line of code with
> 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 ---
https://www.shellcheck.net/
Before reporting issue, try to reproduce with shellcheck.net.
The shellcheck version used, might be obsolete and the issue fixed already.
Also, next time don't forget to also show the shell script's the shebang
line and shellcheck version used.
--
Lea
0 new messages