Live data from Hacker News

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

medium.com

71–80 of 138 posts

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

#71

I have ksh scripts I wrote over 20 years ago on xenix, which still work today on bash or ksh. Meanwhile I have python apps that didn't make it a year. Any particular version of Python is a saner choice, if you could pick one and freeze it retroactively for the last 20 years and for at least the next 20. But that is not how Python works. Python breaks every 11 minutes. I would not write anything in Python that I cared…

That's what Python2.7 is and why every major proprietary product won't adopt anything else. It's also why it won't go away. All of my Python 2.6-2.7 scripts haven't been touched in 10 years in production and they aren't likely to ever be updated. I actually now refuse to write new Python that isn't compatible with both 2&3 for this reason. Python3 refuses to stabilize.

> It's also why it won't go away.

Python 2 went away in macOS. Bash still exists.

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

#72

I was hoping someone finally had a library or something to make python good at the things shell does well (mostly, running stuff and piping output around). If only. This really just reads like someone who doesn't know shell and does know python, but thinks the problem is the tool. They continually describe shell with phrases like "obscure and difficult-to-predict" while talking through things that are either obvious…

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…

> 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 no python?" For them it was difficult to understand because apparently I avoided cat/grep/dirname/basename/etc and used shell syntax wherever possible to avoid shelling out. (the thing I did would only run when system reaches a certain load)

Everyone forgot that the target hardware has only busybox (ash) and was massively resource constrained. My only options were to implement what I was doing as an eBPF, in C, or shell (ash). The shell script took 4 days (and was refactored/optimized several times within that period), the C (or eBPF) program would have taken ~10 days and the eBPF which is the best solution is unmaintainable once I leave the company.

from a performance perspective I take a bash script any time. Also python programs over time have a risk of eventually pulling in a dozen dependencies.

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

#73

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…

> 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…

Judging by the reaction of the kids at work, what you did is already unmaintainable.

Plus, if you are running shell out of necessity on a constrained system, that doesn't mean shell deserves to be a programming language where there's actual choice.

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

#74
The one thing about Python that makes it so much more compelling over Bash is that thing you discover you need once your script starts getting long and repetitive: functions, with arguments, and return values. Python does this much better than Bash. It’s the one thing that makes me no longer use Bash. Oh and exceptions. Exceptions!

The TWO things about Python that make it more compelling are functions and exceptions. You stand a chance of handling errors in Python. In bash there’s very little else you can do, when encountering an exceptional situation that is an error, except stop. The nice thing about all these functions is you can put them in modules as well. Modules! Of course! A namespaced way of laying out non trivial amounts of code!

Ok so real functions, exceptions, modules. Three things that makes Python my default tool of choice. And libraries. Bash doesn’t have pip. Sure, bash’s “pip” is the commands it can run aka /usr/bin, but if that’s your interface then it’s hardly as flexible as say gitlab.py or requests.py.

So: apart from the functions, exceptions, modules, libraries. And speed. SPEED! And code formatting. And a debugger. And stack traces. …what has Python ever given us that makes it a no brainer replacement for bash scripts?

“Brought Unicode”

”Unicode! Oh shut up!”

After MP

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

#75

The one thing about Python that makes it so much more compelling over Bash is that thing you discover you need once your script starts getting long and repetitive: functions, with arguments, and return values. Python does this much better than Bash. It’s the one thing that makes me no longer use Bash. Oh and exceptions. Exceptions! The TWO things about Python that make it more compelling are functions and exceptions.…

Typically you don't want to do dependency management for simple scripts, but that's fine because python is batteries included

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

#77

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 can probably run my bash script on every linux I ever touched.

Exactly THIS !

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

#78
post #73

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…

Judging by the reaction of the kids at work, what you did is already unmaintainable. Plus, if you are running shell out of necessity on a constrained system, that doesn't mean shell deserves to be a programming language where there's actual choice.

> what you did is already unmaintainable.

how so? there is no python or perl or ruby etc on the target. what would have been a maintainable option other than /bin/sh ? C/C++ ?

> where there's actual choice.

again what choice? :) as I said there is no other solution than what I've given. the system literally doesn't have anything else regardless what "I think" it should support.

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

#79

having a hard time being sold here. mkdir -p would create the directory without error. checking if a directory exists is trivial before creating it. Python throws an error if the path given to os.mkdir exists too. This article is way too long to digest, so i should stop now. Perhaps the argument should be, rewrite hacky things in bash as programs and build them into your apps?

>This article is way too long to digest, so i should stop now.

Lol one of the top problems with having "scripts" in python, their reliability-lifetime" (a.k.a as execute-and-forget) is very limited. Packages are outdated, api changes etc etc

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

#80

The one thing about Python that makes it so much more compelling over Bash is that thing you discover you need once your script starts getting long and repetitive: functions, with arguments, and return values. Python does this much better than Bash. It’s the one thing that makes me no longer use Bash. Oh and exceptions. Exceptions! The TWO things about Python that make it more compelling are functions and exceptions.…

> And speed. SPEED!

Maybe I'm just a terrible python programmer and also all those around me suck at it but in 20+ years I have yet to see a well optimized python script faster than a well optimized bash/ash/csh/ksh/zsh script. Maybe your point is true if a script constantly does foo=`some thing` and constantly shells out other commands.

Post reply on HN