Hacker News Reader

Comment by hiAndrewQuinn | Hacker News Reader

`cat x | Y | Z` is Subject-Verb-Object.

`Y x | Z` is Verb-Subject-Object.

That's why I prefer using cat "uselessly".

   < x Y | Z > w

Y takes input redirected from x, piped into Z, which outputs into w.

> Y takes input redirected from x, piped into Z, which outputs into w.

I.e.

  x | Z | tee w | Y

? that's... something else entirely.

No, the command is

    < x Y | Z > w

where x and w are files, not commands.

Something that "cat file | ..." advocates might be overlooking is that a redirection ("<inputfile", ">outputfile", "2>errorfile") can appear anywhere within a simple command, so these:

    command -option < file
    < file command -option
    command < file -option

are all exactly the same -- and of course very similar to

    cat file | command -option

If the purpose of typing "cat file | command" is to put the input file at the beginning (which does make logical sense), you can achieve the same thing with "< file command". Admittedly, it does look at bit strange if you're not accustomed to it. (It even works with csh and tcsh.)

So I take it you're also an advocate for this?

  < <(curl http://...) command -option

Because that's what you get if you address the actual argument and still insist on input redirection.

Input redirection is inconsistent with every other command to retrieve data. Not only does it not have the same syntax, it's combining two actions into one step of the pipeline.

Redirection isn't a step in the pipeline; it's syntax which indicates to the shell that it should perform certain file descriptor manipulations when it arranges the pipeline.

I would say that < <(command arg) is a useless use of process substitution (UUoPS). You just want command arg |.

The redirection variant doesn't eliminate command and does not move arg out of command's argument position; it's just superfluous syntax.

Just because we want "< file" instead of "cat file |" doesn't imply that we want "< <(command arg)" instead of "command arg |". It's not even the same rewrite pattern at all.

However, if someone wrote:

  cat <(curl https://example.com/file) | next

then that now the UUoC pattern "cat file |". We can apply the transformation to eliminate cat:

  < <(curl https://example.com/file) next

Now in so doing, we have moved the process substitution such that there is an obvious match for the UUoPS pattern. We apply that rewrite rule as well:

  curl https://example.com/file | next

> Redirection isn't a step in the pipeline

"Get data" is the pipeline step we're talking about. Using "< file" combines it with the first transformation step, instead of keeping it as its own separate step as all other such data sources require.

> Redirection isn't a step in the pipeline

It isn't implementation-wise, but it is semantically. If anything, < is a useless syntax that should never have been in the shell to begin with. If you want to peephole optimize cat... just do that, just like it replaces tons of other commands with built-ins.

< <(...) is precisely what you need when you want to pipe input into a while read loop and mess with variables.

No, that's obviously taking the inner product of the <x| bra and |Z> ket while applying the Y operator, and multiplying by a scalar w

The shell < has never intuitive to me, for some reason, but this has helped me see it in a new light. Thanks!

cat is a verb though

cat x is a subject

"x" is not a subject.

Reply on news.ycombinator.com