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

[Rob Landley]

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...)

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. :)

> 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.

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...

Rob