Preferences

It's funny how many people fall in love with the Unix philosophy because they enjoy using an OS with a macrokernel that ships with awk, tar, and find, which they operate with useless uses of cat.

Macrokernel or microkernel or a grain of salt, whatever kernel you use does not matter when it comes to seeing the advantages of 'the *nix philosophy'. As to the 'useless uses of cat' these often make the pipe easier to grasp because the first step is always the same:

   cat something|filter step 1|filter step 2|filter step 3
instead of

   filter step 1 something|filter step 2|filter step 3
especially when confronted with filters which need their input to be fed in different ways

   filter step 1 < something
   filter step 1 -i something
   filter something step 1
   cat something|filter step 1
It may be less 'pure' to use cat as the first step in a pipe but who cares?
You can keep the order of things even if you want to avoid using cat:

   < something filter step 1|filter step 2|filter step 3
(just pointing this out in the hope it can be of interest to someone reading the thread, I don't personally care that much about UUOC - "useless" is quite subjective, one can still reasonably find the cat version more readable).
Oh I don't care: I do it all the time when I compose cli commands. But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file?

I think it's a good example of when it's worth straying from the philosophy.

> But is it doing one thing, and doing it well, to use `cat – concatenate and print files` to open a file?

Yes, it 'prints' the file to stdout which is consumed by the pipe and turned into the input for the next command in the pipeline. It doesn't matter whether you're only 'printing' a single file or a bunch of them.

And it numbers empty lines (-b) and non-empty lines (-n) and the end of lines (-E) and elides empty lines (-s) and search-and-replaces tabs (-T) and nonprinting characters (-v)
A kernel is a very special program, and splitting it into individual components would be orthogonal to the Unix philosophy, which is about user space programs. Besides, Linux is quite modular, and only loads what it needs, so the fact that it's monolithic is not a major concern. Yes, it would be better if kernel panics wouldn't impact the system, but nowadays these are very rare, and are usually related to hardware rather than software issues.

As for GNU utils and the examples you mention, those indeed align with the Unix philosophy, which you clearly misunderstand.

Is it clear enough that you could explain why tar has multiple zip options and why find has a DSL? Is it clear enough that you could explain to Rob Pike why he's wrong about cat -v?
> why tar has multiple zip options

Convenience? `tar` integrates well with compression tools, but doesn't implement compression itself. This is the epitome of the Unix philosophy. You can just as well pipe its output to any compression tool of your choice, if you prefer not using its CLI.

> why find has a DSL?

Describing an advanced CLI as a DSL is a stretch. But to humour you: flexibility, and because files have many attributes which a good finding tool should expose to the user. Whether you like its CLI or not is a separate topic, but you're mistaking minimalism for simplicity as a requirement of the Unix philosophy. Some tasks are inherently complex, and forcing a tool to be "minimal" at the expense of flexibility would be counterproductive.

Besides, you're free to choose any other tool you like more to find files on your system. The fact GNU `find` is easily replaceable is precisely a sign that it follows the Unix philosophy well. I personally use `fd` and ripgrep more often than `find` these days.

Re: `cat -v`, I hardly know the history behind it, but it doesn't really matter. As a sibling comment mentions, there are no hard rules around this topic, and people will disagree about what it really means, and how a program should be designed. If I had an opinion on the topic of `cat -v`, I would probably argue with Rob Pike about it as well. None of this means that these design principles are not worth upholding, or that we won't make mistakes along the way. But going back on topic, it's a problem when a project like systemd explicitly chooses not to follow these principles.

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal