From: Florian Zimmermann <mindfsck@gmail.com>
Subject: Re: [patch] support no-path in find utility
To: Ingo Schwarze <schwarze@usta.de>
Cc: tech@openbsd.org
Date: Mon, 13 May 2024 09:53:04 +0200

 > with no arguments is undefined. I don't argue with that (or POSIX), 
but undefined could still mean to make it useful nonetheless? I checked 
other systems: Linux, QNX and Android are all functional without an 
argument (like my patch), Windows and OpenBSD bail out with an error. If 
you step back a little: other commands (ls, tree) all behave like "no 
argument means CWD". Thanks for the pointers with the manpage, I'd try 
to improve there, but for now I wait for if there is any open supporter 
at all.

On 12/05/2024 23:54, Ingo Schwarze wrote:
> Hi,
>
> mindfsck wrote on Sun, May 12, 2024 at 01:56:53PM +0200:
>
>> coming from the GNU world I often use find for explorative tasks like this:
>> # find
>> # find | grep -i something
>>
>> I learned the BSD find does not support this,
> It's not just BSD.
> It's POSIX that requires at least one argument:
>
>    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
>
> The meaning of the command
>
>     $ find
>
> with no arguments is undefined.
>
> In general, we do not want extensions to standardized commands
> unless they provide very significant benefits that cannot be reaped
> in any other way.
>
> What's wrong with always typing "find ." when "find ." is what you
> want, instead of typing the undefined "find"?  It is required by the
> standard to work portably, and i just tested with GNU find 4.8.0
> on Debian GNU/Linux that it does indeed work as it should.
>
>> one has to provide a path (or more).
>> The attached patch adds functionality for the above examples.
> The patch does not add any functionality i can see, so i doubt
> that we want it.  The only effect of that patch would be to
> complicate the documentation (in all of the SYNOPSIS, DESCRIPTION,
> and STANDARDS sections).  In particular, the DESCRIPTION would
> have to describe what "find" with no arg does, and STANDARDS
> would have to say that that's an extension to the standard.
>
> That's more text without find(1) becoming able to do more than
> it already does now.
>
> Besides, please do not send patches as attachments, send them in-line,
> but do not resend this one as it's likely to be rejected anyway, unless
> other developers are aware of arguments that i'm currently missing.
>
> Yours,
>    Ingo