Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I'm being flippant, because shell scripts are so inherently error prone they're to be avoided for critical stuff like this.

If you _absolutely_ must use a shell script:

0. Use shellcheck, which will warn you about many of the below issues: https://www.shellcheck.net/

1. understand how quoting and word splitting work: https://mywiki.wooledge.org/Quotes

2. if piping files to other programs, using `-print0` or equivalent (or even better, if using something like find, its built in execution options): https://mywiki.wooledge.org/UsingFind

3. Beware the pitfalls (especially something like parsing `ls`): https://mywiki.wooledge.org/BashPitfalls

(warning: the community around that wiki can be pretty toxic, just keep that in mind when foraying into it.)



sort by: page size:

I highly recommend this site. It’s very nitpicky, and that’s the only way to write somewhat robust shell scripts. https://mywiki.wooledge.org/BashGuide

I'd recommend shellcheck[1] to help avoid common pitfalls with bash/sh, particularly in regards to word splitting.

[1] https://www.shellcheck.net/


Shellcheck is amazingly impressive at catching issues with shell scripts. It makes it very hard to write a shell script that does the wrong thing.

Also, look at oilshell[1]; it is bash compatible out-of-the-box, but has several options to make it incompatible, but safer (e.g. no field splitting of parameter expansion by default, making quotes much less needed).

1: https://www.oilshell.org/


advanced bash scripting guide: https://www.tldp.org/LDP/abs/html/

also, https://www.shellcheck.net/ not reading, but pretty neat. static code analysis for shell scripts, points out common errors.



I'd recommend against the Advanced Bash-Scripting Guide -- it uses a lot of bad practices (like unquoted variable references!) that you're better off not learning. Instead, check out http://mywiki.wooledge.org/BashGuide and http://mywiki.wooledge.org/BashFAQ. Also, http://www.shellcheck.net is a good automated tool for sanity-checking syntax errors and common mistakes.

Going to use this opportunity to spam ShellCheck, because it has historically saved me dozens of hours catching many silent Bash scripting errors and just making my scripts more robust/warning me of obscure edge cases:

https://www.shellcheck.net/


I wish there was a nicer shell scripting language that simply transpiled to Bash and would generate all this boilerplate code for me. There is https://batsh.org/ which has a nice syntax but it doesn't even support pipes or redirection, making it pretty worthless for shell scripting. I haven't found any other such scripting languages.

Remembering best practices for BASH might be hard. I recommend using http://www.shellcheck.net/. I use with vim and syntastic. This article talks more about it: http://jezenthomas.com/shell-script-static-analysis-in-vim/

I used to refer to that all the time, but it doesn't have newer bashisms (shell != bash).

A better resource is https://mywiki.wooledge.org/BashGuide Also, a preliminary read of https://mywiki.wooledge.org/BashPitfalls is advised.

Using shellcheck as a bash/shell linter is the ultimate. When you get a new warning, you can look up the code and learn why it's complaining.



I know enough bash to know a relevant shellcheck rule... Not sure that's enough to use it safely. :)

https://github.com/koalaman/shellcheck/wiki/SC2124


> The biggest Issue is that error handling is completely broken in POSIX shell scripting (including Bash). Even errexit doesn't work as any normal language would implement it (One could say it is broken by design).

I guess you're referring to http://mywiki.wooledge.org/BashFAQ/105. Got recently hit by these as well.


Shellcheck helped me learn a lot about bash.

https://www.shellcheck.net/


For portability reasons I prefer to write POSIX shell scripts instead of Bash scripts:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...


It should be noted that `ls` is kinda of a (interactive convenience) special case by itself, if you really need to parse `ls` output, you're in a world of hurt on any conventional raw_byte_stream+pipes based shell [1]. Most (non-interactive) tasks done with ls should instead be done with other, safer shell builtins or more appropriate tools.

[1] https://mywiki.wooledge.org/ParsingLs


Shellcheck [1] has a lot of issues with this script. You might consider refactoring it a little bit to pass without errors. Some of the warnings could probably be ignored.

[1] - https://www.shellcheck.net/


I find exceptionally difficult to write anything but trivial shell scripts without bugs. This one took years, and I suspect #bash could still find a bug: https://github.com/jakeogh/commandlock

On the other hand, this is amazing: https://github.com/speed47/spectre-meltdown-checker


I skip a beat, but any shell user will need this at some point in his life : http://mywiki.wooledge.org/

So many 'I wish I'd known earlier'

Other links straight from #bash@freenode

Topic for #bash is: FAQ: http://mywiki.wooledge.org/BashFAQ | Guide: http://mywiki.wooledge.org/BashGuide | ref: http://xrl.us/bhk9ww | http://wiki.bash-hackers.org/ | USE MORE QUOTES!: http://www.grymoire.com/Unix/Quote.html | Scripts and more: http://www.shelldorado.com/ | New official help mailing list: http://tx0.org/31f

They're all deeply useful

next

Legal | privacy