Re: Inconsistent behavior of core utilities

[L A Walsh]

On 2022/08/24 10:31, Michael Stone wrote:
> On Wed, Aug 24, 2022 at 10:17:49AM -0700, L A Walsh wrote:
> > On 2022/08/23 00:30, Mike Jonkmans wrote:
> > > > que
> > > find is the path to go.
> > Because find isn't part of coreutils?
>
> there's more to life than coreutils
-----
But the OP was posting about inconsistencies in coreutils.  

What you are saying is because coreutils is broken/inconsistent, use 'find'.  


> > find isn't consistent either:
> >
> > find . -name \*.foo
> >
> > gives you output from dir ".", but you have to edit the output or add 
> > other args to
> > get just the filenames, since there is no easy way to start from the 
> > current directory:
>
> find . -name \*.foo -type f
>
> if you want just the files in the top directory and not subdirectories 
> then
>
> find . -name \*.foo -maxdepth 1 -type f
>
> > find isn't the path to go, as it's internally inconsistent (not to 
> > mention it's not
> > part of coreutils).
>
> It's very consistent, you just have to learn how it works. Why on earth 
> would coreutils reinvent something that does exactly the job you're 
> trying to do?

find isn't consistent.  If you specify '.' as a starting dir, all output is 
prefixed with
'./'

If you leave off the starting dir you still get './' as a prefix instead of a 
null prefix.

Even if you try a null dir as a starting point '', you still can't get your listing without 
'./' prepended.

Only if you run it through 'sed' to trim  the initial './' can you get the 
unadorned filenames.