Over the decades I’ve seen the praise and critique of the “Unix way”. I don’t remember reading about the aspect I’ll describe below. This might be a banality, and I haven’t invested much thought into it either. I’m just curious to hear your opinions.
At the core of the Unix way is that tools should do just one thing. Users very often need results that can only be achieved after doing several things. With only single-purpose tools at hand, users have to integrate them. In other words, the tool authors delegate integration to the users.
Here’s the idea I want to discuss. In programming languages, integrating various modules to achieve a goal is already a complex task because we often have to handle numerous failure modes and edge cases. In shell scripts this is much worse, since shells are more limited than programming languages. Writing a tool that does only one thing looks like avoiding the most complicated task. Which leads to a conclusion that the Unix way only works well in a rather small fraction of use cases; the majority of cases are better served by different approaches.
What do you think?
Continuing the train of thought from the post: an approach that might serve you better is not a universal program that does everything. It is rather a custom program that does what you need. It very likely will apply reusable code, but in the form of modules instead of programs. It will be much easier to write well than to write a bash script well.
I mean that’s basically the same thing, just a different user interface. I think from a technical perspective it doesn’t matter a lot whether we write down the commands as text/words and connect them with “|” symbols or whether we pick them from a long list of symbols and arrange them as puzzle pieces or connect them with pipes or arrows drawn with the mouse.
In my experience, programming languages offer more control than just connecting inputs and outputs, and it’s easier to get right
And generally should be more efficient too. Bash and this unix-style tool calling was not designed for efficiency. Which is fine for most use cases, but should be avoided for tools you regular use.
To be more detailed, every time you call a program using bash, your bash program has to fork into two identical processes. Then all that work of forking is wasting as one of the forks then execs to replace itself with the program you called. And that happens with each tool called.
Using other programs, like Python, can more efficiently exec other programs without the same overhead of forking. And for longer running jobs, Python is much more efficient as it converts itself to bytecode, whereas bash is purely interpreted.
The main downside of Python is its longer time to start. So for simpler jobs, bash can be better.
Most computer stuff is tradeoffs anyway. I mean we’re looking at different manifestations of “efficiency” here. On the one hand we’re wasting fractions of a milliseconds here and there. On the other hand this might allow us to execute code in parallel, offer modularization. I can combine wildly different programs from different manufacturers, written in different programming languages. I can install new ones and execute them straight away without reloading my shell…
But I’d argue this doesn’t even matter all that much. We’re talking tiny fractions of a second in most use-cases. The real efficiency is me sitting in front of my computer and saving 10 minutes of time because it’s easy and straightforward to make the computer do the task I want it to do.
I’m not a big fan of BASH. I do use it. But mostly when it makes sense and it’s the right tool. And I keep forgetting how to do if-else-statements, when to use single or double brackets… It occasionally breaks in weird ways and it generally needs a lot of background knowledge to write good bash scripts. Python is designed with a bit of a different use-case in mind. But it can also be used to write quick scripts to sort files, do some admin stuff and automate things. Oftentimes it’s a good and comfortable tool to use.