Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?

[Eric Blake]

On 02/28/2017 11:28 AM, James Youngman wrote:

>> (in the sense that the find command line is a little language with
>>> specified semantics and the user is communicating their wishes by using
>>> that language).  POSIX specifies no semantics for the case where no path
>>> name argument is specified, so the current behaviour is compatible with
>>> POSIX.
>>>
>> ====
>>    POSIX is irrelevant to what users want -- it's what computers want.
>> Forcing users to adjust to what computers want is the opposite of
>> "user friendly".
>>
> 
> POSIX is a way of ensuring that someone's expectations for how programs
> behave (given some input, shell, C, or whatever) are reasonably consistent
> between systems claiming compliance.
> 
> The relevance, here, of POSIX is that find should behave consistently with
> POSIX in order to avoid unwelcome surprises for users and changes from
> previously-compliant behaviours to no-longer-compliant behaviours.   Given
> that the use of "find" without an argument is not specified by POSIX,
> implementations are free to specify what (their version of) find does in
> this case.   GNU has some long-established behaviour for this usage.  I
> don't think the usefulness of that behaviour is at issue here, though, and
> my only point was that GNU find's behaviour for "find" by itself is not
> forbidden by POSIX.

For the record, POSIX leaves 'find' up to the implementation (some
implementations give an error, GNU treats it as 'find .'), but requires
'find ""' to report an error because there is no such file or directory
(the empty path name has to fail with ENOENT).

So while I'm okay with something like:

find --trim-leading-dot

printing 'foo' instead of './foo', (and where you can wrap a function or
alias around it to always turn --trim-leading-dot on for your own
interactive dot), I am NOT okay with:

find ''

magically starting to produce successful output where POSIX requires it
to fail.

> But I've not said that you shouldn't remove the "./"  or that you can't
> have the feature.  You certainly can, you can change the code of GNU find
> any way you like.  I will even try to help you do it, time allowing.   I
> just won't be including this feature in the released version.

And I'm merely adding that such a change should be done via a
command-line option, not an environment variable.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature