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

[James Youngman]

On Sun, Feb 26, 2017 at 7:44 AM, L.A. Walsh <address@hidden> wrote:

>
>
> James Youngman wrote:
>
>> On Mon, Feb 20, 2017 at 7:52 PM, L A Walsh <address@hidden> wrote:
>>
>>
>>
>>> Would it be possible or not unduly difficult to change
>>> 'find' to recognize/allow a null path ("") specifically
>>> to allow find to start at the current directory (much like
>>> not specifying any paths), BUT also suppress the prepending
>>> of "./" at the beginning of every result?
>>>
>>>
>>>
>>
>> The current behaviour is deliberate.  It's intended, among other things,
>> to protect the unwary or
>> inexperienced user against unexpected file names such as "-f".
>>
>>
> ---
>    That wouldn't change.  The user will expect pathnames
> on output, as always.
>
>> I think this is a reasonable precaution even if find supported usage such
>> as find "".
>>
> ---
>    They will have the same protections they currently
> have with the same usage (and by default, when no paths are
> specified).  You don't require the same protections when
> a user prints the path with "%P".


Because, typically, -printf is used for output intended for humans rather
than programs.   Also because the documentation specifies the behaviour of
%P in a way that would make a leading "./" clearly unexpected and contrary
to the documented behaviour.



> If the output is intended to be consumed by other programs then stripping
>> the ./ is not needed (and as I imply above, sometimes dangerous).
>>
> ---
>    I assert that in over 25 years of writing scripts I've never found
> it dangerous.


That's good news.   I have also been lucky enough not to have come across a
case where a shell script I had written had been used in a security exploit
or caused a problem of the kind we're discussing.   As far as I know, at
least.


> In fact, having to edit paths as they come out of
> find is a dangerous step that someone may get wrong.


As far as I can see, it is also unnecessary.   That is I don't agree that
someone would have to modify the output in this way.



> Rather than
> adding protections that the user specifically doesn't want and must
> circumvent, why not give them what they ask for?


What the user is asking for is determined by the behaviour of "find" as
documented (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 requires path names that _are_ specified on the command line to be
used un-edited:

"""
Each *path* operand shall be evaluated unaltered as it was provided,
including all trailing <slash> characters; all pathnames for other files
encountered in the hierarchy shall consist of the concatenation of the
current *path* operand, a <slash> if the current *path* operand did not end
in one, and the filename relative to the *path* operand.
"""

Hence if the current directory contains only a plain file called "foo" then

find ""

would be required by the POSIX wording quoted above (supposing it somehow
allowed "" as a synonym for ".") to produce

/foo

That seems at least surprising, and I'd also be concerned about the
security implications.  But this turns out to be moot since in section 4.13
("Pathname Resolution") the POSIX standard states

"""
A null pathname shall not be successfully resolved.
"""
(this is from
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html)


To be clear though, the fact that it seems the behaviour you're suggesting
seems not to be POSIX compliant is something of an excuse on my part, since
if POSIX changed to allow this I would still be reluctant.



> Other programs
> convert input paths into a canonical form.  Deliberately creating
> non-canonical paths is adding complexity and a source for error.
> Adding "./" when the user doesn't want it is unsafe because they
> will remove it, creating another source of errors.


I don't agree with your assumption that the user should or will remove it,
though.

I've maintained GNU findutils for about 14 years now, and this is, as far
as I recall, the first request for this kind of change.  Even if I wasn't
philosophically opposed to this because of security concerns, and even if
the behaviour did seem to be compatible with POSIX requirements, it would
likely not make sense to implement this since the aggregate maintenance
burden (on me and on others) would likely exceed the user benefit (since
not many people have so far stated that they want this).

I should point out that the nature of the copyright license on find does
mean that you have the freedom to change the software to do what you want
without asking me, if you like.   Should you be inclined to make code
changes implementing your feature request, I'd be happy to provide advice
and help.   If you would find it helpful I could also point out, in some
useful place, the existence of your patches.   If there is any other way in
which I could make find more convenient for you to use (without
implementing the particular behaviour we've been discussing), please let me
know.

Thanks,
James.