Possible enhancement to find(1)

[Paul Goyette]

I often find myself (no pun intended!) wanting to determine which files
were accessed before/since a particular timestamp. There currently
exist the -{a,c}{newer,min,time} primitives, but none of these allow me
to say "since today at 5 AM".

I'd like to suggest adding new primitives

-asince "timestamp"
-csince "timestamp"

where the timestamp argument would be converted to an actual time using
parsedate(3).

Does anyone else think this is a good idea? Is there anyone who would
object to adding these primitives?



+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+

[Martin Husemann]

On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote:
> I'd like to suggest adding new primitives
>
> -asince "timestamp"
> -csince "timestamp"
>
> where the timestamp argument would be converted to an actual time using
> parsedate(3).
>
> Does anyone else think this is a good idea? Is there anyone who would
> object to adding these primitives?

Yes, that looks good (I use "touch -d ... /tmp/mark" quite often for this,
avoiding the temporary file would be great).

Martin

[Paul Goyette]

Exactly!

I'll get started on the changes tomorrow.

[Thomas Klausner]

On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote:

> I often find myself (no pun intended!) wanting to determine which files were
> accessed before/since a particular timestamp. There currently exist the
> -{a,c}{newer,min,time} primitives, but none of these allow me to say "since
> today at 5 AM".
>

> I'd like to suggest adding new primitives
>
> -asince "timestamp"
> -csince "timestamp"
>
> where the timestamp argument would be converted to an actual time using
> parsedate(3).
>
> Does anyone else think this is a good idea? Is there anyone who would
> object to adding these primitives?

No, but can you please check some other operating systems/GNU tools if
they have some option like that and match the name, if possible?
Thomas

[Paul Goyette]

I've checked both FreeBSD and OpenBSD and they don't seem to have done
anything similar. At least, no mention in their man pages.

Does anyone have suggestions and web-sites for a couple of linux
distros? I'm not going to check them all... :)

[Roy Marples]

On 10/06/2016 10:03, Paul Goyette wrote:
> Does anyone have suggestions and web-sites for a couple of linux
> distros? I'm not going to check them all... :)

http://man7.org/linux/man-pages/man1/find.1.html

Quite a few time related options.

Roy

[Simon Burge]

Paul Goyette wrote:

> I often find myself (no pun intended!) wanting to determine which files
> were accessed before/since a particular timestamp. There currently
> exist the -{a,c}{newer,min,time} primitives, but none of these allow me
> to say "since today at 5 AM".
>
> I'd like to suggest adding new primitives
>
> -asince "timestamp"
> -csince "timestamp"
>
> where the timestamp argument would be converted to an actual time using
> parsedate(3).

And -msince ?

>
> Does anyone else think this is a good idea? Is there anyone who would
> object to adding these primitives?

Sounds useful!

Cheers,
Simon.

[Paul Goyette]

On Fri, 10 Jun 2016, Simon Burge wrote:

> Paul Goyette wrote:
>
>> I often find myself (no pun intended!) wanting to determine which files
>> were accessed before/since a particular timestamp. There currently
>> exist the -{a,c}{newer,min,time} primitives, but none of these allow me
>> to say "since today at 5 AM".
>>
>> I'd like to suggest adding new primitives
>>
>> -asince "timestamp"
>> -csince "timestamp"
>>
>> where the timestamp argument would be converted to an actual time using
>> parsedate(3).
>
> And -msince ?

Yes, I got that one, too! :)

[Paul Goyette]

Yup - including -daystart

This is basically the same as GNU findutils, which does not have the
functionality that I'm adding.

Thanks for the pointer.

[Robert Elz]

Date: Fri, 10 Jun 2016 16:06:42 +0800 (PHT)
From: Paul Goyette <pa...@whooppee.com>
Message-ID: <Pine.NEB.4.64.16...@pokey.whooppee.com>

| > On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote:

| >> I'd like to suggest adding new primitives
| >>
| >> -asince "timestamp"
| >> -csince "timestamp"

| I'll get started on the changes tomorrow.

But add all 3 (useful) inode times, not just 2 of them (you can
ignore birthtime, as does almost everything else, that's a waste
of inode space)

Along with -{a,c}{newer,min,time} there is also -mmin -mtime and -newer
(and yes, slight pity that the naming is not all consistent, but -newer
has been there much longer than the others).

kre

[Paul Goyette]

On Fri, 10 Jun 2016, Robert Elz wrote:

> Date: Fri, 10 Jun 2016 16:06:42 +0800 (PHT)
> From: Paul Goyette <pa...@whooppee.com>
> Message-ID: <Pine.NEB.4.64.16...@pokey.whooppee.com>
>
> | > On Fri, Jun 10, 2016 at 02:18:16PM +0800, Paul Goyette wrote:
> | >> I'd like to suggest adding new primitives
> | >>
> | >> -asince "timestamp"
> | >> -csince "timestamp"
>
> | I'll get started on the changes tomorrow.
>
> But add all 3 (useful) inode times, not just 2 of them (you can
> ignore birthtime, as does almost everything else, that's a waste
> of inode space)

yeah Birth is useless. :)

> Along with -{a,c}{newer,min,time} there is also -mmin -mtime and -newer
> (and yes, slight pity that the naming is not all consistent, but -newer
> has been there much longer than the others).

It was my intent to also add -since (for consistency with -newer). I
_knew_ there was another one, I simply missed it the first time around.

[Paul Goyette]

On Fri, 10 Jun 2016, Robert Elz wrote:

> Date: Fri, 10 Jun 2016 17:03:35 +0800 (PHT)

> From: Paul Goyette <pa...@whooppee.com>
> Message-ID: <Pine.NEB.4.64.16...@pokey.whooppee.com>
>

> | Does anyone have suggestions and web-sites for a couple of linux
> | distros? I'm not going to check them all... :)
>

> I'd assume they all use the find that's in the gnu findutils which is
> in pkgsrc (sysutils/findutils)
>
> But from a man page on a real linux system...
>
> -newerXY reference

Yeah, I noticed this, too, on findutils...

This is ugly.

If you want the linux variation, go install findutils from pkgsrc. :)

I'm willing to add the -{a,c,m}since options (or -{a,c,}since) with
parsing of the timestamp via parsedate(3), but I'm not going to copy
findutils.


> The -d option of gnu date is essentially the same as in NetBSD date -d
> (though I wouldn't guarantee that our parsedate() always produces the
> same results as theirs - in fact it almost certainly doesn't).

I insist on using parsedate(3) since I want these to work:

find .... -asince "3 days ago"
find .... \! -since "last monday"


> Note that that man page extract is useless, and leaves you guessing (which
> is what I did) as to what this thing actually means! The text suggests that
> both X and Y relate to the reference time, but that would make no sense at
> all. I deduce that X is the inode time to check in the current file, and
> Y is the reference time, as X==t is invalid.

It's the only interpretation that comes close to making sense.


Anyway, I don't really care one way or the other. I'll make my changes
locally, and I'll get what I want. If others want to use findutils,
they know where to get it; if others want my changes, ask for them.

I just won't commit them without some sort of indication of consent.
(Just like my changes re resurrecting the ksem module, discussed last
year...)

[Robert Elz]

Date: Fri, 10 Jun 2016 17:03:35 +0800 (PHT)
From: Paul Goyette <pa...@whooppee.com>
Message-ID: <Pine.NEB.4.64.16...@pokey.whooppee.com>

| Does anyone have suggestions and web-sites for a couple of linux
| distros? I'm not going to check them all... :)

I'd assume they all use the find that's in the gnu findutils which is
in pkgsrc (sysutils/findutils)

But from a man page on a real linux system...

-newerXY reference

Compares the timestamp of the current file with reference. The
reference argument is normally the name of a file (and one of
its timestamps is used for the comparison) but it may also be a
string describing an absolute time. X and Y are placeholders
for other letters, and these letters select which time belonging
to how reference is used for the comparison.

a The access time of the file reference
B The birth time of the file reference
c The inode status change time of reference
m The modification time of the file reference
t reference is interpreted directly as a time

Some combinations are invalid; for example, it is invalid for X
to be t. Some combinations are not implemented on all systems;
for example B is not supported on all systems. If an invalid or
unsupported combination of XY is specified, a fatal error
results. Time specifications are interpreted as for the arguâ€
ment to the -d option of GNU date. If you try to use the birth
time of a reference file, and the birth time cannot be deterâ€
mined, a fatal error message results. If you specify a test
which refers to the birth time of files being examined, this
test will fail for any files where the birth time is unknown.

which I think means that -newerat -newerct and -newermt are the three
options you're considering adding (please forget birthtime!) Other than
the B cases, adding the full set wouldn't hurt I guess (-newerXX is the
same as the existing -Xnewer of course, except where X==m when it is
just -newer)

The -d option of gnu date is essentially the same as in NetBSD date -d
(though I wouldn't guarantee that our parsedate() always produces the
same results as theirs - in fact it almost certainly doesn't).

Note that that man page extract is useless, and leaves you guessing (which
is what I did) as to what this thing actually means! The text suggests that
both X and Y relate to the reference time, but that would make no sense at
all. I deduce that X is the inode time to check in the current file, and
Y is the reference time, as X==t is invalid.

kre

[Paul Goyette]

> Anyway, I don't really care one way or the other. I'll make my changes
> locally, and I'll get what I want. If others want to use findutils, they
> know where to get it; if others want my changes, ask for them.
>
> I just won't commit them without some sort of indication of consent. (Just
> like my changes re resurrecting the ksem module, discussed last year...)

If anyone wants them, the diffs are attached.

[Robert Elz]

You added -since but documented -msince in the man page.

If you were also to add

{ "-newerat", N_ASINCE, c_asince, 1 }, /* gnu find compat */
{ "-newerct", N_CSINCE, c_csince, 1 },
{ "-newermt", N_SINCE, c_since, 1 }, /* ung */

in the appropriate place, you'd have something that was command line
compatible with gnu findutils, so scripts written for that find, which
only use facilities actually implemented here, would work.

Would that really be such an evil thing?

kre

[Paul Goyette]

On Sat, 11 Jun 2016, Robert Elz wrote:

> You added -since but documented -msince in the man page.

I think I just fixed that in my local copy. wiz@ pointed it out.

> If you were also to add
>
> { "-newerat", N_ASINCE, c_asince, 1 }, /* gnu find compat */
> { "-newerct", N_CSINCE, c_csince, 1 },
> { "-newermt", N_SINCE, c_since, 1 }, /* ung */
>
> in the appropriate place, you'd have something that was command line
> compatible with gnu findutils, so scripts written for that find, which
> only use facilities actually implemented here, would work.
>
> Would that really be such an evil thing?

For me, yes. I will not implement the ugly gnu stuff, neither in its
entirety nor partially.

[James K. Lowden]

On Fri, 10 Jun 2016 14:18:16 +0800 (PHT)
Paul Goyette <pa...@whooppee.com> wrote:

> I'd like to suggest adding new primitives
>
> -asince "timestamp"
> -csince "timestamp"

I'd just like to suggest that, instead of adding new primitives, allow
the existing primitives to take a parsable string. Rules:

1. argument to amin & friends is first passed to stat(2). If it's a
filename, current behavior ensues.

2. If stat(2) returns an error, the argument is passed to
parsedate(3). If that succeeds, it is used as a time instead.

3. Else error.

The user would need to take care, in the odd case, that the timestring
didn't *exactly* match a filename. In the normal case the user could
say,

-amin 10:12pm

but if there were a file named "10:12pm", he could use

-amin '10:12 pm'

or any similar variation instead. The likelihood of ambiguity is both
small and mitigated by the use of tab-completion.

A different disambiguation rule would be further from current practice,
but equally practical: If the argument is both a valid datestring and a
filename, treat as a string. To disambiguate, the user could extend
the pathname, or perhaps use a (single) new primitive to indicate
mode of interpretation.

IMO it's harder to remember options than arguments. Instead of
distinguishing in his mind between "time" and "since", neither of which
imply "inode" or "string", it would be better to make the argument
richer, and give the user an out to deal with the odd ambiguous case.

Regards,

--jkl

[Paul Goyette]

On Sat, 11 Jun 2016, Paul Goyette wrote:

> On Sat, 11 Jun 2016, Robert Elz wrote:

>> ...

>> If you were also to add
>>
>> { "-newerat", N_ASINCE, c_asince, 1 }, /* gnu find
>> compat */
>> { "-newerct", N_CSINCE, c_csince, 1 },
>> { "-newermt", N_SINCE, c_since, 1 }, /* ung */
>>
>> in the appropriate place, you'd have something that was command line
>> compatible with gnu findutils, so scripts written for that find, which
>> only use facilities actually implemented here, would work.
>>
>> Would that really be such an evil thing?
>
> For me, yes. I will not implement the ugly gnu stuff, neither in its
> entirety nor partially.

Well, I've been convinced by several off-list exchanges that it's really
not so bad to implement the gnu stuff after all.

We only have to implement gnu-equivalents for the functionality that we
already have - so we don't have to implement comparisons of differing
attributes (ie, a found file's atime vs the reference file's mtime).
The man-page for findutils clearly states that not all combinations need
to be provided.

I've restructured the existing code a bit, so that the parsing code
provides each option's argument parser with the actual option name;
this allows us to use the same argument parsing routines for the "alias"
options as for the "real" options.

New diffs are attached. These include lists of the findutils -newerXY
options which remain unimplemented.

Comments are welcomed - even though I might at first reject them, I do
eventually consider them. :)