[Toybox] find(1) -name vs -wholename

[enh]

On Mon, Mar 4, 2024 at 3:31 PM Rob Landley <rob at landley.net> wrote:
>
> On 3/4/24 12:19, enh via Toybox wrote:
> > obviously the patch is trivial, but i can't think of an existing
> > toybox tool that has one of these "you're holding it wrong" errors,
> > but this is one that i do find useful:
>
> I thought there was one in tar but couldn't find it. Gzip has "need -f to read TTY".
>
> I'm not conceptually against "this CAN'T work" errors. (Except this isn't an
> error, it prints to stderr and then exits with 0. Seems a bit indecisive...)

/facepalm

(probably no-one noticed yet because it's most likely to be hit
interactively. still seems like a bug though!)

> Alas my find.c is dirty because of the whole pending environment measuring mess:
>
> -  TT.max_bytes = sysconf(_SC_ARG_MAX) - environ_bytes();
> +  TT.max_bytes = child_env_free(0);
>
> Yet another open can of worms where I need to do heavy lifting to close a tab...
>
> > ~/aosp-main-with-phones/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.17-4.8$
> > find . -name bits/syscall.h
> > find: warning: ‘-name’ matches against basenames only, but the given
> > pattern contains a directory separator (‘/’), thus the expression will
> > evaluate to false all the time.  Did you mean ‘-wholename’?
>
> Code change is easy enough, something like:
>
>   dprintf(2, "%s: -name can't match paths, try -wholename\n", toys.which->name);
>
> > (of course, it's also a bit like the macOS `grep -r` "hey, i'm just
> > going to sit here doing nothing because -r defaults to stdin rather
> > than the `.` that you obviously intended"
>
> Which debian fixed ages ago. :)

it was probably debian that caused me to get out of the habit of
typing the `.` :-)

> > where i'm left wondering why
> > it can't just do the right thing... since `/` is illegal in a POSIX
> > name, what other interpretation could there be? but, still, better
> > than nothing.)
>
> I'd be happy to do the right thing instead? Fairly minor code change either way.

yeah, i'm not sure why coreutils doesn't do that --- perhaps to avoid
the question of whether `-name bits/syscall.h` means `-wholename
.*bits/sycalls.h` or `-wholename .*/bits/syscall.h`?

(`-path` with a trailing `/` is a similarly unhelpful sharp corner.)

> We could even ping the coreutils guys about that, since they recently agreed to
> add -x when I grumped at them. (I'm moving house! It's very stressful!) Speaking
> of, I just remembered to ping busybox list about that... Alas, still no cut -DF
> in coreutils, last I checked...

tbh, since starting to read the coreutils list i'm _less_ convinced
that anyone really thinks about anything, and especially not about
interactions between things. (i saw the -x,--swap thread but didn't
have the energy to point out the -x,--exchange would have been quite a
bit less unclear...)

> Rob