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?
Qualification: I am a certified moron, I used nano as my IDE for 8 years because I did not know about VS code. I still structure my python like the qbasic I learned in school. I have never mastered object oriented thinking.
Write your scrips one chunk at a time, make them modular, make intermediate scripts if you have to, and have each part output a data structure that you nail down early in the project. Having a ass-load of little parts chained together means you can tweak or entirely replace tools at a later date without fucking the whole process.
If your project is a monolithic do-all be-all monster it means even the tiniest change involves reevaluating your entire codebase. You’re giving yourself all the problems of cuckcoding with none of the time savings.
Many commenters assume I propose do-all be-all monsters. Looks like I failed to explain my idea of custom-made programs for specific use-cases.
The alternative to do-one-thing is do-lots-of-things.
You describe a need for all-singing, all-dancing solutions over single use tools.
You know there are colors beyond black and white? There’s a spectrum of alternatives.
I’m arguing for a little more singing and a little more dancing well-integrated solutions. Like the
-deleteparameter to thefindtool is the step in the right direction. Or do you think that this parameter is superfluous and good oldrmis perfectly fine?You’re gonna think I’m a asshole but, chaining find and rm seems like the best way because you get to keep all the options of rm instead of having only the less flexible option of -deleting every match.
Have you considered the reasons this option was added despite this seemingly obvious fact?
For the single case where a user wants to find then delete a bunch of files, the --delete flag makes sense, but having the function of find overlap with the function of rm adds complexity to the codebase of find without matching the feature set of find + rm.
Remember how I was saying that good integration is difficult? Well, if you just “naively” integrate with
rmthen you get issues like “too many parameters passed to rm” or “there is a vulnerability if you manipulate filesystem while find is still running”. These are among the reasons a well-integrated-deleteexists, as “impure” and “complex” as it is.man find tells me that you should be using the -exec flag should be used if you want to do some operation on the files you find one at a time, using man to learn about a tool before you use it is also the Unix Way. (It also mentions the --delete flag as well as the gotchas that come along with using it).
I will agree that for some complicated tasks that a lot of users might want to do a lot of times, for example downloading videos from YouTube, all encompassing tools are are good idea. yt-dlp has hundreds of functions to cover all the things a user might want to do, but even it relies on outside tools like ffmpeg to get the job done.
Hey get a load of this guy says he can’t “code” but then lays out (actual) practical advice for coding.
My github account is a warcrime, everything I know I have learned from running Debian, reading wiki’s, and stealing code from stack overflow.
Yeah, that’s how you learn tho. I think all of us have just done that and you can get pretty good with just that. And that pipeline of functions thinking