Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bashing the Bash – Replacing Shell Scripts with Python (2017)

medium.com

Post reply on HN
Print view View original

131–138 of 138 posts

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#131

Post by bdowling »

kaba0 wrote: post #119
DyslexicAtheist wrote: post #72

Earlier quoted context omitted.

> To say "you're holding it wrong" is just folly. Bash is worthy of the same treatment that "A Fractal of Bad Design" gave PHP, and it has no place in anything that wants to call itself engineering. is this a cloud AMD64 opinion that ignores the 2 trillion devices which Gartner predicts will never run python? I recently finished a ~600 lines ash script and the kids at work which just graduated complained that *"Y u n…

How is bash performant? It is literally interpret by lines , and starting a whole process per if statements..

> How is bash performant?

Typically, time spent interpreting control flow in a bash script is dwarfed by time spent in the programs called by the script.

> It is literally interpret by lines

It's just splitting lines into words to build up commands. It's not compiling C++.

> starting a whole process per if statements..

In the common pattern `if command1; then command2; fi`, if command1 is a builtin (e.g., `test` or `[`), then bash does not create a subprocess.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#132

Post by kaba0 »

bdowling wrote: post #131
kaba0 wrote: post #119

Earlier quoted context omitted.

How is bash performant? It is literally interpret by lines , and starting a whole process per if statements..

> How is bash performant? Typically, time spent interpreting control flow in a bash script is dwarfed by time spent in the programs called by the script. > It is literally interpret by lines It's just splitting lines into words to build up commands. It's not compiling C++. > starting a whole process per if statements.. In the common pattern `if command1 ; then command2 ; fi`, if command1 is a builtin (e.g., `test` or…

Still doesn’t make it fast in any meaning of the word, which was my original criticism.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#133

Post by lsferreira42 »

nijave wrote: post #103
readingnews wrote: post #36

I have some bad news for you, from a long, long, long time CS/EE/Sysadmin person: I can probably run my bash script on every linux I ever touched. I can probably have that python code break on half of the linux boxen I use. This one does not have module X installed. This one is too old, this one is too new, this python is not holding its mouth just at the right angle to work. Yeah, bash bash all you want. I have pull…

I have the same issue with bash scripts. One host has jq, another is missing it. One host has yq version 2 with completely different syntax than yq version 4. If you switch from Linux to *nix where you introduce BSD variants (like macOS) it gets even worse. Python dependency management leaves much to be desired but bash has none.

That's why you try to write scripts for standard tools and shell features

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#134

Post by bdowling »

kaba0 wrote: post #132
bdowling wrote: post #131

Earlier quoted context omitted.

> How is bash performant? Typically, time spent interpreting control flow in a bash script is dwarfed by time spent in the programs called by the script. > It is literally interpret by lines It's just splitting lines into words to build up commands. It's not compiling C++. > starting a whole process per if statements.. In the common pattern `if command1 ; then command2 ; fi`, if command1 is a builtin (e.g., `test` or…

Still doesn’t make it fast in any meaning of the word, which was my original criticism.

You asked how bash is performant. I responded with reasons its performance is good in many applications. Here”s one more: bash starts up faster than other interpreters (e.g., Python), and startup time can often be a significant factor in overall performance.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#136

Post by deathanatos »

Arnavion wrote: post #61
deathanatos wrote: post #55

Earlier quoted context omitted.

We had some problem, roughly, "run a tool on all YAML files in the directory" or something. The first attempt that led to a production outage: (It is late, bash examples are approximate. Don't sweat the syntax.) the_tool *.yaml There weren't any YAML files, so argv[1] was literally "*.yaml", which then wasn't found, leading to errors, etc. shopt -s nullglob the_tool *.yaml (Don't even get me started on how there's sh…

find . -maxdepth 1 -name '*.yaml' -print0 | xargs -r0 the_tool >To say "you're holding it wrong" is just folly. Bash is worthy of the same treatment that "A Fractal of Bad Design" gave PHP, and it has no place in anything that wants to call itself engineering. If you have a problem that involves "run a command with a list of parameters but not if the list is empty" and you don't immediately think of `xargs -r`, then…

I'll submit that that's a solution.

But it's like, I have to turn my head around and stop doing one thing (globs), and switch over to another thing (find, xargs). The language has baited me down one way of doing it, when I shouldn't be doing it that way. I'm well aware of xargs (but not the -r flag). I typically avoid xargs, as our code has to¹ work on macOS & Linux, and xargs is one of those utilities whose available options differ between the two for even simple use cases. (Such as here, for the "does it exec on no args?".)

But it still proves the point: the equivalent Python is just so much more straight-forward, easier to read, and not apt to shoot me at a moments notice, and doesn't have bugs. A reader only familiar with Python's syntax can read and understand Python, and can write Python that is correct. Not so with bash, you have to understand, "oh, no, globs will screw you here, you need this flag from this utility" — no, it's lunacy.

Like, I can go down the road you're suggesting (and in the past, I did) and keep learning the nooks and crannies and intricacies of bash, each one adding to the nightmare fuel that is my understanding of shell. I can keep tweaking the script around various failure modes, letting each line fail in prod 3 different ways. Or, I can just re-write it in Python, or Rust, or any other sane language and have it never fail again, for reasons that would also either apply to bash, or apply and have worse consequences than bash. (E.g., the Python would raise, bash would just plow on with it.)

Your response is exactly the same as my response before I saw the light on PHP, C, etc.: "you're holding it wrong". No, it's a bad tool that guiles the user into holding it wrong. There are better tools that are easier to hold.

¹b/c despite all work being done for Linux, devs get MBPs, b/c the company can't manage more than exactly 1 type of machine, for everyone.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#137

Post by kafkaIncarnate »

fiddlerwoaroof wrote: post #116
kafkaIncarnate wrote: post #114

Earlier quoted context omitted.

Python2.7 is still maintained. If you mean my software I mentioned if something breaks I'm still required to fix it. I just doubt that will happen at this point and have other tasks to do.

Isn’t Python 2.7 EOL as of January 2020 or something? It’s maintained in the sense that there are still people shipping patches, but the core Python developers no longer maintain it.

That is news to me, and good to know.

https://www.bleepingcomputer.com/news/software/python-27-rea...

Apparently RHEL will maintain any security problems until 2024, but yeah it's pretty much dead. Huh. Not sure how to react to that.

Re: Bashing the Bash – Replacing Shell Scripts with Python (2017)

#138

Post by nijave »

lsferreira42 wrote: post #133
nijave wrote: post #103

Earlier quoted context omitted.

I have the same issue with bash scripts. One host has jq, another is missing it. One host has yq version 2 with completely different syntax than yq version 4. If you switch from Linux to *nix where you introduce BSD variants (like macOS) it gets even worse. Python dependency management leaves much to be desired but bash has none.

That's why you try to write scripts for standard tools and shell features

What are standard tools and shell features? Bash + GNU? Those might be consistently installed on common Linux distros but that doesn't work across *nix systems (Linux, macOS, BSD). That probably won't work against less-common Linux setups like anything embedded (busybox or container images) either
Post reply on HN