[bug #20970] Trailing slash on directory arguments breaks -name

[Eric Blake]

Follow-up Comment #3, bug #20970 (project findutils):

More points of reference, seeing how coreutils handles extra trailing slashes
(and adding the coreutils list for comments):

$ mkdir -p dir/subdir
$ touch q r
$ mv -v q r dir
`q' -> `dir/q'
`r' -> `dir/r'
$ # built names were compressed

$ ls -d dir
dir/
$ # command line args were listed as typed

$ ls -R dir
dir:
q  r  subdir/

dir/subdir:
$ # again, command line arg as is, built names compressed

Given that behavior, then perhaps this should happen:

$ find dir
dir
dir/q
dir/r
dir/subdir


And if that is the case, then "find foo// -wholename foo/" would not match,
but "find foo// -wholename foo/*" would match everything, and "find foo//
-wholename foo//*" would only match "foo//".


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #20970] Trailing slash on directory arguments breaks -name

[Ross Kendall Axe]

Follow-up Comment #2, bug #20970 (project findutils):

Just for fun, I tried it on FreeBSD as well, with identical results to GNU
find.  I had intuitively assumed that the -name thing was a no-brainer, for
basically the reasons you mentioned (though I don't have a copy of POSIX
available), but it seems like this odd behaviour is quite common.  Either way,
I was surprised as hell when "find /usr/man/ -name 'man?*'" matched /usr/man
itself, and I shall try to avoid trailing slashes in my scripts or use
-wholename or -samefile from now on to work around this corner case.

As for the trailing slash in the output, that's a good point about symlinks. 
I'm even more convinced now that that's probably best left alone.

Two things immediately spring to mind about multiple trailing slashes in the
output:
1) I would expect "find foo// -wholename foo//" to match, so maybe some care
would need to be taken (should "find foo// -wholename foo/" also match?), and
2) Processing the output with sed or somesuch might break for similar reasons
if the extra slashes were removed (although -printf is probably better for
most things you could do with sed).

Things like that make me think that probably only -name is worth changing,
especially since "tr -s /" gets rid of the extra slashes easily enough. :-)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #20970] Trailing slash on directory arguments breaks -name

[Eric Blake]

Update of bug #20970 (project findutils):

  Status:None => Confirmed  
 Assigned to:None => ericb  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #20970] Trailing slash on directory arguments breaks -name

[Eric Blake]

Update of bug #20970 (project findutils):

  Depends on: => bugs #20688

___

Follow-up Comment #1:

Part of me was inclined to mark this as invalid, since other implementations
that claim to implement POSIX do likewise (for example, on Solaris):

$ mkdir -p foo/bar
$ /usr/xpg4/bin/find foo -name foo
foo
$ /usr/xpg4/bin/find foo/ -name foo
$

and changing behavior would only be introducing gratuitous incompatibilities.
 But on a closer look, the wording in POSIX is:

"The primary shall evaluate as true if the basename of the filename being
examined matches pattern"

and POSIX is clear (for both basename(1) and basename(3)) that trailing
slashes are stripped when determining the basename, which means Solaris find
has the same bug.

However, remember that "foo" and "foo/" are different files when foo is a
symlink to a directory, so, modulo the -H and -L options, the output should
not strip trailing slashes for directories listed on the command line. 
However, since foo/bar and foo//bar are required to name the same file, I
would prefer reducing the amount of output, and always output foo/bar,
regardless of how many trailing slashes were given on the command line.

Therefore, I think the correct behavior is:

$ find foo
foo
foo/bar
$ find foo/
foo/
foo/bar
$ find foo/
foo/
foo/bar
$ find foo -name foo
foo
$ find foo/ -name foo
foo
$ find foo/ -name foo/
find/find: warning: Unix filenames usually don't contain slashes (though
pathnames do).  That means that '-name foo/' will probably evaluate to false
all the time on this system.  You might find the '-wholename' test more
useful, or perhaps '-samefile'.  Alternatively, if you are using GNU grep, you
could use 'find ... -print0 | grep -FzZ foo/'.
$

As I most recently touched this area of code for bug 20688, I'll provide a
patch.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #20970] Trailing slash on directory arguments breaks -name

[Ross Kendall Axe]

URL:
  

 Summary: Trailing slash on directory arguments breaks -name
 Project: findutils
Submitted by: rossaxe
Submitted on: Tuesday 04/09/07 at 07:19
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.2.31
   Fixed Release: None

___

Details:

The following commands illustrate the problem:

$ mkdir -p foo/bar
$ find foo -name foo
foo
$ find foo/ -name foo

The first command returns the directory 'foo', as expected, but the second
one does not find it, apparently because the trailing / was considered to be
part of the filename.  The following test seems to confirm this:

$ find foo/ -name foo/
find: warning: Unix filenames usually don't contain slashes (though pathnames
do).  That means that '-name foo/' will probably evaluate to false all the
time on this system.  You might find the '-wholename' test more useful, or
perhaps '-samefile'.  Alternatively, if you are using GNU grep, you could use
'find ... -print0 | grep -FzZ foo/'.
foo/

Despite the warning message about slashes in the -name match, it does in fact
work.  This issue is probably related to the following oddity:

$ find foo
foo
foo/bar
$ find foo/
foo/
foo/bar

The first command is perfectly consistent in that it doesn't have trailing
slashes in the output, but the second command does have a trailing slash on
one directory, but not the other.  I'm not entirely sure whether this
behaviour is a good thing or not.  Possibly the second command should produce
'foo//bar' (2 slashes) for consistency.

There is a similar effect when using -wholename, but that may actually be the
best behaviour.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/