top | item 40982719

(no title)

qz_kb | 1 year ago

Using python and constraining yourself to only use a basic subset of the standard library modules so you can run the script in pretty much any environment is almost always a better choice than trying to write even one loop, if statement, or argument parser in a bash script.

bash script is "okay" I guess if your "script" is just a series of commands with no control flow.

discuss

order

mazambazz|1 year ago

Hard disagree. I've written plenty in both. They both have their strengths, but bash is just more efficient if you're working with the filesystem. The UNIX philosophy of "do one thing and do it well" shines here. Python is more powerful but it's a double-edged sword. If I want to read a file containing API endpoints, send a request to them for some JSON, and do some parsing, I don't want to need or want to deal with importing modules, opening file objects, using dictionaries, methods, functions, etc.

Why do that when I can literally just ``` N=0 while read -r URL; do curl "$URL" | jq '.data[].someProp' | grep -v "filter" > "$N.data" N="$((N+1))" done < ./links.txt ```

The other thing is bash makes it exceptionally easier to integrate across different system tools. Need to grab something from a remote with `rsync`, edit some exif, upload it to a CDN? That's 3 commands in a row, versus god knows what libraries, objects, and methods you need to deal with in Python.

skydhash|1 year ago

Libraries are nice, until you have to write the glue code between the modules and functions. But sometimes you already have the features you want as programs and you just need to do some basic manipulation with their arguments and outputs. And the string model can work well in that case.

wiseowise|1 year ago

> Why do that when I can literally just ``` N=0 while read -r URL; do curl "$URL" | jq '.data[].someProp' | grep -v "filter" > "$N.data" N="$((N+1))" done < ./links.txt ```

So that other people can read and modify this.

qz_kb|1 year ago

now add error handling.

aulin|1 year ago

Choice is a privilege you rarely have in a day to day job. Bash most of the time is already there and you have to live with it.

Also, I've been forced to work on a huge SCons based project and I guarantee python can make your life quite miserable when used for something it's not supposed to.

qz_kb|1 year ago

I'm not suggesting you build a a whole build system with python (which is basically bazel and it seems to be good enough for google.)

A lot of originally little automation/dev scripts bloat into more complicated things as edge cases are bolted on and bash scripts become abominations in these cases almost immediately.

udev4096|1 year ago

Bash is native. You won't find python pre-installed on all distros, like alpine

hi_hi|1 year ago

Bash may be native, but alot of the programs you'll want to call may not be, or will differ between platforms in subtle ways. Although this won't be a concern for small/trivial scripts, but if we're talking about python as an alternative, my point probably still applies.

lloeki|1 year ago

> You won't find python pre-installed on all distros, like alpine

The same can be said of bash, especially since you mention Alpine (also FreeBSD)

Perl, though... ;)

(if Perl is not there it gets pulled in very quickly as a dependency of something, e.g typically you pull git, you get perl)

yawpitch|1 year ago

True, though there’s a whole world of people who will yell at you for using Bash-isms rather than pure posix precisely because Bash (at least up to date versions) isn’t everywhere either.

rendaw|1 year ago

I agree, but I've been having a hard time even with python recently. I had a small script (50-100 lines) to format a data drive on boot I refactored, 3 or 4 obvious undeclared variables and who knows how many more I didn't notice - mypy found 0 issues.

I was looking up statically typed alternatives and stumbled upon Ammonite and Scala-CLI for scala. I haven't used them much, but Ammonite bundles some basic libraries including command line parsing, http, and json, which are probably 99% of what I used in Python too? And Scala seems like an interesting language too with decent editor integration.

wiseowise|1 year ago

> I had a small script (50-100 lines) to format a data drive on boot I refactored, 3 or 4 obvious undeclared variables and who knows how many more I didn't notice - mypy found 0 issues.

What does pyright/pylance say?

macrael|1 year ago

use mypy!

runjake|1 year ago

As a person who’s been doing shell programming for 35 years and Python for 15 years, I completely disagree.

Bash scripts and Bash control flow has been and is used in highly critical scripts all over the place, including other planets.

We’ve been writing reliable, well-designed scripts for many decades. Some of my scripts are several hundred lines long and older than the system engineers currently occupying their positions.

Python is fine too. Use the right tool for the right job.

NegativeLatency|1 year ago

Had decent luck using chatgpt to translate some crufty old bash deploy scripts to python

guappa|1 year ago

> Using python and constraining yourself to only use a basic subset of the standard library modules

Used to be a viable strategy until they started to drop modules from the standard library at every single release.

yawpitch|1 year ago

> Used to be a viable strategy until they started to drop modules from the standard library at every single release.

That’s a bit of a ridiculous statement, there’s a small number of very-long deprecated modules removed in 3.12, and some more recently deprecated modules in 3.13. And these things are old, largely or completely unmaintained, and usually complete obsolete.

I’d be surprised if anyone has a script that’s been adversely effected by this, and if they did it’s because they stopped maintaining it years ago (and also chose to both silence warnings and upgrade interpreter versions without reading the release notes).

isbvhodnvemrwvn|1 year ago

I would agree if python dependency management wasn't a dumpster fire.

rendaw|1 year ago

I think the point GP was making was that you restrict yourself to only the bundled standard library, which covers most of the basics needed for scripting.

qz_kb|1 year ago

This is why you force yourself to use nearly zero dependencies. The standard library sys, os, subprocess, and argparse modules should be all you need to do all the fancy stuff you might try with bash, and have extremely high compatibility with any python3.x install.

guappa|1 year ago

And it's a dumpster fire because they refuse to make any decision and decide which is the supported way.

Instead they removed distutils, so now there is no way to install any module without using a 3rd party installer.