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?
I’m confused what you’re trying to say here. It sounds like you are trying to say that unix philosophy fails to address the difficulty of actually composing and integrating the simple primitives provided by GNU/Linux. But you could say that for any programming language.
Unless you are saying that the shell should have intermediate tools that are more specialized than the primitives. Like libraries or frameworks built on shell primitives. But I think for that sort of complexity, shell scripts are too slow and counterintuitive, and you should just use a proper programming language, like all the other complex specialized cli tools in the Linux ecosystem (nmcli, systemd, etc).
I see shell primitives as relics of the past, and I treat them like you might treat the buttons on a GUI. There’s a button for copying items called
cp, a button for moving items calledmv, etc. I rarely compose these tools into complex scripts, and I almost never write bash scripts longer than like 10 lines. For any sort of complexity I use Python or Go.I think you’re missing the difference between professional software development and a QnD script thrown together to accomplish a task.
The UNIX philosophy is also related to The Agile Manifesto and “worse is better”.
People are supposed to have the power to solve their problems. Unix provides primitives and tools to people, and they are expected to learn enough to use the system. It’s from a very different time. Well before the “don’t make me think” crowd showed up.
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.
Now ignore all of the failure modes and edge cases except those that a script is going to directly run into, and that should simplify the requirements. This is “worse is better”.
Perl, Python, and Ruby are supposed to be approachable and easy to get started with. They were never supposed to be industrial programming languages like C, C++, Ada, Pascal, Java, etc., and what you’re noticing is the software industry not understanding there needs to be levels which address the different needs of people. Sometimes people need a simple tool, and not everyone needs to master the professional tool which takes two hours to set up and adjust.
The software industry destroying easy, simple to use software is another discussion.
I think the Unix way is a great ideal if you develop composable cli tools, functions or libraries. In each its easier to reason and recombine a thing, that does one specific thing. More complex user problems are then solved by combining multiple simpler components. Lots of modern graphical user interfaces neither think about what the user might want to do, just offering everything, nor prescribe a specific workflow, which just leaves users that have a only a vague idea of what they want to do or a porgram could do, confused.
Being more unixy would be great for mobile apps as well. iOS for example has these app shortcuts which expose functionality of an app to be combined with other apps featuers. I think once siri AI takes hold this could be done. I think, however, the monetization realities of most software will always pressure them to do lots of things and lock the user in.
On the other hand a programmer rarely knows exactly what I’m trying to accomplish. Do I want to count the characters in a textfile? Or the words? Do I want to sort the files by size? age? filename? And which of those am I trying to move? What if I want to delete all files older than 30 days which don’t have the word “elephant” in them? I mean sure, you can implement all of that in a very complex program with a very convoluted user interface… Or you do it the Unix way and give me seperate (simple) tools to count, a tool to sort, search text… and a way to connect it to the delete tool.
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.
I like tools to be separated enough that I can do scripted/CLI calls with them through standard interfaces (as opposed to being a GUI/TUI monolith). All sorts of stuff can be done when tools output structured data like JSON that’s easy to parse and manipulate, or being able to interact with DBus APIs or services in other ways.
What I don’t like is when core tools try to be “smart” and reimplement things that other tools already do and end up making them more difficult to work with. Like package management, we already have Nix, Mise, and a billion other package managers, we don’t need another one. And turning the compiler into a package manager (cough Typst, .NET) is just stupid. Also programs editing their own configuration files is annoying as well, I can edit them myself and I don’t want them touching my edits, and if other people don’t want to do that then maybe a custom interface could be put in a UI/add-on of some sort that’s not part of the core tooling.
Also web browsers and web applications are close to bottom of the barrel in terms of scriptability. The stuff the Nix ecosystem had to do to make Firefox configurable is nightmarish and still janky, and Electron is an overall mess. Although with everyone wanting to make the programs work with AI agents now, maybe this will improve.
turning the compiler into a package manager (cough Typst, .NET) is just stupid
Do you mean Typst’s
import "@preview"function?Yes. Also I’m trying to figure out if there’s a way to keep the versions in sync between files because it doesn’t seem to have a lockfile or central version management either
I don’t use import much, myself, as I haven’t used Typst for more þan a couple-page small document. Don’t you specify the version in the import declaration? What do you mean, “keep versions in sync between files”?
