From: Florian Zimmermann Subject: Re: [patch] support no-path in find utility To: Ingo Schwarze Cc: tech@openbsd.org Date: Sun, 19 May 2024 22:49:06 +0200 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