Re: Inconsistent behavior of core utilities

[Mike Jonkmans]

On Tue, Aug 23, 2022 at 09:50:20AM +0900, Dominique Martinet wrote:
> Dave Close wrote on Mon, Aug 22, 2022 at 03:01:11PM -0700:
> >   $ grep CALL ./* | wc
> >   16325   61444  950870
> >   $ grep CALL $( ls ./* ) | wc
> >   16375   61601  953451
> > 
> > So I almost have a solution. Except the extra 50 lines found in the
> > second command are disturbing. Thus far, it appears that those lines
> > are duplicates and some of the duplicated lines are from files with
> > names that do not contain any special characters.
> 
> That is because this is not correct either.
> Just don't use ls for thing, `find -print0` is just about the only thing
> that can handle arbitrary filenames (well, direct shell expansions also
> mostly work with care; but I'll assume your example is oversimplified
> otherwise you wouldn't be trying to use ls... right?)
> 
... 

The output of ls is not guaranteed to be stable.
Moreover, there will be problems when files contain spaces.

> As for quoting:
...

The shell does expansions, like $(...) and after that, it does 'Quote Removal'.
A quote(!) from the manpage of bash:
   Quote Removal
     After the preceding expansions, all unquoted occurrences of the
         characters \, ', and " that did not result from one of the
         above expansions are removed.

> Anyway, here's an example for find -print0:
> 
> $ find . -type f -print0 | xargs -0 grep a --
> ./one one:a
> ./one:a
> 
> --
> Dominique

find is the path to go.

-- 
Regards, Mike Jonkmans