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

[L.A. Walsh]

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".  Why would you feel it is
required when the user explicitly asks for it not to be added?

>    The problem is that the
> file names which cause problems are not just dangerous, 
> they are rare[1] - so casual testing won't detect the
> problem which lays in wait.
>   
---
> > Almost every usage of "./" in a find is, at some point,
> > followed by a stripping of "./" -- somewhere, in subsequent
> > use.
> >     
>
> 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.  In fact, having to edit paths as they come out of
find is a dangerous step that someone may get wrong.  Rather than
adding protections that the user specifically doesn't want and must
circumvent, why not give them what they ask for?  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.


> output is intended to be consumed by humans, -printf is likely to give the 
> control and results needed, as Bernhard already suggested.
>   
----
 I'm just trying to get a source of clean input to find -- where
it can take a user path and output names based on that path without
prepending extra characters to it.  Find was intended to take
user paths and find objects based on that path and output the result.

 Why would you insist on forcing users to prepend "./" to their paths?
>   
> > This would allow a backwards compatible way of forcing
> > a null-path onto the front of returned values.
> >
> >     
>
> If users want to omit the "./" then I suggest post-processing the output...
>   
Added complexity adds errors.  It would be better if there was a
way to let find use what the user typed, vs. a pre-filtered
vision. 

> For what it's worth, the existing behaviour has been this way for as long as the source repository records 
---
  
   And for 100's of years people believed the earth was flat.
And the point is?

   The rest of your note doesn't seem relevant.  Proper
quoting or use of print0 can be used to solve the same problems.

   Not editing the user's paths isn't going to cause an end of the
world.  If the users don't want raw paths, they aren't required to
use them and won't get them by default.  But if they specifically
ask for the paths to be used literally, without prefixes, it
should be assumed they aren't children.

   Assuming that they are seems very un-unix like.