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

[L A Walsh]

Bernhard Voelker wrote:
> On 02/20/2017 08:52 PM, L A Walsh 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?
> >     
>
> At first glance, the request sounds interesting to me.
> However, after some thinking I have some qualms with it.
>
> First of all: why do you need to strip off the leading "./"?
> If you only need the basenames, then you can use...
>   
---
   I want the default output to not have a "./" in it if I
don't specify it.

so ...
find '' -name \*foo\*
....output...

or
find ''
.... output...

>   $ find ''
> works identical to
>   $ find -printf '%P\n'
>   
----
   If I wanted a longer workaround I could have looked it up, but
yeah, that seems to be what the output I'm referring to, but
having to add  print (or do I want -print0?  now remember to remove
newline from your output format...  uhhh...simple case)...


find
> right?
>
> Regarding feasibility:
> find(1) does not treat an "" file argument special; instead it's
> actually the kernel which returns ENOENT for it:
>   
---
   I know it doesn't.  It would have to be treated as specially
as the 'no-path' case... i.e. it does something else (useful) with
something that would otherwise have been an error (one of the reasons
I chose that trigger -- so as to not change any working programs).

>   $ strace -ve newfstatat find ''
>   newfstatat(AT_FDCWD, "", 0x1784cd8, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such 
> file or directory)
>   find: ‘’: No such file or directory
>   +++ exited with 1 +++
>
> find(1) tries to read the status - and for directories its
> content -, from the file system.  I do not know if there are
> operating systems or file system implementations which would
> allow an empty-string file name, but the requested change would
> break that.
>   
----
   I'm pretty sure there are no posix compatible file systems
that a zero length filename is valid.


> Of course, we could hack "find ''" to be treated as "find -printf '%P\n'",
> but it would become hard to argument how the '' file argument should
> be treated as in combination with a) other file arguments, and/or b) with
> other actions:
>
>   $ find /dir '' other
>   $ find '' -printf '%H, %p, etc.'
>   
----
   I wasn't thinking of turning it into a shorthand
for the switch you mention -- just a shorthand for not prepending
'./' to the starting path.  For any other input, it bases the
generated paths off of the listed paths.  But how do you specify
to start at the current dir without specifying '.'?

In the above case, I'd expect output like
/dir
/dir/xxx
followed by a find from the current directory.

I wouldn't expect it to change the output for /dir.

Somewhere, find has to take the input paths and start looking
from them for sub-paths.  When doing output, it needs to prepend
the path "inputted" by the user to the subpaths found, no?

> etc.  IMO this would bring quite some inconsistency and confusion.
>   
----
   If it was done that way ... sure.  But neither should
we hold a strawman implementation against the idea.
> Finally, changing the behavior as requested would for sure break
> (okay, badly written) scripts like this:
>
>   var="$( command which may fail )"
>   if find "$var"; then
>     do_something
>   fi
>   
----
   ???
   The above still fails, since you included DQ's around
$var -- they end up in the invoked command yielding same result
as "find ''":
>  find ''
find: ‘’: No such file or directory


Note I did say it wouldn't affect *working* programs, ;-)