bugfindutils - Bugs: bug #23920, find.1: please add short note...

 
 

bug #23920: find.1: please add short note about no trailing slashes for directories

Submitter:  mouz <mouz>
Submitted:  Wed 23 Jul 2008 11:11:02 PM UTC
 
Category:  find Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  Zooko O'Whielacronx Open/Closed:  Closed
Release:  4.4.0 Fixed Release:  4.5.6b
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Tue 14 Jul 2009 10:37:31 PM UTC, comment #9: 

Fixed in the 4.5.x tree.

James Youngman <jay>
Project Administrator
Sun 12 Jul 2009 08:58:26 PM UTC, comment #8: 

The attached patch provides a warning for this case and updates the documentation to be more specific.

(file #18420)

James Youngman <jay>
Project Administrator
Fri 10 Apr 2009 12:09:26 PM UTC, comment #7: 

"shell pattern" does have a specific meaning; see
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13 for example.

I don't understand your point here:

<< Note that the result line of an object differs depending on the given search path, you have take care of this in your "-path" expressions.

Example:
cd ~
find find1 ./find1 ~/find1 -type d -name "test1"
=> find1/test1
=> ./find1/test1
=> /root/find1/test1 (or /home/<user>/find1/test1)

>>


The example presumably relates to the paragraph before it, but it doesn't use -path.

Certainly -name 'foo/' will not match anything, since / is not part of the basename of any file other than / and //.   On the other hand "-path foo/" will match something if ./foo/. exists and foo/ was a command line argument.

This behaviour is required by POSIX; see http://www.opengroup.org/austin/interps/uploads/40/14959/AI-186.txt

However, maybe I misunderstood your point an so I'm responding to something you didn't actually say.

James Youngman <jay>
Project Administrator
Thu 09 Apr 2009 02:18:31 PM UTC, comment #6: 

I ran into a similar problem with find 4.4.0 (in Debian 5.0.0), and got it sorted out.
This bug consists of several parts, so I will try to give a summary first, then explain in detail from general down to this specific issue.
By the way this behaviour seems to be a side effect of the fix for https://savannah.gnu.org/bugs/?20970

Summary:
1. "-path" works as designed with a simple sting comparison
2. the man-page is misleading (especially the term "shell pattern")
3. inconsistent behaviour if a given search path is part of the result and has a leading slash

Preparation for examples:
cd ~
mkdir -p find1/test1

Details:
1 & 2. Result Lines & "-path" expression / man-page
a) Result lines of an object never have a trailing slash. It's always /path/to/something, where something can be a file, directory, link, whatever
b) "-path" does a simple string comparison towards the object's result line.

The man page is misleading as it uses the term "shell pattern", but it's just a dumb string pattern.
The Debian man page tries to explain it with "the metacharacters do not treat ‘/’ or ‘.’ specially;", but then the reader is already on the wrong train named "shell pattern" (e.g. /etc/../tmp/../usr/bin)
See documenation at http://www.gnu.org/software/findutils/manual/html_mono/find.html#Full-Name-Patterns)

Therefore if you check for a specific directory use "-path /direct/path/to/directory" without a trailing slash.
Use boolean logic and the "-type" expression to avoid problems with files, links, etc. that could have the same path.

Note that the result line of an object differs depending on the given search path, you have take care of this in your "-path" expressions.

Example:
cd ~
find find1 ./find1 ~/find1 -type d -name "test1"
=>  find1/test1
=>  ./find1/test1
=>  /root/find1/test1 (or /home/<user>/find1/test1)

3. The bug is that the result line doesn't comply to the rule of 1a, if the search path itself is the tested object and it was stated with a trailing slash.

Example:
find find1 find2/ -type d

The fix would be to apply the functionality of GNU --strip-trailing-slashes (see http://www.gnu.org/software/coreutils/manual/html_node/Trailing-slashes.html), in a similar way discussed for https://savannah.gnu.org/bugs/?20970

M. Buecher <maddes_b>
Sat 06 Sep 2008 10:17:09 PM UTC, comment #5: 

Oops.  I was thinking that -path added an implicit leading and trailing *, but that is not the case.  Just like -name, the pattern does not match an internal substring unless explicit globs are provided.  So, revisiting the examples:

$ find 2008/ 2001/ -path 2008/ -o -path 2001
2008/
$ find 2008/ 2001/ -path 2008/ -o -path '2001*'
2001/
2008/
$ find 2008 2001 -path 2008/ -o -path 2001
2001
$ find ./src/emacs/ -path ./src/emacs/
./src/emacs/
$ find . -path ./src/emacs/
$ find . -path './src/emacs/*'
./src/emacs/foo.c

So, indeed, a trailing slash to path will never match anything except command line arguments, making it almost worthless for -prune.

Eric Blake <ericb>
Project Administrator
Sat 06 Sep 2008 09:52:55 PM UTC, comment #4: 

I don't know how I missed it in 5.1.   Sorry.

I agree with your first two examples.

But I can't imagine that it was intended for  "-path ./src/emacs/" to match ./src/emacs/foo.c, any more than "-name austin" is intended to match "austin-d5.1r.pdf".

However I cannot see any wording right now in section 2.13 of volume 4 which indicates that this should not happen.

James Youngman <jay>
Project Administrator
Sat 06 Sep 2008 03:12:55 PM UTC, comment #3: 

Huh?  -path was added for POSIX 200x; in draft 5.1, it is line 89102.  At any rate, based on line 89051 ("Each path operand shall be evaluated unaltered as it was provided, including all trailing <slash> characters; all pathnames for other files encountered in the hierarchy shall consist of the concatenation of the current path operand, a <slash> if the current path operand did not end in one, and the filename relative to the path operand. The relative portion shall contain no dot or dot-dot components, no trailing <slash> characters, and only single <slash> characters between pathname components."), I argue that the following behavior should occur:

$ find 2008/ 2001/ -path 2008/ -o -path 2001
2001/
2008/
(ie. the pattern '2008/' should match the argument '2008/', and the pattern '2001' should match the argument '2001/')

$ find 2008 2001 -path 2008/ -o -path 2001
2001
(ie. the pattern '2008/' does not match the argument '2008')

I also argue that:
$ find . -path ./src/emacs/

will match for files within src/emacs (after all, the pattern './src/emacs/' matches the file './src/emacs/foo.c', according to globbing), but:

$ find . -path ./src/emacs/ -prune

is worthless, since './src/emacs/' does not match './src/emacs', and -prune is only useful on directories.

Maybe it is worth warning about trailing slash unless POSIXLY_CORRECT.

Eric Blake <ericb>
Project Administrator
Sat 06 Sep 2008 11:22:56 AM UTC, comment #2: 

My mistake.   I just read IEEE P1003.1 Draft 5.1 (that is, the current draft of the POSIX spec), and it does not include find -path. 

Anyway, I think we can go further than you suggest; we can issue a warning for -path ./src/emacs/ since it contains a trailing slash.   The warning would be somewhat similar to the warning you get for -name a/b.

But yes, we should also improve the documentation.

However, we also have a bug in the way that command-line arguments are matched:
$ ls -ld 2008 2001
drwxr-xr-x 8 james james 4096 2008-09-06 11:57 2001
drwxr-xr-x 2 james james 4096 2008-09-06 12:10 2008
$ find 2008/ 2001/ -path 2008/ -o -path 2001
2008/
$ find 2008 2001 -path 2008/ -o -path 2001
2001
$

The first find command should have matched 2001 but not 2008, just like the second find command actually did.

I'd guess this may also mean that -path foo/. and foo/.. and foo/../bar need documenting (and perhaps some fixes).   We need not to break -path foo/bar versus /foo/bar and /foo/bar as well, while we're at it.

James Youngman <jay>
Project Administrator
Sun 31 Aug 2008 02:25:47 PM UTC, comment #1: 

The next version of POSIX will introduce -path so I need to be sure that the current behaviour is compliant, anyway.

James Youngman <jay>
Project Administrator
Wed 23 Jul 2008 11:11:02 PM UTC, original submission:  

Please add a short note about the fact that for matching a directory one should not use a trailing slash.

Motivation: the following does not do what some would expect at first sight. The tree below emacs is also printed, while the user intended prune for it:

find . -path ./src/emacs/ -prune -o -print

(This request was originally filed by Zooko O'Whielacronx in the ubuntu bugtracker at https://bugs.launchpad.net/bugs/6087. It was filed for an old version of findutils, but I found the current manual page also does not contain such a note.)

mouz <mouz>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by maddes_b (Posted a comment)
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by mouz (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-03-31 jay Open/ClosedOpen Closed
        Fixed ReleaseNone 4.5.6b
    2009-07-14 jay StatusNone Fixed
    2009-07-12 jay Attached File- Added 0001-Savannah-bug-23920-warn-about-path-arguments-endi.patch, #18420
    2008-08-31 jay Assigned toNone jay
    2008-07-23 mouz Carbon-CopyRemoved mouz -
    2008-07-23 mouz Carbon-Copy- Added mouz

    Back to the top


    Powered by Savane 3.9