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 04 Sep 2007 07:19:01 AM UTC  
 
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 04 Dec 2007 11:55:06 PM UTC, comment #9:

Also applied this patch to 4.2.x.

James Youngman <jay>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Digest:
   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 02 Dec 2007 01:48:04 PM UTCjayOpen/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.3.11
    Mon 26 Nov 2007 10:38:24 AM UTCjayStatusConfirmed=>Fixed
      Assigned toericb=>jay
    Tue 04 Sep 2007 07:30:06 PM UTCericbCarbon-Copy-=>Added -unavailable-
    Tue 04 Sep 2007 03:03:41 PM UTCericbStatusNone=>Confirmed
      Assigned toNone=>ericb
    Tue 04 Sep 2007 03:03:09 PM UTCericbDependencies-=>Depends on bugs #20688

    Back to the top


    Powered by Savane 3.1-cleanup