Honestly, I don't think I found a single case where this was true. Every time I try to rewrite a moderately complex bash script in Python it becomes hundreds or thousands of lines of code dealing with calling external binaries, streams and proper error handling. Perhaps if you're only dealing with text processing it will work, but the moment you start piping together external programs via Python it's all pointless.
Glad I'm not the only one. Honestly, whenever bash comes up in any context, 10 different people feel compelled to express this whole replace all bash scripts with python sentiment and I just have no clue what the fuck they're talking about.
I would consider myself an expert or at least near-expert in python, but I don't see opportunities to replace my shell scripts with python popping up left and right. Do you open files manually and set up pipe chains with subprocess.Popen? I've done this, and its generally many more LOC compared to the shell original, and harder to read.
On the other hand, I'd consider myself maybe 7/10 skill level with bash, but most developers are only ever a 2/10 or 3/10 with bash/shell. I can't help but think that the average developer's lack of shell understanding is where all these suggestions to convert to python come from. If it's that easy or beneficial to convert to python, then it probably should have been written in python originally.
I think when you have a very-well-written bash script, it starts to get pretty close to python in size, but python wins in readability. A well written bash script will handle errors cleanly, will not die on quoting problems, and can use complex data structures or objects when data handling gets hairy.
When you use regexes, letting python use them directly seems to be much cleaner than quoting and passing them to awk/sed/grep or other text processing tools.
Additionally, python seems to have libraries to handle all kinds of input like json and csv.
One thing that python doesn't do as naturally as bash is invoke commands. For python I usually include some functions to run commands passed as a list, and check the return code or return the output. then 'cmd -f $arg1' becomes myrun('cmd','-f', arg1)
100% agree. There are some libraries like https://amoffat.github.io/sh/ that aim to make that easier, but they always have some quirks that, funnily enough, are often the corner cases you were hitting in your complicated Bash script in the first place.
Yeah, I figure if a bash script goes over ~10-20 lines, or involves really long lines, or quotes within quotes within quotes of different kinds, it's time to move on to Python or similar.
When I'm working on/writing complex bash scripts, it's because the scripts have to run on a variety of different customer machines where Python is not consistently available (let alone being able to count on a particular version) and, if it's not there, cannot be installed.
The main advantage of bash is that it exists on just about every unix machine.
TypeScript is now tenable for bash scripts with the fast-starting Bun runtime https://bun.sh/.
Before Bun, Node+V8 was just too slow to start.
IMHO all scripts should be written in TypeScript...you get typechecking and all the rest of the editing experience. Plus things like Wallaby.js for live coding/testing.
My `.bashrc` now just runs a TypeScript script with Bun. Allows you to use proper structure instead of brittle spaghetti stuff. The number of times I'm debugging silly PATH stuff was too much...
>you get typechecking and all the rest of the editing experience
This is true for a number of languages that can also be run without AOT compilation (Go, Rust, etc). This feels like some really weird, incoherent astroturf take for Bun promotion.
Fair - I find that every time a Python program becomes sufficiently complex though (defined as "needs something not in the stdlib of Python 3.6"), I end up rewriting them in Go or Rust ;-)
vultour|2 years ago
epr|2 years ago
I would consider myself an expert or at least near-expert in python, but I don't see opportunities to replace my shell scripts with python popping up left and right. Do you open files manually and set up pipe chains with subprocess.Popen? I've done this, and its generally many more LOC compared to the shell original, and harder to read.
On the other hand, I'd consider myself maybe 7/10 skill level with bash, but most developers are only ever a 2/10 or 3/10 with bash/shell. I can't help but think that the average developer's lack of shell understanding is where all these suggestions to convert to python come from. If it's that easy or beneficial to convert to python, then it probably should have been written in python originally.
m463|2 years ago
When you use regexes, letting python use them directly seems to be much cleaner than quoting and passing them to awk/sed/grep or other text processing tools.
Additionally, python seems to have libraries to handle all kinds of input like json and csv.
One thing that python doesn't do as naturally as bash is invoke commands. For python I usually include some functions to run commands passed as a list, and check the return code or return the output. then 'cmd -f $arg1' becomes myrun('cmd','-f', arg1)
iamjackg|2 years ago
iudqnolq|2 years ago
ff317|2 years ago
3np|2 years ago
JohnFen|2 years ago
The main advantage of bash is that it exists on just about every unix machine.
unknown|2 years ago
[deleted]
vaughan|2 years ago
Before Bun, Node+V8 was just too slow to start.
IMHO all scripts should be written in TypeScript...you get typechecking and all the rest of the editing experience. Plus things like Wallaby.js for live coding/testing.
My `.bashrc` now just runs a TypeScript script with Bun. Allows you to use proper structure instead of brittle spaghetti stuff. The number of times I'm debugging silly PATH stuff was too much...
ryapric|2 years ago
This is true for a number of languages that can also be run without AOT compilation (Go, Rust, etc). This feels like some really weird, incoherent astroturf take for Bun promotion.
c0wb0yc0d3r|2 years ago
jen20|2 years ago
Cheeeetah|2 years ago
m463|2 years ago
captnswing|2 years ago