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

[L A Walsh]

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

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


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