From: Ingo Schwarze <schwarze@usta.de>
Subject: Re: [patch] support no-path in find utility
To: mindfsck@gmail.com
Cc: tech@openbsd.org
Date: Sun, 12 May 2024 23:54:23 +0200

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