[Toybox] find and {}

[Rob Landley]

On 2/12/19 3:59 PM, enh via Toybox wrote:
> from the top of find.c:
> 
>  * Not treating two {} as an error, but only using last
> 
> this came up today, specifically that this didn't work the same way
> that GNU find would:

This whole "wait for somebody to complain" approach becomes a bit of a minefield
when you throw the android developer base at it, doesn't it? :)

> $ adb shell 'find /data/local/tmp -type d -exec echo {} {}.suffix \;'
> /data/local/tmp {}.suffix
> 
> but i'm not sure whether that comment in the source is meant to be a
> TODO or an expected deviation for a reason? (so i thought i'd ask
> before i tried to fix it...)

It was "do the simple thing and wait for somebody to complain". I remember the
{} + variant becomes a pain to handle environment size limits for even with one
of them, and posix says:

  If a utility_name or argument string contains the two characters "{}", but not
  just the two characters "{}", it is implementation-defined whether find
  replaces those two characters or uses the string without change.

  If more than one argument containing the two characters "{}" is present, the
  behavior is unspecified.

I vaguely recall other unfinished rough edges in find like supporting "find .
blah{}blah +" which is going to involve xmprintf("%s%s%s", before, file, after)
in a loop, figuring out when we've exceeded environment space size constraints
and backing up to make a line that's just long enough (and handling the case
where _one_ instance doesn't work because environment space is exhausted, and
remember environment variables consume environment space and there's still no
way to MEASURE the kernel's environment space limit which varies by kernel
version, remember that conversation and yes I'm thinking of doing a
portability.c shim querying kernel version at #%*(#&% runtime...)...

And then you've got to free them again because find works on arbitrary input
size (who knows how big the filesystem metadata is) so you can't leak them as
you go but must clean up...

Oh, and what does one{}two{}three mean?

Seriously, half the reason I haven't sat down to try to fluff out the test suite
properly is if I think about it I go through ALL THESE QUESTIONS and my todo
list gets longer. (The other half is the same reason I haven't done more on the
code size: $DAYJOB eats all my energy. Toybox and mkroot and kernel patches and
so on have to fit in the cracks.)

Rob