[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: L A Walsh
Subject: Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?
Date: Mon, 20 Feb 2017 21:09:20 -0800
User-agent: Thunderbird

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\*

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


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
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
   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, ;-)

reply via email to

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