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
