Hmm, don't try to innovate in BSD, a small patch leading to an only 
"better" behavior is ignored or even wrongly read. I go back to "that 
other" Unix, thanks anyways!


On 13/05/2024 09:53, Florian Zimmermann wrote:
>
> > 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