-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix as many existing ShellCheck reports as possible #470
Comments
Thanks for this report. Could you please detail how |
Never mind my previous comment. I have checked the whole repository and find the files to check with
I will take this opportunity to also remove unmaintained and (I think) deprecated scripts from repository:
|
Thank you, @xdelaruelle! I also went through the whole repository and I listed all text files that looked like shell scripts both to me and to ShellCheck. I've already started fixing some reports so I'll post a PR soon. |
On my side, I will create a new lint testsuite that will be callable with I will also check the Tcl scripts with Nagelfar through this testsuite. |
According to ShellCheck's documentation: Different shells support different features. To give effective advice, ShellCheck needs to know which shell your script is going to run on. Related: https://www.shellcheck.net/wiki/SC2148 Related: cea-hpc#470
According to ShellCheck's documentation: Double quotes around $@ and ${array[@]}) prevent globbing and word splitting of individual elements, while still expanding to multiple separate arguments. Related: https://www.shellcheck.net/wiki/SC2068 Related: cea-hpc#470
According to ShellCheck's documentation: Bourne shells are very whitespace sensitive. Adding or removing spaces can drastically alter the meaning of a script. Related: https://www.shellcheck.net/wiki/SC1035 Related: cea-hpc#470
According to ShellCheck's documentation: -a and -o in [ .. ] test expressions are not well defined, and can cause incorrect results when arguments start with dashes or contain !. Related: https://www.shellcheck.net/wiki/SC2166 Related: cea-hpc#470
These occurrences do not seem to cause any problems described below but let's still fix it for the sake of consistency within this script. According to ShellCheck's documentation: ShellCheck noticed that you have used a variable as an array, but then assign it a string. array=foo is equivalent to array[0]=foo, and leaves the rest of the elements unaffected. Related: https://www.shellcheck.net/wiki/SC2178 Related: cea-hpc#470
According to ShellCheck's documentation: Use "$@" (with quotes) to prevent whitespace problems. $* and ${array[*]}, unquoted, is subject to word splitting and globbing. Related: https://www.shellcheck.net/wiki/SC2048 Related: cea-hpc#470
These occurrences do not cause any problems described below but it's better to be verbose that we indeed want to access the first array element. According to ShellCheck's documentation: When referencing arrays, $myarray is equivalent to ${myarray[0]} -- it results in only the first of multiple elements. Related: https://www.shellcheck.net/wiki/SC2128 Related: cea-hpc#470
According to ShellCheck's documentation: Arrays and $@ can contain multiple elements. Simple variables contain only one. When assigning multiple elements to one element, the default behavior depends on the shell (bash concatenates with spaces, zsh concatenates with first char of IFS). Related: https://www.shellcheck.net/wiki/SC2124 Related: cea-hpc#470
According to ShellCheck's documentation: In the original code, the return value of mycmd in $(mycmd) is ignored, and export will instead always return true. This may prevent conditionals, set -e and traps from working correctly. Related: https://www.shellcheck.net/wiki/SC2155 Related: cea-hpc#470
Some variables, that were unquoted intentionally were converted to arrays. According to ShellCheck's documentation: Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such. Related: https://www.shellcheck.net/wiki/SC2086 Related: cea-hpc#470
According to ShellCheck's documentation: When command expansions are unquoted, word splitting and globbing will occur. This often manifests itself by breaking when filenames contain spaces. Related: https://www.shellcheck.net/wiki/SC2046 Related: cea-hpc#470
According to ShellCheck's documentation: export takes a variable name, but ShellCheck has noticed that you give it an expanded variable instead. Remove $/${} for that, or use ${var?} to quiet. Related: https://www.shellcheck.net/wiki/SC2163 Related: cea-hpc#470
According to ShellCheck's documentation: Different shells support different features. To give effective advice, ShellCheck needs to know which shell your script is going to run on. Related: https://www.shellcheck.net/wiki/SC2148 Related: cea-hpc#470
According to ShellCheck's documentation: Double quotes around $@ and ${array[@]}) prevent globbing and word splitting of individual elements, while still expanding to multiple separate arguments. Related: https://www.shellcheck.net/wiki/SC2068 Related: cea-hpc#470
According to ShellCheck's documentation: Bourne shells are very whitespace sensitive. Adding or removing spaces can drastically alter the meaning of a script. Related: https://www.shellcheck.net/wiki/SC1035 Related: cea-hpc#470
According to ShellCheck's documentation: -a and -o in [ .. ] test expressions are not well defined, and can cause incorrect results when arguments start with dashes or contain !. Related: https://www.shellcheck.net/wiki/SC2166 Related: cea-hpc#470
These occurrences do not seem to cause any problems described below but let's still fix it for the sake of consistency within this script. According to ShellCheck's documentation: ShellCheck noticed that you have used a variable as an array, but then assign it a string. array=foo is equivalent to array[0]=foo, and leaves the rest of the elements unaffected. Related: https://www.shellcheck.net/wiki/SC2178 Related: cea-hpc#470
According to ShellCheck's documentation: Use "$@" (with quotes) to prevent whitespace problems. $* and ${array[*]}, unquoted, is subject to word splitting and globbing. Related: https://www.shellcheck.net/wiki/SC2048 Related: cea-hpc#470
These occurrences do not cause any problems described below but it's better to be verbose that we indeed want to access the first array element. According to ShellCheck's documentation: When referencing arrays, $myarray is equivalent to ${myarray[0]} -- it results in only the first of multiple elements. Related: https://www.shellcheck.net/wiki/SC2128 Related: cea-hpc#470
According to ShellCheck's documentation: Arrays and $@ can contain multiple elements. Simple variables contain only one. When assigning multiple elements to one element, the default behavior depends on the shell (bash concatenates with spaces, zsh concatenates with first char of IFS). Related: https://www.shellcheck.net/wiki/SC2124 Related: cea-hpc#470
According to ShellCheck's documentation: In the original code, the return value of mycmd in $(mycmd) is ignored, and export will instead always return true. This may prevent conditionals, set -e and traps from working correctly. Related: https://www.shellcheck.net/wiki/SC2155 Related: cea-hpc#470
Some variables, that were unquoted intentionally were converted to arrays. According to ShellCheck's documentation: Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such. Related: https://www.shellcheck.net/wiki/SC2086 Related: cea-hpc#470
According to ShellCheck's documentation: When command expansions are unquoted, word splitting and globbing will occur. This often manifests itself by breaking when filenames contain spaces. Related: https://www.shellcheck.net/wiki/SC2046 Related: cea-hpc#470
According to ShellCheck's documentation: export takes a variable name, but ShellCheck has noticed that you give it an expanded variable instead. Remove $/${} for that, or use ${var?} to quiet. Related: https://www.shellcheck.net/wiki/SC2163 Related: cea-hpc#470
Some variables, that were unquoted intentionally were converted to arrays. According to ShellCheck's documentation: Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such. Related: https://www.shellcheck.net/wiki/SC2086 Related: cea-hpc#470
According to ShellCheck's documentation: When command expansions are unquoted, word splitting and globbing will occur. This often manifests itself by breaking when filenames contain spaces. Related: https://www.shellcheck.net/wiki/SC2046 Related: cea-hpc#470
According to ShellCheck's documentation: export takes a variable name, but ShellCheck has noticed that you give it an expanded variable instead. Remove $/${} for that, or use ${var?} to quiet. Related: https://www.shellcheck.net/wiki/SC2163 Related: cea-hpc#470
According to ShellCheck's documentation: Different shells support different features. To give effective advice, ShellCheck needs to know which shell your script is going to run on. Related: https://www.shellcheck.net/wiki/SC2148 Related: cea-hpc#470
According to ShellCheck's documentation: Double quotes around $@ and ${array[@]}) prevent globbing and word splitting of individual elements, while still expanding to multiple separate arguments. Related: https://www.shellcheck.net/wiki/SC2068 Related: cea-hpc#470
According to ShellCheck's documentation: Bourne shells are very whitespace sensitive. Adding or removing spaces can drastically alter the meaning of a script. Related: https://www.shellcheck.net/wiki/SC1035 Related: cea-hpc#470
According to ShellCheck's documentation: -a and -o in [ .. ] test expressions are not well defined, and can cause incorrect results when arguments start with dashes or contain !. Related: https://www.shellcheck.net/wiki/SC2166 Related: cea-hpc#470
These occurrences do not seem to cause any problems described below but let's still fix it for the sake of consistency within this script. According to ShellCheck's documentation: ShellCheck noticed that you have used a variable as an array, but then assign it a string. array=foo is equivalent to array[0]=foo, and leaves the rest of the elements unaffected. Related: https://www.shellcheck.net/wiki/SC2178 Related: cea-hpc#470
According to ShellCheck's documentation: Use "$@" (with quotes) to prevent whitespace problems. $* and ${array[*]}, unquoted, is subject to word splitting and globbing. Related: https://www.shellcheck.net/wiki/SC2048 Related: cea-hpc#470
These occurrences do not cause any problems described below but it's better to be verbose that we indeed want to access the first array element. According to ShellCheck's documentation: When referencing arrays, $myarray is equivalent to ${myarray[0]} -- it results in only the first of multiple elements. Related: https://www.shellcheck.net/wiki/SC2128 Related: cea-hpc#470
According to ShellCheck's documentation: In the original code, the return value of mycmd in $(mycmd) is ignored, and export will instead always return true. This may prevent conditionals, set -e and traps from working correctly. Related: https://www.shellcheck.net/wiki/SC2155 Related: cea-hpc#470
Some variables, that were unquoted intentionally were converted to arrays. According to ShellCheck's documentation: Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such. Related: https://www.shellcheck.net/wiki/SC2086 Related: cea-hpc#470
According to ShellCheck's documentation: When command expansions are unquoted, word splitting and globbing will occur. This often manifests itself by breaking when filenames contain spaces. Related: https://www.shellcheck.net/wiki/SC2046 Related: cea-hpc#470
According to ShellCheck's documentation: export takes a variable name, but ShellCheck has noticed that you give it an expanded variable instead. Remove $/${} for that, or use ${var?} to quiet. Related: https://www.shellcheck.net/wiki/SC2163 Related: cea-hpc#470
According to ShellCheck's documentation: Different shells support different features. To give effective advice, ShellCheck needs to know which shell your script is going to run on. Related: https://www.shellcheck.net/wiki/SC2148 Related: #470
According to ShellCheck's documentation: Double quotes around $@ and ${array[@]}) prevent globbing and word splitting of individual elements, while still expanding to multiple separate arguments. Related: https://www.shellcheck.net/wiki/SC2068 Related: #470
According to ShellCheck's documentation: Bourne shells are very whitespace sensitive. Adding or removing spaces can drastically alter the meaning of a script. Related: https://www.shellcheck.net/wiki/SC1035 Related: #470
According to ShellCheck's documentation: -a and -o in [ .. ] test expressions are not well defined, and can cause incorrect results when arguments start with dashes or contain !. Related: https://www.shellcheck.net/wiki/SC2166 Related: #470
These occurrences do not seem to cause any problems described below but let's still fix it for the sake of consistency within this script. According to ShellCheck's documentation: ShellCheck noticed that you have used a variable as an array, but then assign it a string. array=foo is equivalent to array[0]=foo, and leaves the rest of the elements unaffected. Related: https://www.shellcheck.net/wiki/SC2178 Related: #470
According to ShellCheck's documentation: Use "$@" (with quotes) to prevent whitespace problems. $* and ${array[*]}, unquoted, is subject to word splitting and globbing. Related: https://www.shellcheck.net/wiki/SC2048 Related: #470
These occurrences do not cause any problems described below but it's better to be verbose that we indeed want to access the first array element. According to ShellCheck's documentation: When referencing arrays, $myarray is equivalent to ${myarray[0]} -- it results in only the first of multiple elements. Related: https://www.shellcheck.net/wiki/SC2128 Related: #470
According to ShellCheck's documentation: In the original code, the return value of mycmd in $(mycmd) is ignored, and export will instead always return true. This may prevent conditionals, set -e and traps from working correctly. Related: https://www.shellcheck.net/wiki/SC2155 Related: #470
Some variables, that were unquoted intentionally were converted to arrays. According to ShellCheck's documentation: Quoting variables prevents word splitting and glob expansion, and prevents the script from breaking when input contains spaces, line feeds, glob characters and such. Related: https://www.shellcheck.net/wiki/SC2086 Related: #470
According to ShellCheck's documentation: When command expansions are unquoted, word splitting and globbing will occur. This often manifests itself by breaking when filenames contain spaces. Related: https://www.shellcheck.net/wiki/SC2046 Related: #470
According to ShellCheck's documentation: export takes a variable name, but ShellCheck has noticed that you give it an expanded variable instead. Remove $/${} for that, or use ${var?} to quiet. Related: https://www.shellcheck.net/wiki/SC2163 Related: #470
Make 'mt lint' pass with remaining shellcheck reports on sh, bash and ksh scripts. Waiting for another contribution to fix the remaining warnings and notices. Related: cea-hpc#470
Make 'mt lint' pass with remaining shellcheck reports on sh, bash and ksh scripts. Waiting for another contribution to fix the remaining warnings and notices. Related: #470
@xdelaruelle, thanks again for the fixes! I've not forgotten about this issue but, unfortunately, I don't know when I'll be able get to it again because right now I'm busy with finishing my thesis and other, more urgent, stuff related to RHEL. |
No problem @lzaoral. I am closing this issue, as the work achieved for next version (5.2) on this topic is already a good step forward. But do not hesitate to send other pull requests on this topic when you will have more time. This is much appreciated. |
Describe the bug
PR #469 added a ShellCheck linting on PRs with new changes. However, problems in already existing files are not reported (unless they are fixed). This issue tries to aggregate all such files.
List of affected shell scripts for commit 8f5f423
ShellCheck version: 8.0.0
I've tried to filter all unrelated files from this list but It's possible that some of them are not actual shell scrips.
EDIT: Remove
./script/mb
since it's not a shell script.The text was updated successfully, but these errors were encountered: