Re: Possible enhancement to find(1)

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Fri, 10 Jun 2016 14:18:16 +0800 (PHT)
Paul Goyette <paul%whooppee.com@localhost> 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