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?

  • Nik282000@lemmy.ca
    1·
    1 day ago

    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.

    The alternative to do-one-thing is do-lots-of-things.

    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.

    You describe a need for all-singing, all-dancing solutions over single use tools.

    • arty@feddit.orgOPEnglish
      1·
      1 day ago

      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 -delete parameter to the find tool is the step in the right direction. Or do you think that this parameter is superfluous and good old rm is perfectly fine?

      • Nik282000@lemmy.ca
        1·
        1 day ago

        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.

        • arty@feddit.orgOPEnglish
          1·
          1 day ago

          Have you considered the reasons this option was added despite this seemingly obvious fact?

          • Nik282000@lemmy.ca
            1·
            1 day ago

            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.

            • arty@feddit.orgOPEnglish
              1·
              14 hours ago

              Remember how I was saying that good integration is difficult? Well, if you just “naively” integrate with rm then 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 -delete exists, as “impure” and “complex” as it is.

              • Nik282000@lemmy.ca
                1·
                10 hours ago

                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.