"A collection of pure bash alternatives to external processes."

It is a neat academic exercise to find these but I think that's sort of the point - why?

If you're building something that multiple folks will be reading and using just call out to external processes and make it easier to follow what's going on. It's neat to know how to do these things, but they're honestly a bit of a security hole because a large portion of folks using them will never comprehend the why and how and just assume it's doing the proper what.

Why? No external dependencies, your code can run anywhere you have a Bash shell. This also means a smaller attack surface.

Also readability: While some of the examples may be somewhat confusing to someone who doesn't have a lot of Bash experience, to someone who does it can be a lot more readable then feeding a string in yet another language to an external program and processing the output..

Sed exists everywhere for a reasonably complete definition of everywhere - if it doesn't exist then you probably don't have access to Bash (and definitely not a fully featured one)

I have managed networks with 1000+ (microwave link) network devices that had Bash but no sed.. Sure was nice to be able to script maintenance on those..

Your definition of "reasonably complete" might not work for everyone else's use case.

Other people mention constrained environments, but tight loops are also a thing. If you know bash's parameter expansion well, it can make it really easy to write a one-liners that speedily process large amounts of output. Setting up and tearing down a whole process (e.g. sed) can cause an order of magnitude slow down, which is significant if you just want something quick and dirty.

I feel like... maybe? But quick or dirty should be enough - you could also build a python interpreter once to map over the data and then maybe write up some tests to confirm the functionality.

Every explanation of why to use bash here seems like it's got a whole lot of constraints on when it's a good to use - I've finished some tasks just in bash scripts but when I'm writing something for anything other than one time passes it seems like more of a maintenance liability than anything else.

Meh. Choose your poison. As the trope goes, "No language is good at everything." Python is verbose compared to bash for many tasks, and the reverse is true as well.

IMHO, spending the time to actually learn some bash can really improve one's CLI life. Bashing on bash seems mostly like a tired ol' trope, "If it's in bash, it's bad."

The author of the original article really has written some pretty shell code!

Useful in small embedded. Add twelve lines to a boot script, or bring in several new executables into /bin?

There are resource constraints even in large-ish embedded. Your main file system may live in a decent amount of flash space, but when the kernel is booting, it uses a tiny file system in RAM, which is pulled out of an initramfs image. There is a shell there with scripts.

The partition for storing the kernel image (with initramfs, device tree blobs and whatever else) might be pretty tight.

However, because a lot of these snippets depend on Bash extensions, they preclude the use of a smaller, lighter shell.

Wouldn't a compiled binary be smaller and faster than an interpreted language? Assuming stdlib is already loaded.

Problem: we're using trim_string in an initramfs image. Now we need Python3 in initramfs. Oops, kernel doesn't fit into the ARM board's flash partition any more ...

lmao @ spinning up a python interpreter just to perform a trivial string operation

The problem is the direct logical implication of the hyperbolic statement "X is not human-readable" is that only non-humans can read X. Which is rude.