Can you explain to me why either of these is useful?
I've somehow gotten by never really needing to pipe any commands in the terminal, probably because I mostly do frontend dev and use the term for starting the server and running prodaccess
Pipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on.
Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.
Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.
As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)
It goes beyond what I was able to do with git settings alone. Specifically stripping the headers/padding/decorative and it doees it across all output (or well a lot of it).
wlroots is self-described as "about 60,000 lines of code you were going to write anyway." It's also a moving target and you'll probably have to retool when wlroots updates.
That seems like a huge burden to carry around, considering that a minimal X11 window manager can be a few thousand lines of code and probably still compiles after 15 years.
I think that's actually the biggest real criticism that can reasonably be made about Wayland: they ought to have produced something like wlroots from the start.
Weston was only ever intended to be an example, and its monolithic nature meant that it wasn't particularly useful as a platform on which others could build (and this was even more true early on, before libweston).
As a result, GNOME and KDE both did their own implementations - and from that seed grew a host of complaints about things not working in one or the other, when on xorg they had worked more or less the same. The lack of a common entry point for "plumbing" also hurt, and can probably take much of the blame for the initial pain that many faced when first moving to a wayland-based DE.
But, of course, that's only obvious in retrospect. I don't think it was at all clear at the time those decisions were being made originally - in other words, it was a mistake rather than malice.
That helps, but you still have to - at a bare minimum - wire up all the functionality. My pet example is trying out a new wlroots compositor and discovering that it has no way to change keyboard layout because it doesn't use that code from the library yet.
It's incredible watching people determine that outsourcing their thinking and work to what has been generously described as a junior coworker is a new 'skill'. Words are losing their meaning, on multiple levels.
No sane person would argue Person A is a concreter if Person A is telling Person B to do concreting and Person B does the concreting. Doesn't matter if Person A had elaborate plans for the concrete, or if Person A owns the concrete afterwards. These are long-established ideas. You can twist it and argue "semantics!" all you want but it will never take with anyone but the Person A's.
It's sad to watch the mental gymnastics at play. I guess by asking my mechanic to service my car, I'm a mechanic too? I want it > it gets done > I am the doer. Ridiculous.
