grep “thing I want” !$

This is a trick I’ve used lots when wanting to perform a non-piping operation on a command I’ve ‘cat’ed (eg ‘rm -v !$’)

I’d never criticise anyone for “useless” use of ‘cat’ though. If the fork() overhead was really that critical then it wouldn’t be a shell command to begin with.

    $ cat file
    $ grep stuff alt-.

    $ < file

    $ ${READNULLCMD:-more} < file

    $ < file

    $ < file grep stuff

https://zsh.sourceforge.io/Doc/Release/Redirection.html#Redi...

    cat log | not spam1 | not spam2 | not 'spam(3|4)' | .... | less

UUoC criticism, to me, belongs when one sits down to script.

cat “filename.txt”

Up | grep “thing”

Up | grep -v “not thing”

Up | grep -v “other thing”

Etc. it’s just easier to build this way even if the initial cat is unnecessary.

> grep “thing I want” filename.txt.

…every time

  < file.txt grep pattern

"useless use of cat" goes into the latter bucket. Complaining at me about it does not actually improve the code; it's just a nag about a bad habit that, arguably, isn't even a bad habit.

Or just use `cat` and let the pipe separate the different steps. "< access.log head" is nice but it breaks this representation where each step is piped into the next one. Sure, once you’re done fiddling you can rewrite the thing to remove the "cat", but when you are constructing the thing I find it clearer to use cat.

Uh... I dunno, but my lizard brain thinks that the whole idea of mediating filesystem operations on storage and IPC mechanisms like pipes is a lot more complicated, magic, and deserving of a single command than merely filtering the data on stdin.

I agree with the article and the logic, and think this historic meme was basically wrong originally. You string up your chain of pipelines with the first element being "where does it come from?" and not merely whatever the first operation happens to be just because that operation allows for some kind of file input or redirection syntactically.

This is one of those things where I think it is until it isn't.

I sometimes second-guess myself when I think I might be over-single-responsibilifying. "Well in practice these two things are so trivial that this feels a little silly."

It often turns out to have been a good call in hindsight, especially when working with other people who aren't necessarily thinking about these things at all. If the responsibilities have been sufficiently split up, they're more likely to change only the part that needed to be changed, and less likely to complectify the two things together that really shouldn't've been. Or when I go "oh wow that thing that I thought I overly-abstracted sure composes well with this unexpected new thing!"

Hardcore separation of concerns is just another method of defensive programming.

> < access.log head -500 etc etc etc

It's too bad that the syntax is so different. Why does the first stage not end with "|"? There's space for shell syntax improvements, here. Maybe a 'cat'-like builtin that translates `cat foo | bar` into `bar <foo` so you can have the nice syntax but don't needlessly create processes would leave everyone happy.

Do you have a source for that? I thought it was just POSIX built-in for true. Like `.` vs. `source`. What's a label in this context anyway?

Nope. Unix shell doesn't have labels (are you mixing with DOS batch files?).

: is a shell builtin that does nothing. In the bash man page, look for the first entry of the "SHELL BUILTIN COMMANDS" section. https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh...

  for(;;){
      // loop body here
  }

  < infile  x | y | z > outfile

    </proc/0/environ xargs -0

Or to grab just a few lines for my later reference:

    kubectl get po/my-pod -o yaml | less
    /* find the lines I'm interest in */
    -N
    |^sed -n 34,35p

[1] https://evalapply.org/posts/shell-aint-a-bad-place-to-fp-par...

    dostuff () { 
        if [[ $1 = clean ]]; then 
            grep -v dirt
        else 
            cat
        fi | do_other_stuff
    }

   < x Y | Z > w