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

[Bernhard Voelker]

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

  $ find -printf '%f\n'

Other than that, I think you want that

  $ find ''

works identical to

  $ find -printf '%P\n'

right?

Regarding feasibility:
find(1) does not treat an "" file argument special; instead it's
actually the kernel which returns ENOENT for it:

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

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

etc.  IMO this would bring quite some inconsistency and confusion.

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

I've personally never seen the leading "./" as annoying enough.

Have a nice day,
Berny