bugfindutils - Bugs: bug #20970, Trailing slash on directory...

 
 

bug #20970: Trailing slash on directory arguments breaks -name

Submitter:  Ross Kendall Axe <rossaxe>
Submitted:  Tue 04 Sep 2007 07:19:01 AM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  Open/Closed:  Closed
Release:  4.2.31 Fixed Release:  4.3.11
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 04 Dec 2007 11:55:06 PM UTC, comment #9: 

Also applied this patch to 4.2.x.

James Youngman <jay>
Group administrator
Sat 24 Nov 2007 01:54:30 PM UTC, comment #8: 

The fix is to use base_name (which malloc's) in combination with strip_trailing_slashes to get the correct string, then free the memory after the comparison.  Both of those functions are provided by the dirname gnulib module.

Eric Blake <ericb>
Group administrator
Sat 24 Nov 2007 12:56:18 PM UTC, comment #7: 

The interp requires that -name not consider trailing slashes in the filename (but are considered in the pattern). 

The current gnulib last_component() and base_name() functions behave somewhat differently but in each case they leave one or more trailing slashes.   Hence those functions seem to be unsuitable as-is, at least for sole use in performing the comparison.

James Youngman <jay>
Group administrator
Tue 20 Nov 2007 02:00:55 PM UTC, comment #6: 

The Austin Group interpretation was issued/approved today.

http://www.opengroup.org/austin/interps/uploads/40/14959/AI-186.txt

Geoff Clare <geoffclare>
Sat 08 Sep 2007 06:04:27 PM UTC, comment #5: 

I've raised the issue with the Austin Group.  Hopefully an interp will be reached before POSIX 200x is finalized:

https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-review-l&id=2512

Eric Blake <ericb>
Group administrator
Sat 08 Sep 2007 03:11:16 PM UTC, comment #4: 

Partly because we currently seem to be following common practice, I would be inclined to ask for a POSIX interp (i.e. for the current issues standard), or at least comment from the Austin Group, before changing our current behaviour. 

The issue with -wholename you mention at the foot of your 09/04/2007 comment probably also merits discussion with the Austin Group, since -path is being standardised.

James Youngman <jay>
Group administrator
Tue 04 Sep 2007 07:30:06 PM UTC, comment #3: 

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//".

Eric Blake <ericb>
Group administrator
Tue 04 Sep 2007 06:34:40 PM UTC, comment #2: 

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

Ross Kendall Axe <rossaxe>
Tue 04 Sep 2007 03:03:09 PM UTC, 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.

Eric Blake <ericb>
Group administrator
Tue 04 Sep 2007 07:19:01 AM UTC, original submission:  

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.

Ross Kendall Axe <rossaxe>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by geoffclare (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by ericb
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by rossaxe (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-12-02 jay Open/ClosedOpen Closed
        Fixed ReleaseNone 4.3.11
    2007-11-26 jay StatusConfirmed Fixed
        Assigned toericb jay
    2007-09-04 ericb Carbon-Copy- Added -email is unavailable-
    2007-09-04 ericb StatusNone Confirmed
        Assigned toNone ericb
    2007-09-04 ericb Dependencies- Depends on bugs #20688

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code