Re: -newer returning old results

[James Youngman]

On Wed, Oct 20, 2010 at 3:06 PM, Kai Hendry  wrote:
> I have a script that uses find and -newer, however everytime it's
> invoked it returns the same selected old results. For the most part it
> works, but for example the particular old contents of
> "/home/hendry/static.natalian.org/2009-01-05/" are returned. How can
> this be explained?
>
> Many thanks,
>
>
> thor:456$ find /home/hendry/static.natalian.org -newer last.txt -iname
> *.ogg -o -iname *.ogv -type f

This is a valid find command line.  But there are two problems with it
that mean it no doubt does not do what you hoped.

1. You did not quote the arguments to -iname.   See for example the
section NON-BUGS in the find manpage.   Also see the description of
-iname in the same manual page.
2. The precedence of the implicit "and" between tests is higher than
that of "-o".See the section OPERATORS in the find manpage.   In
other words

find /home/hendry/static.natalian.org -newer last.txt -iname "*.ogg"
-o -iname "*.ogv" -type f
means the same as
find /home/hendry/static.natalian.org \( -newer last.txt -iname
"*.ogg" \) -o \( -iname "*.ogv" -type f \)
not the same as
find /home/hendry/static.natalian.org  -newer last.txt \( -iname
"*.ogg" -o -iname "*.ogv" \) -type f

... whereas it is probably the latter (with the altered -type f) that
you intended.

I hope this helps,
James.



> /home/hendry/static.natalian.org/2010-01-10/12.ogv
> /home/hendry/static.natalian.org/2010-01-10/11.ogv
> /home/hendry/static.natalian.org/2010-01-10/23.ogv
> /home/hendry/static.natalian.org/2010-01-10/24.ogv
> /home/hendry/static.natalian.org/2010-01-10/22.ogv
> /home/hendry/static.natalian.org/2010-01-10/33.ogv
> /home/hendry/static.natalian.org/2010-01-10/32.ogv
> /home/hendry/static.natalian.org/2010-01-10/21.ogv
> /home/hendry/static.natalian.org/2010-01-10/31.ogv
> /home/hendry/static.natalian.org/2010-01-10/13.ogv
> /home/hendry/static.natalian.org/2010-01-10/34.ogv
> /home/hendry/static.natalian.org/2009-07-12/talkaoke-2009-05-28-host_session_9-part_2.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_4205.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_3967.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_4206.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_4169.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_3969.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_4160.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_4217.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_4183.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_3949.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_3970.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_3966.ogv
> /home/hendry/static.natalian.org/2009-01-05/mvi_3968.ogv
> thor:457$ cat last.txt
> /home/hendry/static.natalian.org/2010-01-10/34.ogv
>
> thor:459$ stat /home/hendry/static.natalian.org/2009-01-05/mvi_4205.ogv
>  File: `/home/hendry/static.natalian.org/2009-01-05/mvi_4205.ogv'
>  Size: 3161219         Blocks: 6184       IO Block: 4096   regular file
> Device: 811h/2065d      Inode: 187843284   Links: 1
> Access: (0644/-rw-r--r--)  Uid: (67299/  hendry)   Gid: (24839/pg224602)
> Access: 2009-07-17 17:45:50.0 -0700
> Modify: 2009-01-05 05:41:32.0 -0800
> Change: 2009-07-23 06:57:19.0 -0700
> thor:460$ stat last.txt
>  File: `last.txt'
>  Size: 51              Blocks: 8          IO Block: 4096   regular file
> Device: 811h/2065d      Inode: 187260985   Links: 1
> Access: (0664/-rw-rw-r--)  Uid: (67299/  hendry)   Gid: (24839/pg224602)
> Access: 2010-03-08 01:07:08.0 -0800
> Modify: 2010-10-20 06:56:42.0 -0700
> Change: 2010-10-20 06:56:42.0 -0700
> thor:461$ stat /home/hendry/static.natalian.org/2009-01-05
>  File: `/home/hendry/static.natalian.org/2009-01-05'
>  Size: 4096            Blocks: 8          IO Block: 4096   directory
> Device: 811h/2065d      Inode: 187842583   Links: 2
> Access: (0755/drwxr-xr-x)  Uid: (67299/  hendry)   Gid: (24839/pg224602)
> Access: 2009-07-17 18:06:41.0 -0700
> Modify: 2009-01-05 05:41:32.0 -0800
> Change: 2009-07-23 06:57:19.0 -0700
>
>
>
> thor:463$ mount
> /dev/sda1 on / type ext3 (rw,errors=remount-ro)
> tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
> proc on /proc type proc (rw,noexec,nosuid,nodev)
> sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
> devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
> /dev/sda2 on /tmp type ext3
> (rw,noexec,noatime,nodiratime,data=ordered,commit=300)
> /dev/sda6 on /var/spool/cron/crontabs type ext3 (rw,nosuid,nodev)
> /dev/sdb1 on /home type ext3
> (rw,nosuid,nodev,noatime,nodiratime,errors=remount-ro,data=writeback)
> none on /sys/kernel/config type configfs (rw)
>
>

Re: find . -exec TURNIP{} +

[James Youngman]

On Wed, Sep 15, 2010 at 10:32 AM, Geoff Clare  wrote:
> I wrote, on 04 Sep 2010:
>>
>> Eric Blake  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):

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]

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).
Either way, the current implementation of GNU find at the current HEAD
revision rejects the construct, which is wrong.The current
behaviour would only be acceptable if the Austin Group selects (i) in
cases like "find -exec utility1 arg arg2 arg4 arg5{} +" (and there are
no more arguments).

[bug #31359] FAIL: test-strstr on alpha - please update gnulib

[James Youngman]

Update of bug #31359 (project findutils):

  Status:None => Fixed  
 Assigned to:None => jay

___

Follow-up Comment #1:

Fixed and pushed.   But please note that the current head contains an
incorrect bugfix for bug #30777 - it's not currently standard-compliant.   
See recent discussions on the list for details.

___

Reply to this item at:

  

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

Re: find . -exec TURNIP{} +

[Geoff Clare]

James Youngman  wrote, on 21 Oct 2010:
>
> On Wed, Sep 15, 2010 at 10:32 AM, Geoff Clare  wrote:
> > I wrote, on 04 Sep 2010:
> >>
> >> Eric Blake  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.