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

[James Youngman]

On Mon, Feb 27, 2017 at 12:59 AM, L A Walsh <address@hidden> wrote:

>
>
> James Youngman wrote:
>
>>
>> Because, typically, -printf is used for output intended for humans rather
>> than programs.
>>
> ----
>    Ahh... This is your 1st mistake.  Interactive forms, and the
> ones used most often are supposed to be the shortest forms.  Go back
> and look at early unix design docs.  The designers of the early
> unix tools couldn't touch type.  That's why the names were all
> short.  The most commonly used items were the shortest.  Go read a
> book on language design (like the 2011 C++ Stroustrup book).  He
> says the same thing -- you use the shortest forms for the most
> common usage.
>

I believe you're saying that the shortest form, "find" by itself, is the
one used most often and the form intended for use by humans.

I agree.   Perhaps you've assumed that I was saying that "find -printf" is
the only form intended to produce output for humans, but that's not what I
was saying.





> 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.
>>
> I find the extra "./" to be a distraction.  It slows comprehension.
> Every book on comprehension and language will tell you that languages
> with short forms for expression are the most powerful.
>

"./" is part of the output, though, not the input from the user.



>
>>
>>     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.
>>
> ----
>    ??? How can you say that's what the user wants --- Telling the
> user that some complex invocation is "really what the want" is the
> height of arrogance.  You don't tell users what they want -- you
> listen -- something you are refusing to do.


You're putting words into my mouth.

I am stating that the user interface for find, such as it is, is a "little
language" (in the sense coined by Jon Bentley).   The user uses this
language to indicate their wishes, and the find command line, together with
the "specification" of the language, determine how the computer interprets
what the user stated that they wanted.

To phrase this a bit differently, and I hope more clearly the second time:

1. The only information we have about what the user wants is the find
command line that they specified.
2. This means that we cannot reliably determine that the user "specifically
doesn't want" something unless they said as much in the find command line.



>
>
> (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.



>
>> 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.
>>
> ----
>    Um...
>
>  find tmp2
>>
> tmp2
> tmp2/a
> tmp2/b
> tmp2/c
>
> Clearly a slash is not appended to the current path operand
> in the 1st case.  Why should one be forced in the "" case:
>
> cd tmp2
> find ""
> a
> b
> c
>
>
>
>> I don't agree with your assumption that the user should or will remove
>> it, though.
>>
> ----
>    You can't disagree that I remove it.  I do.  I am a user.
> Thus your statement that I don't remove it is clearly untrue.
>

My statement was about users in general.


> You can believe I'm the only one in the entire world that does
> so if you want, but that would seem to be a rather provincial
> view in my opinion.
>

My claim is not that there is just one user who does this (and I'd say it
was pretty obvious I wasn't claiming so).   My claim is that the
*proportion* of users who routinely remove the "./" is small.

My rationale for that claim is that, in the last fifteen years, as far as I
can remember, the total number of people asking on the mailing list for
"./" to be omitted from the output is 1.     If the proportion of users who
specifically don't want "./" in the output is indeed small, then the burden
of implementing or maintaining the feature isn't justified.

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.

James.