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

91–100 of 138 posts

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

#91

Post by rvieira »

BeetleB wrote: post #20
yjftsjthsd-h wrote: post #8

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…

> 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. xonsh ( https://xon.sh/ ) Been using it for a few years now. It's worth it.

Never heard of xonsh before and it looks really useful. Thanks.

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

#92

Post by HeckFeck »

Izkata wrote: post #60
Brian_K_White wrote: post #59

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…

Over the past decade I've been drifting towards doing more and more in bash that I'd've normally done one one language or another just because of this stability. Perl is another candidate if I need something more complicated, but I'm not as familiar with it so I don't really reach for it often. Are there any other languages with the same stability that would also fill this niche?

I've learnt Perl for this very reason. It is extremely capable, extensible and still very backwards-compatible. It feels like an evolution of bash but much more performant.

A bit of a shame that it's seen as an anachronism to many. Perl soon rubs off on you and becomes a delight.

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

#93

Post by aloisdg »

derekbaker783 wrote: post #53
GSGBen wrote: post #48

Earlier quoted context omitted.

> 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. Good news, they did! Even better news: it doesn't require python, it's cross platform, and supports an easy-to-read verbose style for scripts but a quick-to-write terse style for interactive usage. It's an absolute joy to use for nested data structures,…

What is Powershell

A dotnet based shell where you can share around dotnet object instead of plain text.

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

#95

Post by raffraffraff »

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…

Also, how much code would it take to do the same thing in python?

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

#96

Post by kleene_op »

raffraffraff wrote: post #95
Arnavion wrote: post #61

Earlier quoted context omitted.

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…

Also, how much code would it take to do the same thing in python?

Probably something along the line of

  Popen(["the_tool"] + list(Path().glob("*.yml")))

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

#98

Post by xorcist »

deathanatos wrote: post #55
yjftsjthsd-h wrote: post #8

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…

This tool of yours can not cope with files not existing, and causes production outages? Yet somehow you manage to blame bash for this? The outcome would not have been different if systemd or python started your tool.

In fact, handling that types of errors is what bash is suitable for. "If file is readable, process it" is not an unusual construct. Please do take care however to avoid races if this directory is a spool directory that can be populated at any time, in which case it is useful that rename() is atomic, sometimes an additional working directory is required. Again, this is how the operating system is designed and nothing the shell can gloss over.

I have seen many problems from previously unknown race conditions when concurrency is increased. Scripts have to be kept composable and trivial to understand in order to guard against that.

To be honest, I would argue to remove any script that looks like the last example above. It is not clear what side effects of that bizarre array construct are useful to the system. Keep scripts as simple and readable as possible, a trivial truth perhaps, applicable to every language, but one that needs to be reiterated until the end of our profession.

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

#99

Post by xorcist »

Izkata wrote: post #63
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…

My preferred way under those conditions would be more along the lines of "see if a safe command fails, do the desired command if not", like: if ls *.yaml > /dev/null; then the_tool *.yaml fi

That only looks simple because we don't know what problem was being solved.

Is it really right to not process any files just because one of them just disappeared?

In general, situations like this suffer from race conditions and time-of-check/time-of-use problems.

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

#100

Post by tempodox »

rhn_mk1 wrote: post #73
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…

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.

If the kids refuse to learn anything new (to them), they chose the wrong occupation.
Post reply on HN