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

[Bernhard Voelker]

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

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,
Berny