[bug #65804] ~/bin detected as relative path

[Geoff Clare]

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 shell assigns the
expanded value to PATH.

$ PATH="/bin:~/bin"; echo "$PATH"
/bin:~/bin
$ PATH=/bin:~/bin; echo "$PATH"
/bin:/home/geoff/bin



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65804] ~/bin detected as relative path

[Geoff Clare]

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 ENV -u BASH_ENV PATH='/bin:~/bin' bash --norc -c 'type
rebuild-findutils.sh'

Try that with POSIXLY_CORRECT=1 added and bash should report
"rebuild-findutils.sh: not found"



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

[Geoff Clare]

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 must be ignored, otherwise they must terminate xargs.

Two possible solutions:

1. Only enable special handling of SIGUSR1 and SIGUSR2 if the -P option is
used (as it's not in POSIX and can therefore change the behaviour).

2. Don't enable special handling of SIGUSR1 and SIGUSR2 if POSIXLY_CORRECT is
set in the environment (and -P is not used).



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #61009] xargs need option to immediately stop on command fail

[Geoff Clare]

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
via find's exit status instead.)

$ find --version 2>&1 | head -n 1
find (GNU findutils) 4.6.0.225-235f
$ find . -type d \( -exec sh -c 'exit 1' {} + -o -print \)
$ echo $?
1
$ find . -type d \( -exec sh -c 'exit 1' {} \; -o -print \)
.
$ echo $?
0


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58384] incorect documentaion for -regex

[Geoff Clare]

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.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52137] unexpected behaviour when combining -I and -n

[Geoff Clare]

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 quoted phrase:
> 
> "The -I, -L, and -n options are mutually-exclusive. Some implementations use
the last one specified if more than one is given on a command line; other
implementations treat combinations of the options in different ways."
> 
> However, this quote is taken from the Rationale section which is
non-normative (per the comment earlier in the document, "The following
sections are informative.")
> 
> Since the text stating that these options are mutually exclusive is
non-normative, and that the text doesn't seem to indicate that the user should
expect anything other than a perhaps-unexpected combination of behaviours, I'm
left not totally sure that the xargs implementation is allowed to issue a
diagnostic.
> 
> Geoff, do you have an opinion on whether a diagnostic is permissible?

You noticed the descriptive text changes but you missed the all-important
SYNOPSIS change.

Issue 6: [-I replstr][-L number][-n number

Issue 7: [-I replstr|-L number|-n number]

The vertical bars indicate that the options are mutually exclusive.

So yes you can write a diagnostic.

> If we do issue a diagnostic, but all invocations of the named utility return
0, is it still conforming for xargs also to return 0? 

The general rule is that if you write a diagnostic, the exit status has to be
non-zero.  However, in this particular case there is a get-out courtesy of XBD
12.1 item 8:

"The use of conflicting mutually-exclusive arguments produces undefined
results, unless a utility description specifies otherwise."

Since it says the result is "undefined", you can do anything you want.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: find . -exec TURNIP{} +

[Geoff Clare]

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 TURNIP{} {} +
 
  Perhaps we should raise this on the Austin Group mailing list.
 
  I have submitted it as bug 309.
 
 I notice that the bug now has a response too:
 http://austingroupbugs.net/view.php?id=309
 
 As far as I understand note 562 attached to that bug (I have a copy of
 draft 5.1, but the line numbers do not seem to correspond, so I'll
 need to check for an updated version):

If you are a member of the austin-group-l mailing list, I think you
should be able to download the final SUSv4 PDF from
http://www.opengroup.org/pubs/catalog/c082.htm
(I'm assuming when that page says members it means Austin Group
members.)

 1. If {} occurs more than once in the arguments to -exec, the
 behaviour is unspecified.
 2. If {} occurs in an argument but the argument is not exactly {},
 there are two options:
  a. The argument is used, unchanged
  b. The argument is substituted
 ... and we must document which will occur.  [I have a preference for 2a]

Item 2 only applies to the ';' terminator, and item 1 only applies to
the '+' terminator.

The end result of the changes in note 562 is that the requirements
for the ';' terminator are unchanged, and for the '+' terminator you
have more freedom to do whatever you want if more than one argument
contains {} (regardless of whether the extra one(s) are only {}).

If you do a substitution for TURNIP{} when the terminator is ';' you
might decide that leaving it unchanged for a '+' terminator would
be undesirable as it would mean find silently treats such arguments
differently for the two terminators.  You could instead report an
error when the terminator is '+'.  Or you could do a substitution -
there is one that sort of makes sense, namely prefix TURNIP to every
pathname as you aggregate them.

 Bug 310 is also relevant.  It deals with this question of how this
 should be interpreted:
 
 find -exec utility1 arg arg2 arg4 arg5{} + -exec utility2 arg6 {} +
 
 The options are
  (i) utility1 is invoked with a number of arguments, one of which is
 utility2.   utility2 is not invoked by find.
  (ii) utility1 and utility2 are both invoked.   The final argument
 passed to utility1 is either substituted or not, and this is
 implementation defined (as for note 562).
 However, as far as I can see there is no resolution yet for bug 310,
 so I don't know whether we should be implementing (i) or (ii).

Bug 310 is marked Accepted and Resolved.  This means the requested
change was accepted as an editorial change, no formal interpretation
needed.  Option (ii) is not correct because the standard requires
that the first '+' is not treated as a terminator.  However, since
more than one argument contains {} you do have more choices than
just option (i), as discussed above.  E.g. you could report an error.

 Either way, the current implementation of GNU find at the current HEAD
 revision rejects the construct, which is wrong.

Not necessarily - it depends on what the error message is.  If the
message implies that the first '+' was treated as a terminator, then
it's wrong.

Regards,
Geoff.

[bug #20970] Trailing slash on directory arguments breaks -name

[Geoff Clare]

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:

  http://savannah.gnu.org/bugs/?20970

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #19605] find does not report symlink loop when trying to follow symlinks

[Geoff Clare]

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 up (possibly through other symlinks) pointing to
itself.  A stat() of the symlink fails with ELOOP.  The POSIX requirements
relating to detection of directory loops have no bearing on this problem,
which is about symlink loops.

It's interesting that adding -size produces the desired result, but it
shouldn't make any difference.  With -L (or -H), find needs to stat() each
path operand in order to tell whether it resolves to a directory that it
should descend into.

You had your doubts about bug 11148 as well, but in the end you decided to
make the change I requested.

The current versions of AIX, HP-UX and Solaris all report the expected error,
the same as findutils 4.2.28 does.  I can see no justification for making
4.3.3 behave differently.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?19605

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #19605] find does not report symlink loop when trying to follow symlinks

[Geoff Clare]

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 that it should descend into).

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?19605

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18554] feat req: -exec cmd {} more args +

[Geoff Clare]

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:

-exec utility_name [argument ...] ;
-exec utility_name [argument ...] {} +

The reason it was done that way was to minimize the chances of breaking
existing uses of -exec of the form:

find ... -exec utility [args]... {} args... + [args]... \;

The POSIX rationale gives an example command that would still be broken even
with the rules as they are, but the hope was that such uses were very rare.

If there is a need to have arguments after the aggregated ones this can
easily be accomplished using sh -c:

find startpoint -tests ... -exec sh -c 'scp $@ remote:/dest' sh {} + 

The current draft of the next revision of POSIX.1 includes an example on the
find page that shows this kind of usage.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18554

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18554] feat req: -exec cmd {} more args +

[Geoff Clare]

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.  (POSIX says {} only needs to be substituted if
it is a separate argument.)


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18554

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #18554] feat req: -exec cmd {} more args +

[Geoff Clare]

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 {} + technique is well known and
often recommended on comp.unix.shell, so if there is a potential problem with
it on Linux I would say that is a (quality of implementation) problem for
Linux, not a problem that POSIX needs to address. It could easily be
mitigated by putting a smaller limit in find on the number of arguments it
aggregates.  A limit of 32000 would leave plenty of room for additional fixed
arguments to be passed to the utility.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?18554

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17877] Invalid No such file or directory error on filesystem without stable inode numbers

[Geoff Clare]

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.

* If the inode numbers are the same, the file might be the same file or it
might be a different file that has been assigned the same inode number.

The ambiguity in the second case can be avoided by obtaining the first inode
number from an open fd (which is then kept open) instead of a pathname.  (Or
an fd could be used to obtain the second inode number, as long as it was open
at the time the first inode number was obtained.)

(All of the above assumes that the device numbers are the same.)

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17877

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #17877] Invalid No such file or directory error on filesystem without stable inode numbers

[Geoff Clare]

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 is different.  POSIX says The st_ino and st_dev fields
taken together uniquely identify the file within the system, therefore
st_ino being different means that the pathname now refers to a different
file.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?17877

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils

[bug #16738] find does not subtract environment size from ARG_MAX

[Geoff Clare]

URL:
  http://savannah.gnu.org/bugs/?func=detailitemitem_id=16738

 Summary: find does not subtract environment size from
ARG_MAX
 Project: findutils
Submitted by: geoffclare
Submitted on: Friday 06/02/2006 at 16:52
Category: 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: 4.2.27
   Fixed Release: None

___

Details:

In xargs.c there is the following code:

  /* Take the size of the environment into account.  */
  if (size_of_environment  posix_arg_size_max)
{
  bc_ctl.arg_max = 0;
  env_too_big = 1;
}
  else
{
  bc_ctl.arg_max = posix_arg_size_max - size_of_environment;
}

The equivalent code is missing from find.  This means that if
the environment passed to find is too large, it can produce
exec() errors when {} + is used:

$ env | wc -c
1953
$ find . -exec true {} +
$ FOO=$(printf '%1024s' x) env | wc -c
2982
$ FOO=$(printf '%1024s' x) find . -exec true {} +   
find: true: Argument list too long
find: true: Argument list too long







___

Reply to this item at:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=16738

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils