cvs commit: src/usr.bin/touch touch.1 touch.c
Greg 'groggy' Lehey
grog at FreeBSD.org
Tue Apr 10 01:05:13 UTC 2007
On Monday, 9 April 2007 at 2:48:26 -0700, Brian Somers wrote:
> On Mon, 9 Apr 2007 02:19:42 +0000 (UTC) Greg Lehey <grog at FreeBSD.ORG> wrote:
>> grog 2007-04-09 02:19:37 UTC
>> FreeBSD src repository
>> Modified files:
>> usr.bin/touch touch.1 touch.c
>> Add -A flag to adjust existing time stamps.
>> diff -u src/usr.bin/touch/touch.1:1.14 src/usr.bin/touch/touch.1:1.15
>> --- src/usr.bin/touch/touch.1:1.14 Sun Feb 13 22:25:24 2005
>> +++ src/usr.bin/touch/touch.1 Mon Apr 9 02:19:37 2007
>> +.It Fl A
>> +Adjust the access and modification time stamps for the file by the
>> +specified value.
>> +This flag is intended for use in modifying files with a time stamp
>> +relative to an incorrect time zone.
> I don't understand what this means. File times are in UTC aren't
No, they're in time_t. But if you import files from other systems,
you frequently get times which are off by some time zone offset.
The case in point is that when importing files from digital cameras,
it's frequently impossible to get the correct time. Many cameras are
too stupid to handle time zones at all and assume it's UTC. Those
that can make a typically US assumption that all time zones are on the
hour. Here in South Australia, for example, we have a time zone
offset of +0930, which seems to blow the minds of most cameras. In my
case, I have a Canon that fits the first category, and a Nikon that
fits the second.
>> +The argument is of the form
>> +.Dq [-][[hh]mm]SS
>> +where each pair of letters represents the following:
>> +.Bl -tag -width Ds -compact -offset indent
>> +.It Ar -
>> +Make the adjustment negative: the new time stamp is set to be before
>> +the old one.
>> +.It Ar hh
>> +The hour of the day, from 00 to 23.
>> +.It Ar mm
>> +The minute of the hour, from 00 to 59.
>> +.It Ar SS
>> +The second of the minute, from 00 to 59.
> Why this format?
It's basically a simplification of the format that touch(1) uses to
> My guess is that the delta is expected to be a DST difference, but
> if it is, I'm even more confused.
Yes, that seems confusing. For the +1030 time difference that I had
to contend with on Sunday, you'd write -103000 (HHMMSS).
But why limit it to exact time zone offsets? How accurate is the
clock in your digital camera? Did you reset it when the clocks went
forward a couple of weeks ago? Also, currently there is no time zone
anywhere in the world that is +1030.
I've just checked my camera and discovered that it said 10:01 when in
fact the time was 9:23. That's one hour for forgetting to put the
clock back, compensated for by it having lost 22 minutes since last
set. If I put a time zone in there, rather than an exact offset, I'd
be restricting the functionality.
>> +When used in conjunction with the
>> +.Fl a
>> +flag only, the modification time is adjusted by the time specified as
>> +argument to the
>> +.Fl A
>> +flag, while the access time is modified from the base time described
> Wow. So -A changes both times in addition to the
> access-only time change. This is really unintuitive
> to me. I'd expect ``-A 000001 -a' to adjust the access
> time only (as -a previously meant). I wouldn't expect
> the modification time to be bumped by a second and the
> access time to be set to one second in the future.
> But again, I don't know why you'd want to do this...
I can't see any earthly reason to use -m or -a in conjunction with -A.
I was simply documenting what would happen. But see below.
>> +If the file does not exist, and creation is allowed,
>> +.Fl A
>> +does not change its time stamps.
> So if I ``touch -A 000001 something'' where ``something''
> doesn't already exist, the file is created and the time
> is left at now? That's also confusing.
What would you set it to? I was thinking of prohibiting the use of -c
altogether, since it doesn't make sense. What do you think?
>> - aflag = cflag = fflag = mflag = timeset = 0;
>> + myname = argv;
> myname should be set to the base name, not the full argv.
OK. Will change.
> I personally think this option is a mistake. I would
> think that something like this would be better:
> [-A adjust] - adjust the updated time(s) by the given
> ``adjust'' number of seconds.
Then you're asking people to calculate the number of seconds. Why? I
suppose you could add a second format. I was sorely tempted to write
HH:MM:SS, but that doesn't match the format for the -t option, which
is enshrined in POSIX.1.
> I would imagine this to be useful in (say) a test script that wanted
> to set up a bunch of files with time stamps set to specific relative
> But I'm clearly missing the point here...?
Is it clearer now?
After thinking about this, it's clear that the interaction between -A
on the one hand and -a and -m on the other is confusing. I'll change
it so that only the specified time stamps are changed under these
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20070410/f9d2be9d/attachment.pgp
More information about the cvs-src