pages*: replace invocations of cat with shell redirection

[jtmr05]

• The page(s) follow the content guidelines.
• The page(s) follow the style guide.
• The PR title conforms to the recommended templates.

In general, there's no need to pipe the output of cat into another command just to operate on the contents of a file. A shell redirection serves that exact purpose and does not include the overhead of spawning a new process. Given the fact that one of the goals of tldr is to ease new users into the world of the command-line, it is best not to instill bad practices on new users.

[CLAassistant]

All committers have signed the CLA.

[Managor]

This was discussed in the past #13668

The ease of reading from left to right is a very strong reason to use cat for new users.

[jtmr05]

Fair point, though I stand by my idea that it is instilling a bad practice.

[Managor]

How significant is spawning a new process? Can you give rough benchmark numbers? I doubt modern computers mind it at all.

[Managor]

Suggested change

	`ajson '{{$..json[?(@.path)]}}' < {{path/to/file.json}}`
	`ajson < {{path/to/file.json}} '{{$..json[?(@.path)]}}'`

While this is not a direct approval of the idea, I have an improvement suggestion: Always have the shell redirection come after the program invocation

[Managor]

Suggested change

	`ajson '{{$..json[?(@.path)]}}' < {{path/to/file.json}}`
	`ajson <{{path/to/file.json}} '{{$..json[?(@.path)]}}'`

Also I wonder if having no space in between makes the example more or less clear to the user viewing the example.

[Managor]

I guess it's not something that can be used universally. ip rule for example has writing to a file and reading from a file on the same spot at the end of the commans which makes it easy to read.

[jtmr05]

Interesting, although placing the redirection before the arguments feels confusing imo.

[Managor]

It don't think it would be confusing. Having the shell redirection point directly at the program has the same effect visually as using cat where pushing data into stdin is the first thing that happens.

[tranzystorekk]

Can you give some examples to illustrate why this is a bad practice? E.g. is it prone to some kind of error or user mistake, does it obscure something that the user should be aware of?

Usually when it's called a bad practice, the only rationale given is vague personal preference or the presumed perf cost of process spawning.

[SethFalco]

A very brief opinion from minimal investigation:

1. I wouldn't describe cat as a "bad practice", but I do see the appeal to relying on syntax/behavior that is a shell built-in rather than an external program. 👍
2. However, not every shell supports shell redirects. For example, cat works in PowerShell, but < does not work. 👎

As most of these are in the common folder, I'd personally stick with cat as it's more portable, especially for Windows users.

[jtmr05]

How significant is spawning a new process? Can you give rough benchmark numbers? I doubt modern computers mind it at all.

Honestly, I wrote a simple a test and the script that used cat was only about ~10% slower than the version using direct shell redirection, which is considerable but far less significant than I anticipated.

A very brief opinion from minimal investigation:

1. I wouldn't describe `cat` as a "bad practice", but I do see the appeal to relying on syntax/behavior that is a shell built-in rather than an external program. 👍

2. However, not every shell supports shell redirects. For example, `cat` works in PowerShell, but `<` does not work. 👎

As most of these are in the common folder, I'd personally stick with cat as it's more portable, especially for Windows users.

I approached this from a Unix perspective, and thus I'm not really well versed on Windows, so I guess that's a fair point. Albeit a bit strange that Powershell supports output redirection and pipes but not input redirection.

[jtmr05]

Can you give some examples to illustrate why this is a bad practice? E.g. is it prone to some kind of error or user mistake, does it obscure something that the user should be aware of?

Usually when it's called a bad practice, the only rationale given is vague personal preference or the presumed perf cost of process spawning.

The performance penalty exists, though perhaps not that significant. But there's also this.

[acuteenvy]

But there's also this.

When you're writing a shell script, I agree that using cat is a bad practice, since it spawns a redundant process and you know that input redirection will always work, since the script will only be executed by the shell you're writing it for. Spawning cat multiple times will be a lot slower than using shell builtins to read files.

However, when you're just using the command-line, it doesn't matter nearly as much. A single use of cat takes just a little bit more than input redirection, but it works everywhere.

[spageektti]

But there's also this.

When you're writing a shell script, I agree that using cat is a bad practice, since it spawns a redundant process and you know that input redirection will always work, since the script will only be executed by the shell you're writing it for. Spawning cat multiple times will be a lot slower than using shell builtins to read files.

However, when you're just using the command-line, it doesn't matter nearly as much. A single use of cat takes just a little bit more than input redirection, but it works everywhere.

I think that we can close this PR then