Safe ways to do things in bash • Hacker News Board

Re: Safe ways to do things in bash

#251

Post by andrewshadura » Wed, May 16, 2018, 6:02 AM UTC

opinionator1 wrote: post #200

znpy wrote: post #192

Earlier quoted context omitted.

> So, you'd rather use something that is decades old because you can't/don't want to (ask to) install 1 new program on the server and take a weekend to rebuild your config file? Absolutely, yes. Because long story short, bash is TriedAndTrue® technology. Stuff that works. It takes a bit of dedication to be mastered at a decent level but it pays off immensely. It's so ubiquitous it is one of those tools that you can l…

"works" More like "better the devil you know" (if you can even say that much). Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary. At my shop bash is strictly disallowed in production environments and we're all better off for it.

It is not webscale!

Re: Safe ways to do things in bash

#252

Post by sa46 » Wed, May 16, 2018, 7:22 AM UTC

freedomben wrote: post #121

antris wrote: post #113

Earlier quoted context omitted.

What is your opinion on using other languages to augment bash? Awk, perl etc.

I personally consider awk, sed, grep, cut, etc. to be "part" of bash. I don't think I ever write a script without invoking those venerable tools at least once. I often have many pipes, such as some_command \ | grep -E 'some.*regex$' \ | sed -e 's/erase_text//g' \ | sed -e 's/erase_more//g' \ | awk '{ print $2 }' \ | cut -d ':' -f 1 I used to reach for Perl one-liners a lot, and still do sometimes when I need a gross…

Drive by code review, you can end a line with the pipe (also && and ||) to avoid a backslash.

    some_command |
      grep -E 'some.*regex$' |
      sed -e 's/erase_text//g' |
      sed -e 's/erase_more//g' |
      awk '{ print $2 }' |
      cut -d ':' -f 1

Re: Safe ways to do things in bash

#253

Post by opinionator1 » Wed, May 16, 2018, 4:44 PM UTC

robot01 wrote: post #221

opinionator1 wrote: post #200

Earlier quoted context omitted.

"works" More like "better the devil you know" (if you can even say that much). Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary. At my shop bash is strictly disallowed in production environments and we're all better off for it.

Do you guys have a different, approved shell for prod?

Nobody should be using any shell in prod

Re: Safe ways to do things in bash

#254

Post by opinionator1 » Wed, May 16, 2018, 4:47 PM UTC

znpy wrote: post #219

opinionator1 wrote: post #200

Earlier quoted context omitted.

"works" More like "better the devil you know" (if you can even say that much). Bash doesn't scale. Every shop larger than 1 has been burned by bash gotchas. Use a real scripting language and shell out to the commands and builtins when necessary. At my shop bash is strictly disallowed in production environments and we're all better off for it.

> Bash doesn't scale. Thanks mate, I had a good laugh. I wouldn't expect bash to scale anyway. That's not what it's meant for. It's meant for system administration task automation. On a more serious note ... In many occasions, the performance you get depends on how you tackle the problem you have, though. Even using bash and the tools from the unix toolbox, sometimes you can gain significant improvements on how you m…

I should have clarified. I'm not talking about micro-optimizations. Bash doesn't scale operationally. You might be a bash wizard who never fucks up, but you're never going to be able to keep non-wizards from having to use your awful bash codebase.

Bash is not at all meant for "system administration task automation", the very idea is ludicrous. It has to be the most singularly ill-purposed invention ever to be applied towards task automation.

Re: Safe ways to do things in bash

#255

Post by nunez » Wed, May 16, 2018, 9:13 PM UTC

melq wrote: post #109

nunez wrote: post #50

Shellcheck made me a MUCH better Bash developer. Also, I prefer using [ condition ] for tests instead of the less-portable [[ cond ]] syntax despite the latter being more feature-rich. Didn’t see that one in there.

Why do you prefer the former?

Portability