is there the need for a blog post saying a command has a specific usage given how the unix philosophy is exactly to have many composable specialised commands ?
The actual post is fantastic though. There are a million posts that give a one sentence description of the common unix utilities, but very few that actually give examples of when they are the most useful.
You are not a Unix user. You don't know Unix's commands and their common options. If the article is aimed at you and people like you that read your scripts then it's fine but it's akin to commenting "dir /w" in a DOS batch file to explain its purpose. Unix users should not following the article's advice, they should be embracing Unix's style and ethos; it's part of what's made it such a success.
BTW, a month of using Unix should have a Unix user knowing what ls's -t and -r flags do, along with -a and -l they're some of its most commonly used.
Adding that to the blog post would strengthen the argument.
We shouldn't assume the knowledge level of the reader.
Examples become production all the time.
Using files with unix philosophy is a tried and tested way to be really productive.
I think you may have focused in on the tangential sentence rather than the point about it being a conceptual overview with Unix commands being used as a metaphor, i.e., not a literal example.
E.g., they’re not typing `echo` commands in the same way that they’re not typing `gpg "make-key"` (which is not a real command).
Excellent! I think I know Unix pretty well, but it would be great if someone had a directory of common use scenarios that one could look through, rather than using Google and wading through horrible forum posts...
Thanks! I really appreciate your straw man and shameless baiting, but my point was made. To be perfectly clear, if I can dumb it down a bit, though the observation is correct and maybe even mildly interesting, maybe it is even a unique observation no one else has noticed, it is, regardless, not a valid criticism in the same way it is not a valid criticism of garage tools that cars are not made out of them. So criticizing UNIX commands because no major applications are made out of them is, if not wrong-headed, then it is barking up the wrong tree, because, at least my understanding is, major applications are developed with programming language. I suspect there are a myriad of programs that fail to rise to the level to be classified major applications that are basically ugly and slow and strung-together UNIX commands, so it can be done, if desired, just as I expect one could build a vehicle out of garage tools if one had the drive to do so rather than use the appropriate materials. So there is perhaps some question begging in your observation in the hidden and incorrect assumption "UNIX tools are intended to be used as elements of major applications, that's what they're for" so that you may criticize in the precise way that you did. There are plenty of valid criticism of UNIX tools, but yours is not one of them. Though, it seems obvious, you have an keen and interesting mind possibly with a touch of the inability to be disagreed with, nor can tolerate criticism of your observations. Maybe I'm wrong, it just seemed that way just then.
This kind of article is good to keep bubbling up over time, to educate new users in best practices. Not everyone is a 20-year unix admin that's seen a bit of everything.
I agree that over use of a phrase can dilute a message but I think you're not acknowledging something important.
The phrase "Unix Philosophy" is a concrete, functioning example of compositionality.
Git is a pretty heavyweight tool and many of its commands are not compositional or built up from many smaller functional units. Git repos also do not compose, which is a significant flaw.
I don't know if unix is the most ahem "specific" specification ever given. What specification of unix do you think the author was referring to? In any case, they have corrected themselves in the blogpost.
I think gp is not ragging on the blog's author for being a novice at Unix systems internals but lamenting the " I looked into this but then it all seemed so complicated so I stopped" attitude that is present in this as well as the sibling posts on sudo and ls. I would much prefer to read three posts delving deeper into the inner workings of any one of these commands than the existing three muddled surface level treatments.
I cannot see how this article is defending UNIX only by talking about a
single utility. It could be a better "defense" if it mentioned, for
example, the power of being able to compositionally combine various
commands through pipes, each of which doing one thing well. Inputs and
outputs, remember?
The post the author is responding to is uninformed, and seems rather
like a rant. DOS vs UNIX comparison does not work. I couldn't know how
to take the `apt-get` example seriously. Because you could easily fix
something like `alias ai='sudo apt-get install'` to achieve `ai
something` magic with something as simple as aliases, which DOS does not
even provide.
For some things, yes. For ad-hoc stuff, composability is amazing. Once in awhile I need to use a wrench to fix my car, and I have a whole array of wrenches to accommodate most needs I have with that car. I would never drive the car with a wrench still in place holding something together, and that's what the Unix philosophy promotes: take all these small tools which each do their thing and create some larger "grander-purpose" software with them.
That works if you need to do a one-time (or at least infrequent) analysis of some raw text, but I have learned over and over to not rely on the passing of plain text between programs for anything that you need to work later on. Something always changes which breaks it. Always. Maybe not for a year, but some update happens which subtly changes the output of a command which breaks stuff down the line.
With typed data checking and compiled applications (the opposite of passing untyped text between individual tools) I can easily account for errors before they happen, and rely on tests which exercise these things, and gain significant performance improvements over piped single-purpose tools, in less time overall.
I was going to comment on exactly this article except that I couldn't find it quickly. It isn't weirdly relevant; it's totally relevant. It demonstrates that, with sufficient knowledge of the command line, one can write the most amazing tools, quickly and succinctly. Here, knowledge doesn't necessarily meaning knowing everything immediately but also knowing what resources to reference to find out stuff.
I've been programming for 40 years and using unix/linux since the 80's and in this little one-line script, I discovered two things that one can do with the appropriate arguments that I've never known. YMMV.
reply