[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #23920] find.1: please add short note about no trailing slashes for
[bug #23920] find.1: please add short note about no trailing slashes for directories
Thu, 09 Apr 2009 14:18:35 +0000
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)
Follow-up Comment #6, bug #23920 (project findutils):
I ran into a similar problem with find 4.4.0 (in Debian 5.0.0), and got it
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
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:
mkdir -p find1/test1
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
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.
find find1 ./find1 ~/find1 -type d -name "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
find find1 find2/ -type d
The fix would be to apply the functionality of GNU --strip-trailing-slashes
in a similar way discussed for https://savannah.gnu.org/bugs/?20970
Reply to this item at:
Nachricht geschickt von/durch Savannah
- [bug #23920] find.1: please add short note about no trailing slashes for directories,
M. Buecher <=