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..
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.
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.
munk-a|6 years ago
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.
jascii|6 years ago
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..
xelxebar|6 years ago
kazinator|6 years ago
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.