[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: Bernhard Voelker
Subject: Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?
Date: Tue, 28 Feb 2017 08:22:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 02/26/2017 08:44 AM, L.A. Walsh wrote:
> Adding "./" when the user doesn't want it is unsafe because they
> will remove it, creating another source of errors.

I see it different: find does not "prepend" the "./".  Instead,
 $ find
without any path argument assumes the current directory as the
starting point for the search - which is ".".  This assumption
is for convenience for the user.  Therefore, all output for
-print starts with "./" which is exactly what the user is asking
(implicitly) for.

Without "." as assumed starting point, find would not know what
directory to read.  Unless non-directory files are given as arguments,
find always uses opendir/readdir/closedir to process the current
directory and the hierarchy below (also the underlying FTS from gnulib).
Thus said, treating the empty '' argument as "." for the traversal
but at the same time not doing so for the output somehow feels odd to me.

Like James suggested in the other email, please have a look at the code,
and try to come up with patches.  But as explained in the above, it
would probably already look quite hacky in the code to a) assume
"." as the starting point for the traversal, and b) undoing the same
for the output ... leaving alone the cases where the user really passed
"." as another argument.

Finally, when thinking about the use in shell scripts or on the
command line, I'm still convinced that
  $ var=
  $ find "$var"
should fail rather than processing with an assumed "." as starting

Thus said, although the idea was quite tempting in the beginning,
it more and more feels wrong to me.

Not much related:

> [...] Other programs
> convert input paths into a canonical form. [...]

This comment would inspire me more to add a -printf directive to
output all found files in canonicalized form - I think we don't have
this yet.

Have a nice day,

reply via email to

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