I used to have a report who had a similar train of thought, and ended up writing shell scripts in python which was way more fragile, unreadable and more complicated.
The edge cases are there, but you don’t run into them all that often. Or if you do, you fix your scripts. Take the cp —- 2nd example. You generally don’t start file names with a -. It just makes Unix life annoying so you get pushed away from doing it.
Keep scripts sane and straight forward, you can do really nice and powerful work knowing Unix tools. You can also shoot yourself in the foot some day when you create a file called ‘-rf’.
I wouldn't send a navy seal into battle without one, but it isn't an absolutely critical piece of gear.
I haven’t found Bash to be much better in practice. You can’t really do much with Bash alone, it’s only as useful as the tools you use it with, the ones you install with your OS package manager. And Bash versions themselves can vary dramatically. Try writing non-trivial Bash scripts that are portable between macOS and Linux...it’s a nightmare.
(Yes I know there are libs for python that can do this, but in general Go is just simpler: it has everything I need for writing utilities out of the box, including way simpler package management, and I can come back 2 years later to some code I wrote and jump back into it with no effort.)
Can you read the Go source code from a Go binary? Is the algorithm transparent to the user?
How do you jump back to work on a binary? You have to keep the source code somewhere else (probably in a repo somewhere); now you have an application instead of a script.
You should be doing that for scripts as well! Far too often I've seen problems arise when a team depends on a process but its just a shell script run by cron from the home directory of the guy who's on vacation.
You could also do `go run main.go` if you want to be close to the source. The Gitlab Runner repo has a "script" run like that[1].
[1] https://gitlab.com/gitlab-org/gitlab-runner/-/blob/master/Ma...
This is like half the point for me. It's that I have lots of cli tools I like to use, and many of them are very unix-philosophy like. I want to cobble them together to accomplish a task, and since they already work with shell and pipes etc, it's trivial.
Now in an alternative, I have to go find some library that does the equivalent, or write my own version of the functions, etc, and lots of times those libraries have the thier own sets of pitfalls. I like bash because it encourages sticking the unix philsophy of do one thing and do it well (because you are just using it as a glue, not as a material itself). (also sometimes I just want something thats easy to read and understand)
For all those who bash bash as so horrible, unstable, non-prod.... bash scripts aren't perfect, and nobody who uses bash would say so, but bash runs on millions of prod systems across the world and things are fine... so maybe whats needed is a bit less holier-than-thou attitude from those people and bit more "you do you".
I'm not bashing Bash, I use Bash all the time and it's enormously useful. But it has limitations and tradeoffs that make me reach for other things more often.
Still can, if you want it to. I'll admit my perl chops have rusted clean away.
But it used to be something you could rely on having, and never had the dependency hell problem that's plagued python, for whatever reason.
Also never went through the 2-to-3 transition tsuris, instead opting to make its sequel the Duke Nukem Forever of programming languages.
I will admit Python doesn't have great, simple primitives for shell-like tasks but you can create a few functions to make a simple sh("") wrapper.
With Ruby's backtick execution syntax you can blend in shell/system utilities pretty easily. Unfortunately, Ruby isn't installed on as many systems by default, afaik
Here's a Ruby equivalent of looping through mp3 files in the current directory
```
Dir["*.mp3"].each do |file|
puts file # print the file name
```
Bash has all kinds of pitfalls and things like checking if a file exists vs if it’s larger than 0 bytes.
Then you get people who instead use php to do scripts. Ugh.
I like objects and performance and abstraction and other things about other languages but bash has a _lot_ of parsing tools.
Bash does actually have a fair amount of regex support built in too though it's not as well talked about.
Mine remains: that shell affords capabilities via utilities. Awk (again, with numerous implementations) also offers regex capabilities, some not offerred by sed, and missing a few.
When writing cross-platform scripting, adhering to common standards rises in importance. This is possible, if occasionally limiting.
* ergonomic integration with the shell
* easy piping
* easy input/output redirection
Maybe Ruby comes close with the backticks or `system` but it still isn't as nice as a shell IMHO
Perl is influenced by shell scripting and there are several easy ways to run commands, build pipes, redirect and other things shells are good at, like testing and listing files.
And as ugly as Perl looks, it has much less pitfalls than shell scripts.
The thing is, Perl won't help you with discipline. If you want write-only code, Perl will compile it, no problem.
For that reason, it is the language of choice for one liners and throwaway scripts (and that's how I use it most or the times). But writing clean Perl is perfectly doable, though I usually prefer static languages if maintainable code is a priority (no Perl, no shell, not even Python).
It’s usually not worth the effort to shove everything into a real programming language but write a few self-contained commands designed to be called from a shell and then use the shell as the glue.