[blfs-support] Comment/Question/Flame on "probably the most used admin tool", 'find'
alupu01 at gmail.com
Thu Nov 7 13:02:43 PST 2013
WARNING - this is a lengthy post. Can be safely skipped.
In my previous posts, I expressed my puzzlement/sadness about a construct
# Gimme the files modified in the range between n and m minutes ago
find -mmin -n -mmin +m
not working for me.
As always, Bruce showed me that a problem (any problem) is with me and not
with the system.
However, I'd had a nagging suspicion about my problem being related to the
change (and not really with me, in _this_ particular case) so I decided to
pursue the subject further.
Now I think I know more. I'm a little late with the results but I was busy
with some other nonsense lately. I apologize for the tardiness.
FWIW, here it is the full story, in gory details.
In truth, I didn't use the 'find' construct above "nakedly". It's actually
at the end
of a bash wrapper where I first convert dates and times to minutes ago, and
then, finally, I plug into the 'find' line the "n" and "m" numbers.
This wrapper, "findfiles", started failing on me, kinda all of a sudden
the initial, not well thought-out, stream-of-consciousness post):
% ls -l temp1.txt
2013-11-04 18:26 temp1.txt
% findfiles 2013-11-04 18:25 18:27
2013-11-04 18:26 temp1.txt # OK
% ls -l temp2.txt
2013-11-03 18:26 temp2.txt
% findfiles 2013-11-03 18:25 18:27
# no output
% findfiles 2013-11-03 19:25 19:27 # but with "19:25 19:27" ?!
2013-11-03 18:26 temp2.txt # OK ????
I think I have the whole story finally, still not pretty, not easy to deal
and not really 'find's fault, but at least I can present it for all to
I've written a little "demo" applet, "hrs2date" (in the spirit of my wrapper
mentioned) which gives you the hours (NOT minutes; for clarity) from this
moment to a past midnight date.
It's shown at the bottom (like for a top post - might be frowned on by
very straightforward, no error checking, as simple as I could think of
(I could've written the whole programme in Haskell but I thought better of
especially as I don't know anything about the language; however, I'm
Haskell handles time changes automatically - behind the scenes - in stride,
like anything else).
"hrs2date" is in the public domain so it can be viewed, used, modified,
out the window, etc., by anybody - including my friends.
A sample output:
Thu Nov 7 13:05:10 EST 2013
% hrs2date 2013-11-07
toDATEhrs = 13
% hrs2date 2013-11-06
toDATEhrs = 37
% hrs2date 2013-11-05
toDATEhrs = 61
% hrs2date 2013-11-04
toDATEhrs = 85
% hrs2date 2013-11-03
toDATEhrs = 110 # Oops! 110 - 85 = 25, NOT 24 !!!
% hrs2date 2013-11-02
toDATEhrs = 134
Note: the time change (DST to EST) was effected at 2AM, Nov. 3 here,
whereby everybody had to move their clocks one hour back - like to 1AM.
The problem I see is with this crazy time-change habit the world got into
This makes it more difficult to compute time (in minutes) to an event if
there was a time change somewhere (as we all have read in the press, some
people also complain about medical problems related to this back and forth
time changes; I'm fine in this respect. Or am I? ).
BTW, I strongly suspect global warming has something to do with the problem
as well and, as a consequence, will make it worse if we refuse to do
about it. But I leave that for the scientists to make the final decision.
Unfortunately, unless somebody can give me a SIMPLE ("if" - type) formula
accounts for a time change in my little bash wrapper, I'll do the
calculations with pencil and paper like in the old days from now on.
if [ "$1" == "" ]; then
# for people who didn't read my post
echo "Enter a date (yyyy-mm-dd)" ; exit 2
NOWsecs=`date +%s` # This moment (in sec. since Jan. 1,
DATEsecs=`date -d $DATE +%s` # DATE's seconds since Jan. 1, 1970
toDATEsecs=$(( $NOWsecs - $DATEsecs ))
toDATEhrs=$(( $toDATEsecs / 3600 )) # damn the minutes.
echo toDATEhrs = $toDATEhrs
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the blfs-support