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


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

Submitted by:  Ross Kendall Axe <rossaxe>
Submitted on:  Tue Sep 4 07:19:01 2007  
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Fixed
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Open/Closed: Closed
Release: 4.2.31Fixed Release: 4.3.11

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Tue Dec 4 23:55:06 2007, comment #9:

Also applied this patch to 4.2.x.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sat Nov 24 13:54:30 2007, 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>
Project Administrator
Sat Nov 24 12:56:18 2007, 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>
Project AdministratorIn charge of this item.
Tue Nov 20 14:00:55 2007, comment #6:

The Austin Group interpretation was issued/approved today.


Geoff Clare <geoffclare>
Sat Sep 8 18:04:27 2007, comment #5:

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


Eric Blake <ericb>
Project Administrator
Sat Sep 8 15:11:16 2007, 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>
Project AdministratorIn charge of this item.
Tue Sep 4 19:30:06 2007, 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////
$ # command line args were listed as typed

$ ls -R dir////
q r subdir/

$ # again, command line arg as is, built names compressed

Given that behavior, then perhaps this should happen:

$ find dir////

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>
Project Administrator
Tue Sep 4 18:34:40 2007, 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 Sep 4 15:03:09 2007, 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
$ /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
$ find foo/
$ find foo/////
$ find foo -name foo
$ find foo/ -name 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>
Project Administrator
Tue Sep 4 07:19:01 2007, original submission:

The following commands illustrate the problem:

$ mkdir -p foo/bar
$ find foo -name 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/'.

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
$ find foo/

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 File(s):

No files currently attached


   bug dependencies.

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Dec 2 13:48:04 2007jayOpen/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.3.11
    Mon Nov 26 10:38:24 2007jayStatusConfirmed=>Fixed
      Assigned toericb=>jay
    Tue Sep 4 19:30:06 2007ericbCarbon-Copy-=>Added -unavailable-
    Tue Sep 4 15:03:41 2007ericbStatusNone=>Confirmed
      Assigned toNone=>ericb
    Tue Sep 4 15:03:09 2007ericbDependencies-=>Depends on bugs #20688

    Back to the top

    Powered by Savane 3.1-cleanup1