I wish it had a more comprehensive auto correct feature. I maintain a huge bash repository and have tried to use it, and it common makes mistakes. None of us maintainers have time to rewrite the scripts to match standards.
I honestly think autocorrecting your scripts would do more harm than good. ShellCheck tells you about potential issues, but It’s up to you to determine the correct behavior.
For example, how could it know whether cat$foo should be cat"$foo", or whether the script actually relies on word splitting? It’s possible that $foo intentionally contains multiple paths.
Maybe there are autofixable errors I’m not thinking of.
FYI, it’s possible to gradually adopt ShellCheck by setting --severity=error and working your way down to warnings and so on. Alternatively, you can add one-off #shellcheck ignore SC1234 comments before offending lines to silence warnings.
For example, how could it know whether cat$foo should be cat"$foo", or whether the script actually relies on word splitting? It’s possible that $foo intentionally contains multiple paths.
Last time I used ShellCheck (yesterday funnily enough) I had written ports+=($(get_elixir_ports)) to split the input since get_elixir_ports returns a string of space separated ports. It worked exactly as intended, but ShellCheck still recommended to make the splitting explicit rather than implicit.
The ShellCheck docs recommended
IFS=" "read -r -a elixir_ports <<< "(get_elixir_ports)"
ports+=("${elixir_ports[@]}")
Then you’ll have to find the time later when this leads to bugs. If you write against bash while declaring it POSIX shell, but then a random system’s sh doesn’t implement a certain thing, you’ll be SOL. Or what exactly do you mean by “match standards”?
I wish it had a more comprehensive auto correct feature. I maintain a huge bash repository and have tried to use it, and it common makes mistakes. None of us maintainers have time to rewrite the scripts to match standards.
I honestly think autocorrecting your scripts would do more harm than good. ShellCheck tells you about potential issues, but It’s up to you to determine the correct behavior.
For example, how could it know whether
cat $fooshould becat "$foo", or whether the script actually relies on word splitting? It’s possible that$foointentionally contains multiple paths.Maybe there are autofixable errors I’m not thinking of.
FYI, it’s possible to gradually adopt ShellCheck by setting
--severity=errorand working your way down to warnings and so on. Alternatively, you can add one-off#shellcheck ignore SC1234comments before offending lines to silence warnings.Last time I used ShellCheck (yesterday funnily enough) I had written
ports+=($(get_elixir_ports))to split the input sinceget_elixir_portsreturns a string of space separated ports. It worked exactly as intended, but ShellCheck still recommended to make the splitting explicit rather than implicit.The ShellCheck docs recommended
IFS=" " read -r -a elixir_ports <<< "(get_elixir_ports)" ports+=("${elixir_ports[@]}")Then you’ll have to find the time later when this leads to bugs. If you write against bash while declaring it POSIX shell, but then a random system’s
shdoesn’t implement a certain thing, you’ll be SOL. Or what exactly do you mean by “match standards”?