Follow-up Comment #6, bug #65804 (group findutils):
[comment #5 comment #5:]
> Wasn't aware that "~/bin" is not posix conform... it was just shorter :)
It's the quoting that's the problem. In a POSIX-conforming shell you can use ~
in PATH assignments, as long as you don't quote it. Then the
Follow-up Comment #4, bug #65804 (group findutils):
[comment #2 comment #2:]
> It does appear that Bash performs tilde expansion on $PATH entries while
execvp (which is what the env program uses) does not:
This is one of the places where bash does not conform to POSIX by default.
> $ env -u
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
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 #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 #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
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 #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:
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 #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 #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 #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
: 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
16 matches
Mail list logo