Re: 'Cat' feature request

[Kaz Kylheku]

On 2023-12-28 13:24, Bernhard Voelker wrote:
> On 12/26/23 04:53, Kaz Kylheku wrote:
>> The feature is actually implementable. The cat program has a way of
>> determining that it has been passed all the names that may arise
>> from the expansion of *. (Modulo a minor sampling-related race
>> condition.) Namely, it can just call glob("*", ...) and compare
>> the results to its argument vector.
> 
> Besides the race, there's inherently no way to tell if the user specified
> the files explicitly or whether the shell has expanded them by globbing.

I'm not going to defend this very hard, since I regard the entire
concept to be a cockamamie idea, in any incarnation.

However, it's possible to take the requirements-level stance that the
two cases being indistinguishable doesn't matter and is a "feature".

Just like if you want to look for 4, it might actually be
an advantage to recognize it in forms like 1 + 1 + 1 + 1, 2 + 2 or 4.
In a directory where we have . .. .rc foo bar, the expressions *
and foo bar can be regarded as equivalent.

The user has this silly function in their personal environment and
knows about its quirks. The user knows that if for whatever reason they
produce a cat command line which explicitly contains the expansion
of *, the function will reject it in the same way. Thus, in that case,
if that user wants to cat all those files, they have to use
"command cat" or "/usr/bin/cat".

A * glob can be hidden behind other expansions:

  STAR='*'
  cat $STAR

thus, access to the raw syntax will not give you an immediate
answer that * is present; you have to perform expansions on
the command line. But not all the expansions (so you can't
use eval in any shape): you have to stop before the pathname
expansions in order to then look for unexpanded globs.

The whole thing becomes much more of a fool's errand than the
function I wrote. (Which, yet, nobody in their right mind
should use, I underscore.)