<div dir="ltr">Attached is the updated patch.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 12:33 AM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 09/18/14 05:38, Ashwini Sharma wrote:<br>
> Hi Rob,<br>
<br>
Hi. Your last round of fixes (which I've applied a little over half of)<br>
touched some of the files needing cleanup outside of the pending<br>
directory. (I.E. command contributions that predated "pending".) I<br>
updated the toys/pedning/README file listing them (so it's not just my<br>
private list), and have been looking at a few. (Yesterday it was "touch"<br>
and "cut" I think.)<br>
<span class=""><br>
> Attached are the patches. This has fixes for<br>
><br>
> touch:<br>
> 1. while setting access or modify times of a file, this was causing a<br>
> hang due to non-increment of ss.<br>
<br>
</span>I actually have more fixes to touch pending: the logic is wrong for file<br>
create. I think if you combine "touch -a -d" when creating a file, it<br>
should set the access time to what you specified with -d but leave the<br>
modification time at the current (creation) time? I need to read the<br>
spec and test what the ubuntu version does.<br>
<br>
Query: this patch replaces the stanza I just took _out_ that tries to<br>
work around a libc bug. Which libc is having the problem?<br>
<br>
Does the for loop not work?<br></blockquote><div>2 use cases here.</div><div><br></div><div>1. update access or modify time one at a time. </div><div>__fetch()__ was checking for __TT.file__ instead of input parameter __file__. Failure </div><div>here as TT.file = NULL, causes a jump to open statement in loop. Success here results in endless loop.</div><div><br></div><div>2. file to be touched is existing and owned by other user.</div><div> In this open(O_CREAT) did succeed, but utimes() fail returning EPERM. Again the endless loop.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> 2. handling the time format for __-d__ option as per the spec<br>
> (<a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html" target="_blank">http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html</a>).<br>
<br>
</span>The majority of this patch affects the -t case, not the -d case?<br></blockquote><div><br></div><div>for -d case, it is taking into account the UTC time zone. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- strcpy(toybuf, "%Y%m%d%H%M");<br>
date = TT.time;<br>
- for (i=0;i<3;i++) {<br>
- s = strptime(date, toybuf+(i&2), &tm);<br>
- if (s) break;<br>
- toybuf[1]='y';<br>
- }<br>
+ i = ((s = strchr(date, '.'))) ? s-date : strlen(date);<br>
+ if (i == 8) strcpy(toybuf, "%m%d%H%M");<br>
+ else if (i == 10) strcpy(toybuf, "%y%m%d%H%M");<br>
+ else if (i == 12) strcpy(toybuf, "%Y%m%d%H%M");<br>
+ else perror_exit("bad '%s'", date);<br>
+<br>
if (s && *s=='.') {<br>
- int count = sscanf(s, ".%2d%u%n", &(tm.tm_sec), &i, &len);<br>
-<br>
- if (count==2) tv->tv_usec = i;<br>
- s += len;<br>
+ if ((sscanf(s+1, "%2u%n", &(tm.tm_sec), &i) != 1) || *(s+i+1))<br>
+ error_exit("bad '%s'", date);<br>
+ s += (i+1);<br>
<br>
Where did the call to strptime go? This new code seems to set up toybuf<br>
(using three separate strings instead of three cases on one string), and<br>
then... not call strptime? I'm confused...<br>
<br></blockquote><div>my bad, attached is the updated patch. I preferred if..else over loop calling strptime() 3 times. Though the loop is kept intact now.</div><div><br></div><div>__for__ loop works fine, but as per spec it should accept [[CC]YY]mmddMMHH[.SS], all the fields in pairs of two digits.</div><div>strptime() doesn't care for this two digit format, leading '0' may or may not be there.</div><div>Finally [.SS] can be in the range [00, 60] and no further fractions. </div><div>sscanf(".%2d%u%n") would fail when input is like "1910200240.24" or "1910200240." (Segfault) </div><div>as len is not updated properly and s is advanced by the same.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
(Yesterday I was looking at whether or not I could combine the date<br>
parsing logic there with the stuff in "date". The answer is currently<br>
"no", but I want to give it another look...)<br>
<br>
Have to answer the rest later, errand...<br>
<span class=""><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div><br></div></div>