[jeffrallen]

I review shell scripts from beginner ops people. I would not approve any of this stuff. Once you need this complexity in shell, you need other things you should be getting from the language's stdlib. So I'd ask them to switch to Python or Go.

Do not fall into the trap of big complex shell scripts.

[SoftTalker]

There's a point where what you say is true but I would not view using 'jq' to tease a list out of some JSON data to be it. Isn't that what your python or go code is going to do? All jq is is a packaged set of calls to stdlib stuff.

Systems admins are generally not Python or Go experts. And those are two dependencies which may not be available anyway (or will require installation, and maintenancee, may introduce new vulns, etc.). You could say the same about 'jq' though.

[floydnoel]

Overall I agree, but I think developers usually err the other way, where they are afraid of running any shell commands outside of invoking their developer tools.

I really enjoyed this article because I found it refreshing- it felt like it was intended for hackers. I love to learn more about different shells and functionality vs yet another unicorn's latest product announcement.

[zhouzhao]

>Do not fall into the trap of big complex shell scripts

This so much.

[calmbonsai]

I'll go further.

Shell is great for personal or local-group/team automation, but outside of a bootstrap, it should _never_ be used for anything in deployed production.

The 3 main issues are hidden deps, error handling, and performance.