4 ms·

This advice is largely automated by https://github.com/koalaman/shellcheck https://github.com/koalaman/shellcheck

blueflow 5y ago
It felt nice when i discovered shellcheck. I made the mistake of trying to get my scripts 100% compliant... and was then astounded to find i broke several of them. If you don't know what you are doing, and shellcheck knows more, it might be useful. But if you know what you are doing, shellcheck becomes annoying quickly. Example: echo "$(command)" is marked as SC2005, useless echo. But command does not always print a newline, so "fixing" this would garble your output under some conditions.
- anotherhue 5y ago
  Very true, and I experienced something similar just yesterday. I've begun piping such untrustworthy commands to xargs -n1 to guarantee good behavior.
  - blueflow 5y ago
    Take note that this splits words into separate lines.
    - teddyh 5y ago
      Bare “xargs” should work here, I would think?
- account42 5y ago
  > Example: echo "$(command)" is marked as SC2005, useless echo. But command does not always print a newline, so "fixing" this would garble your output under some conditions. It should still be `printf '%s\n' "$(command)"` for portability unless the intention is for the output of your command to possible be interpreted as a flag for echo.
  - q3k 5y ago
    Amazing example of why robust shell scripts are hard.
  - blueflow 5y ago
    You got me there! There are indeed values that start with a hyphen, somehow it didn't break previously.
  - kergonath 5y ago
    > It should still be `printf '%s\n' "$(command)"` for portability Damn that’s ugly though. Not much better than Perl in terms of characters soup. And Perl has a massive advantage with its deep integration of regexes.
    - hnlmorg 5y ago
      Perl's character soup is because it's an evolution of sed and awk so Perl adopted many of the UNIX shell idioms.
  - hnlmorg 5y ago
    One of my pet peeves with command line tools is where they take a list of values but also support flags. You then have no end of fun working with hyphen-prefixed file names and no end of hard to find bugs too (at least most shell script writers are aware that spaces in file names are a pain but these kinds of bugs are a lot more dangerous and easier to forget). I can forgive a lot of design flaws because the tech was new and people didn't know any better but I always struggle to apply that same reasoning with the design of having commands that support both free text and flags that change that command's operation. I'm surprised nobody at the time paused and said "this might be a problem" when they were writing their tools and only using the hyphen to distinguish between a flag or data. Maybe I'm being a little unfair though -- it is hard to put yourself in their shoes and unlearn 50 years of tech. My biggest peeve about it though is that I can write a shell that doesn't apply to POSIX and which fixes a lot of shortcomings of shell scripting. But I cannot fix this specific class of bugs without rewriting the entirety of coreutils.
- deleted 5y ago
  [deleted]
- dtgriscom 5y ago
  Oh, yeah. I've broken multiple historic scripts in obscure ways "fixing" them under shellcheck's direction. It's a general lesson for linters: if it points out code where the results may be surprising, then be aware that the "surprising" result may be necessary for the code's function.
- arglebargle123 5y ago
  Shellcheck is still incredibly handy to re-check your work for simple mistakes, but man do I ever end up using a lot of shellcheck ignore statements.
neves 5y ago
I'm a big fan of shellcheck, but use it for your new scripts. Don't try to change working code that depends on shell idiosyncrasies.
gkfasdfasdf 5y ago
As well, having a bash language server enabled (https://github.com/bash-lsp/bash-language-server https://github.com/bash-lsp/bash-language-server) helps immensely.

It felt nice when i discovered shellcheck. I made the mistake of trying to get my scripts 100% compliant... and was then astounded to find i broke several of them. If you don't know what you are doing, and shellcheck knows more, it might be useful. But if you know what you are doing, shellcheck becomes annoying quickly. Example: echo "$(command)" is marked as SC2005, useless echo. But command does not always print a newline, so "fixing" this would garble your output under some conditions.

anotherhue 5y ago
Very true, and I experienced something similar just yesterday. I've begun piping such untrustworthy commands to xargs -n1 to guarantee good behavior.
- blueflow 5y ago
  Take note that this splits words into separate lines.
  - teddyh 5y ago
    Bare “xargs” should work here, I would think?
account42 5y ago
> Example: echo "$(command)" is marked as SC2005, useless echo. But command does not always print a newline, so "fixing" this would garble your output under some conditions. It should still be `printf '%s\n' "$(command)"` for portability unless the intention is for the output of your command to possible be interpreted as a flag for echo.
- q3k 5y ago
  Amazing example of why robust shell scripts are hard.
- blueflow 5y ago
  You got me there! There are indeed values that start with a hyphen, somehow it didn't break previously.
- kergonath 5y ago
  > It should still be `printf '%s\n' "$(command)"` for portability Damn that’s ugly though. Not much better than Perl in terms of characters soup. And Perl has a massive advantage with its deep integration of regexes.
  - hnlmorg 5y ago
    Perl's character soup is because it's an evolution of sed and awk so Perl adopted many of the UNIX shell idioms.
- hnlmorg 5y ago
  One of my pet peeves with command line tools is where they take a list of values but also support flags. You then have no end of fun working with hyphen-prefixed file names and no end of hard to find bugs too (at least most shell script writers are aware that spaces in file names are a pain but these kinds of bugs are a lot more dangerous and easier to forget). I can forgive a lot of design flaws because the tech was new and people didn't know any better but I always struggle to apply that same reasoning with the design of having commands that support both free text and flags that change that command's operation. I'm surprised nobody at the time paused and said "this might be a problem" when they were writing their tools and only using the hyphen to distinguish between a flag or data. Maybe I'm being a little unfair though -- it is hard to put yourself in their shoes and unlearn 50 years of tech. My biggest peeve about it though is that I can write a shell that doesn't apply to POSIX and which fixes a lot of shortcomings of shell scripting. But I cannot fix this specific class of bugs without rewriting the entirety of coreutils.
deleted 5y ago
[deleted]
dtgriscom 5y ago
Oh, yeah. I've broken multiple historic scripts in obscure ways "fixing" them under shellcheck's direction. It's a general lesson for linters: if it points out code where the results may be surprising, then be aware that the "surprising" result may be necessary for the code's function.
arglebargle123 5y ago
Shellcheck is still incredibly handy to re-check your work for simple mistakes, but man do I ever end up using a lot of shellcheck ignore statements.

neves 5y ago

I'm a big fan of shellcheck, but use it for your new scripts. Don't try to change working code that depends on shell idiosyncrasies.

gkfasdfasdf 5y ago

As well, having a bash language server enabled (https://github.com/bash-lsp/bash-language-server https://github.com/bash-lsp/bash-language-server) helps immensely.