I'm actually pretty much against UUoC. The cat example is much more resilient to modification. For instance, there are usually natural modifications considering filtering etc.
Anyway, since he said number we probably want `nl` not `wc`.
Separating pipe-setup from processing is sound engineering to me and makes things much easier. For instance as I iterate, I will have cat piped to head piped to filter but eventually I'll take the head out and run the whole thing. That's a trivial ^W versus moving around arguments and worrying about arg order, etc.
I am confused. What's wrong with `wc -l < file | ... | ...`?
I know `< file wc -l | ... | ...` is identical because the redirection is done before the command is executed, but what does putting it in front help with?
Because I feel the other answers, though correct, are entirely missing out on clarity:
The first iteration looks like this:
<file head -n10 | grep foo | tr baz qux
The second iteration looks like this:
<file gzcat | head -n10 | grep foo | tr baz qux
It makes the change much easier, since the first thing written is the first thing that happens. In `gzcat < file`, the logical first step - reading and streaming file - is now the physical second step. Like a German sentence, whenever you want to prepend the file, you have to maintain an item in second position.
In this particular case, people (like me) would wonder, "what's the point" and then go searching for the details of how `cat` and `wc` work, assuming that there's might be a reason the original developer wrote this code, as opposed to the simpler `wc -l` (i.e. Chesterton's Fence).
People usually use it because piped input is a known interface, you don't have to go digging through a man page or help page to figure out what flag is needed to accept input from a file. "Data flows from left-to-right" is also very intuitive, and you don't need to know the specifics of how your shell interprets a command line to figure out where to put the input redirection in the case of a more complicated shell command.
The point is I personally find it more ergonomic. Just like how I'll take a slightly longer route to avoid turning directly across traffic or avoid a particularly dangerous intersection.
Also, context is really important. Not that people on the internet ever stop to think about what the context is that the person is writing the code in. I don't write bash scripts that run mission critical workloads. I just ad-hoc type stuff into my shell to produce output I need for stuff at the time.
But for me that beats the purpose. You still end up with the complexity. Only now you have to add and manage it yourself in some other way, probably being worse off then when you would have started with all that complexity but integrated in one standardised package (distro).
Imho, the issue is not that the solutions are complex but the problems we (assume we) need to solve are. Just making simple solutions that ignore the bigger problems underneath do not really help in the end.
The purpose can be to make a simple system, not an easy to use one. A simple system can maintain its simplicity by avoiding tackling complex problems - however if you want to tackle those problems yourself then, sure, you'll also need to handle that inherent complexity that the original system decided to avoid. But that is complexity you invite in, not something that the original system had.
That doesn't make the original system any simpler or more complex.
Yeah, I spent a lot of time ensuring the website would load quickly and I do away with a lot of "optional" cruft.
There's no Javascript full stop, no stylesheets (all CSS is embedded in each page) and every page load is a single web request (with the exception of the screenshots page).
Even the SVG logo is embedded in the pages!
Writing it this way also causes each page to be self contained, a download of the HTML page includes all of the CSS, logo and information so it can easily be saved and viewed locally. :)
My main issue with the site is that in my browser i get the mobile version instead of the desktop since i do not use my browser maximized (i have a 1366x768 monitor). Isn't there any other way to figure out if i use a mobile phone instead of using the horizontal resolution?
> The only remark I have regarding code quality is that the word splitting warning is disabled for the entirety of kiss: I would have disabled it on a per-occurence basis.
There are 8 occurrences of word splitting in the source, each and every one is intentional.
I also enable all lint errors when working on the package manager itself (to catch any unintentional word splitting which may slip through my fingers).
The ideal goal is to reduce the word splitting count to zero though! :)
(I'll go ahead and make the change you're suggesting until I do remove all word splitting).
