[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: L.A. Walsh
Subject: Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?
Date: Sat, 25 Feb 2017 23:44:36 -0800
User-agent: Thunderbird

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]