: find
Severity: 3 - Normal
Item Group: Wrong result
Status: None
Privacy: Public
Assigned to: None
Originator Name: Geoff Clare
Originator Email:
Open/Closed: Open
Release
Follow-up Comment #3, bug #17877 (project findutils):
POSIX does require a file's inode number to be stable. To see this consider
what happens if you stat() a pathname and remember the st_dev and st_ino
values, then some time later you stat() the same pathname and observe that
the st_ino value
Follow-up Comment #6, bug #17877 (project findutils):
Good point about inode numbers being reused.
This means that what you can tell from comparing inode numbers (obtained from
pathnames), according to POSIX, is:
* If the inode numbers are different, the file is definitely a different
file.
*
Follow-up Comment #6, bug #18554 (project findutils):
POSIX definitely only allows + to be special when it immediately follows {}.
I can see that because the text doesn't say immediately follows it could be
misinterpreted, but the requirement is clear from the specified form of the
primary:
Follow-up Comment #9, bug #18554 (project findutils):
James, I believe the way I suggested using sh -c is perfectly safe. The
security problem you are thinking of is associated with uses where the {} is
part of the command, e.g.
find ... -exec sh -c 'ls -l {}' \;
which is not portable anyway.
Follow-up Comment #13, bug #18554 (project findutils):
Egmont, you raise an interesting point about the limit on the number of
arguments. There is nothing in POSIX about such a limit, but I don't think
there is anything that forbids it either.
The -exec sh -c 'utility ... $@ ...' sh {} +
Follow-up Comment #3, bug #19605 (project findutils):
You are confusing directory loops and symlink loops, which are completely
different things. In a directory loop, a symlink points up to a parent
directory of the symlink. A stat() of the symlink succeeds. In a symlink
loop the symlink ends
Follow-up Comment #6, bug #19605 (project findutils):
On second thoughts, d_type is a red herring. With the -L option, d_type
doesn't provide enough information for symlinks - find needs to know what
type of file the symlink points to (in order to tell whether the symlink
points to a directory
Follow-up Comment #6, bug #20970 (project findutils):
The Austin Group interpretation was issued/approved today.
http://www.opengroup.org/austin/interps/uploads/40/14959/AI-186.txt
___
Reply to this item at:
James Youngman j...@gnu.org wrote, on 21 Oct 2010:
On Wed, Sep 15, 2010 at 10:32 AM, Geoff Clare g...@opengroup.org wrote:
I wrote, on 04 Sep 2010:
Eric Blake ebl...@redhat.com wrote, on 03 Sep 2010:
However, it also means that we have to think about this case:
find . -exec
Follow-up Comment #10, bug #52137 (project findutils):
James wrote in comment #8:
> In issue 6, -L and -n are specified to interact such that the last-specified
takes effect. The -I option is specified, but no interaction with -L or -n is
called out.
>
> In issue 7, we have the previously
Follow-up Comment #2, bug #58384 (project findutils):
Seems the documentation is wrong:
$ find . -type f -regex '.\{3,\}' | wc -l
0
$ find . -regextype posix-basic -type f -regex '.\{3,\}' | wc -l
16
Clearly the default is not posix-basic.
Follow-up Comment #9, bug #61009 (project findutils):
[comment #5 comment #5:]
> find . -type f \( -exec cp -t "${IMGDIR_DST}" {} + -o -quit \)
That will never evaluate -quit because -exec ... {} + is always true, as
required by POSIX. (With the '+' terminator, command failure is communicated
Follow-up Comment #2, bug #64442 (project findutils):
When fixing this, please also consider changing xargs to make it conform to
POSIX as regards signal handling. POSIX does not allow xargs to handle SIGUSR1
and SIGUSR2 differently from other signals. I.e. if they are inherited as
ignored they
14 matches
Mail list logo
