I have always tried to avoid using functions in my bash scripts. That said, it's always nice to other people's bash programming techniques and style. This one had the biggest impact for me, although I can't imagine it's news to any of you on here: http://redsymbol.net/articles/unofficial-bash-strict-mode/
Defensive BASH programming
31–40 of 53 posts
Re: Defensive BASH programming
#32Step 1: Choose a better language. Almost anything will do.
Re: Defensive BASH programming
#33This guide is all but ready for prime time. Make it go down, as it is a pile of bad habits. Sure, there are one or two good ideas, but nothing revolutionnary.
Use www.shellcheck.net as a complement
Re: Defensive BASH programming
#34Slightly off-topic but maybe some people will find it useful: I used to write my various glue-things-together scripts in bash, but this quickly becomes a nightmare as the script grows, due to bash's corner cases, syntax, portability issues etc. Recently I wrote my massive glue-things-together script with nodejs (since I already use node for many things) and it's much more maintainable and I couldn't be more happy. No…
Is it really a 'script' if you need to add a dir full of modules? I've always thought of 'scripts' as all-in-ones.
Well, you're right, it's a tradeoff. The 'script' is not standalone anymore, but it's a (script + package.json) and needs `npm install` to work properly. I still use bash for simple things, but if it grows too much and logic starts getting non-trivial, IMO it's a valid use case to switch.
Re: Defensive BASH programming
#35A guy publishing a guide for "defensive bash programming", who, in the process, provides this listing as an example for anything, is not fit for publishing said guide in the first place: main() { local files=$(ls /tmp | grep pid | grep -v daemon) }
You might have been better off reading the text after the code example that came after the code you quoted.
The text read:
- Second example is much better. Finding files is the problem of temporary_files() and not of main()’s. This code is also testable, by unit testing of temporary_files().
- If you try to test the first example, you will mish mash finding temporary files with main algorithm.
Re: Defensive BASH programming
#36Does anyone know if these ideas conflict with http://mywiki.wooledge.org/BashFAQ or http://mywiki.wooledge.org/BashGuide ? These are the resources that are drummed into you on #bash on Freenode, with the strong suggestion that All Other Resources Are Bad And You Should Feel Bad
The #bash users on freenode are right on that one. Everything in the wiki you linked to is documented and everything is explained clearly.
Another very good resource is the O'Reilly book: http://shop.oreilly.com/product/9780596009656.do
Re: Defensive BASH programming
#37The sloshes are redundant after a pipe symbol. i.e. ls $dir \ | grep something is the same as ls $dir | grep something
However, the author argues that the pipe symbol should be moved to be beginning of the next line, so the backslash isn't optional.
Re: Defensive BASH programming
#38Content from so long ago, posted here on HN less than two weeks ago... here are some recent reddit comments about the post:
https://www.reddit.com/r/bash/comments/3w354v/defensive_bash...
Re: Defensive BASH programming
#39Slightly off-topic but maybe some people will find it useful: I used to write my various glue-things-together scripts in bash, but this quickly becomes a nightmare as the script grows, due to bash's corner cases, syntax, portability issues etc. Recently I wrote my massive glue-things-together script with nodejs (since I already use node for many things) and it's much more maintainable and I couldn't be more happy. No…
I would love to write my bash scripts in node, but end up writing them in bash anyway ... How do you do something like this in node? sudo -u 2>&1 >> logfile | tee | echo
I'm assuming this isn't a real example of a thing you would want to do, because it doesn't make sense. (redirecting stderr to stdout, stdout to a file, then pipe to tee and echo?)
At any rate, you'd:
1. use some sort of popen()
2. use pipes and pass the same pipe to stdout as stderr
3. pass stdout of one popen to another's stdin
4. just use bash, because this gets so hairy and bash does it really well. When I want to use a complex pipeline of programs in non-bash programs, I'll frequently popen() to a bash script. This is ugly, but if you're really careful (shellshock?) it can be ok.
Re: Defensive BASH programming
#40A guy publishing a guide for "defensive bash programming", who, in the process, provides this listing as an example for anything, is not fit for publishing said guide in the first place: main() { local files=$(ls /tmp | grep pid | grep -v daemon) }
You might have been better off reading the text after the code example that came after the code you quoted. The text read: - Second example is much better. Finding files is the problem of temporary_files() and not of main()’s. This code is also testable, by unit testing of temporary_files(). - If you try to test the first example, you will mish mash finding temporary files with main algorithm.
The problem isn't where it is - using "ls" to find files is never a good idea from my understanding. I think it's because of ls garbling file names but I might be mistaken there.
That the author is using that to find files is reasonable enough to me to disregard the rest of the blog.
edit: take that back...looked through rest of blog but don't see anything useful. I hate his idea for functions for builtins, using local is ok, please don't break up shell pipelines over N lines for simple stuff