GNOME Bugzilla – Bug 326093
Parsing atq on Ubuntu Dapper fails (patch in CVS already)
Last modified: 2006-02-04 08:43:57 UTC
Gaute, can you check my latest addition in CVS HEAD with your version if atq. The regular expression parsing atq was inacurate for the at version as installed on Ubuntu Dapper. pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule$ cvs diff -r 1.124 ChangeLog Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-schedule/ChangeLog,v retrieving revision 1.124 retrieving revision 1.125 diff -r1.124 -r1.125 0a1,4 > 2006-01-07 Philip Van Hoof <pvanhoof@gnome.org> > > * src/at.py: Fixed atq parsing on Ubuntu Dapper > pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule$ Close the bug if it works on a few systems and/or at version. But do keep an eye on it. If the atq output format changed, we might have to start supporting multiple versions or start talking with it's authors.
Doesn't work here. Warning: a line in atq's output didn't parse gaute@eple:~/Prosjekt/GNOME/gnome-schedule/src$ atq 16 2006-01-08 13:01 a gaute
slackware-10.2 at-3.1.8-i486-2
Right, I see. Your atq output is completaly different (the date format is different). pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule$ at tomorrow warning: commands will be executed using /bin/sh at> ls at> <EOT> job 7 at Sun Jan 8 13:01:00 2006 pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule$ atq 7 Sun Jan 8 13:01:00 2006 a pvanhoof pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule$ Trying to fix it, gimme a second ;-)
This work for you? new revision: 1.89;
Yes this works. It would be nice if we could talk to the developers and check wheter this is just a very seldom format change, isn't there any POSIX standards for this? Anyway, we have to support both versions now, since it has allready been released.
The regex is: ([^\s]+)\s((.*)\s(..:..:..\s....)|([^\s]+)\s([^\s]+))\s([^\s]+)\s([^\s]+) for "7 Sun Jan 8 13:01:00 2006 a pvanhoof" and "16 2006-01-08 13:01 a gaute" It might be a locale setting. We can, of course, check the sources to check why our at versions differ in atq's output.
pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule/src$ at -V at version 3.1.9 Bug reports to: rmurray@debian.org (Ryan Murray) Garbled time pvanhoof@lort:~/repos/cvs/gnome/gnome-schedule/src$
2006-01-08 isn't my locale. Your format is more of the standard way of outputting it really, so it might be the new way? anyway got to go now, check back later on.
gaute@eple:~$ at -V at version 3.1.8 Bug reports to: ig25@rz.uni-karlsruhe.de (Thomas Koenig) Garbled time
It looks like this is the opensolaris implementation. Check out the printdate function. It's not using locale-specific functions and formatting string "%3s %2d, %4d %02d:%02d". http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/cron/atq.c. Not sure what at implementation is typically being used on GNU/Linux and where to find it's sources (at gnu.org, perhaps?).
Okay. So, let's at least keep an eye on this one. Perhaps making it more easy to report parsing problems by outputting the line and warning visually (a popupable messagebox with a listbox with problematic lines? It shouldn't bug the user constantly, but it should be easy to report such problems).
Man page of 3.1.8 says: ... Times displayed will be in the format "1997-02-20 14:50" unless the environment variable POSIXLY_CORRECT is set; then, it will be "Thu Feb 20 14:50:00 1997". ... So we should set POSIXLY_CORRECT when calling atq.
BTW: Perhaps it's easier and cleaner to use time.strptime and time.strftime instead of a regexp to parse this.
It doesn't really help us that much since we have to specify the format ourself, but it could be useful for value checking. Anyway, I think it would be easier to set or unset the POSIXLY_CORRECT variable on startup. Is it clear that there are only these two formats that are used?
(In reply to comment #14) > Anyway, I think it would be > easier to set or unset the POSIXLY_CORRECT variable on startup. Is it clear > that there are only these two formats that are used? We should make sure gnome-schedule only uses POSIXLY_CORRECT readings from atq. I'm currently at work and have a HP-UX at hand. Sample output of "at -l" on HP-UX: 1136658280.a Sat Jan 7 19:24:40 2006 Next thing: HP-UX implementation of at doesn't provide atq and atrm. We should use "at -l" respectively "at -r" and drop configure checks for atq and atrm. Although I can't use gnome-schedule here, it would be a more generic approach.
(In reply to comment #15) > Next thing: > HP-UX implementation of at doesn't provide atq and atrm. We should use "at -l" > respectively "at -r" and drop configure checks for atq and atrm. Although I > can't use gnome-schedule here, it would be a more generic approach. Forget about this one. I've investigated a little bit more. We can't support HP-UX or IRIX implementations for following reasons: HP-UX: Isn't conform with newer POSIX standards. It uses "at -d [jobid]" for displaying job contents. According to ISO POSIX (2003) this should delete the job. The displayed date format depends on locale settings. IRIX: This one doesn't even provide the functionality to display job contents. Depends on locale settings too. With C locale the "at -l" output is exactly the same as HP-UX. Thus we should check for atq and atrm to be sure we have the at implementation that is currently maintained by Debian. MacOSX and other BSDs are using it anyway. OpenSolaris seems to be at least compatible with it. Sorry for the noise...:)
(In reply to comment #16) > (In reply to comment #15) > > Next thing: > > HP-UX implementation of at doesn't provide atq and atrm. We should use "at -l" > > respectively "at -r" and drop configure checks for atq and atrm. Although I > > can't use gnome-schedule here, it would be a more generic approach. > > Forget about this one. I've investigated a little bit more. We can't support > HP-UX or IRIX implementations for following reasons: > > HP-UX: Isn't conform with newer POSIX standards. It uses "at -d [jobid]" for > displaying job contents. According to ISO POSIX (2003) this should delete the > job. The displayed date format depends on locale settings. > > IRIX: This one doesn't even provide the functionality to display job contents. > Depends on locale settings too. With C locale the "at -l" output is exactly the > same as HP-UX. So the current implentation isn't compatible with these systems. This is a bit bad, but is there really a way to do this? put a flag in the configure script or something and define something in config.py? > > Thus we should check for atq and atrm to be sure we have the at implementation > that is currently maintained by Debian. MacOSX and other BSDs are using it > anyway. OpenSolaris seems to be at least compatible with it. Like we are doing now :) I think it works ok on mac, check bug 325951 and bug 325955.
> So the current implentation isn't compatible with these systems. This is a bit > bad, but is there really a way to do this? put a flag in the configure script > or something and define something in config.py? I wouldn't care about this. If someone really wants it on those Unixes, it should be possible to install the Debian at. The systems I have access to are running Motif as WM, so Debian at would be the smallest missing dependancy... ;) > > MacOSX and other BSDs are using it > > anyway. OpenSolaris seems to be at least compatible with it. > > Like we are doing now :) I think it works ok on mac, check bug 325951 and bug > 325955. Yeah, have seen them. From deeper looking at OpenSolaris sources it seems to behave a bit different. For instance it adds an header to atq and uses a different format. But I don't have a running system... we should wait until someone requests it. Perhaps you could make a note on the website and the README.
(In reply to comment #18) > > So the current implentation isn't compatible with these systems. This is a bit > > bad, but is there really a way to do this? put a flag in the configure script > > or something and define something in config.py? > > I wouldn't care about this. If someone really wants it on those Unixes, it > should be possible to install the Debian at. The systems I have access to are > running Motif as WM, so Debian at would be the smallest missing dependancy... > ;) Allright, that is settled then. No more efforts to do this. Are they or 'regular' at following POSIX?
> Allright, that is settled then. No more efforts to do this. Are they or > 'regular' at following POSIX? Don't know exactly, and don't feel like buying the POSIX papers... ;) IRIX supports XBD standard. http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/at.z HP-UX supports SVID2, SVID3, XPG2, XPG3, XPG4. http://docs.hp.com/en/B2355-60105/at.1.html Linux Standard Base: http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/at.html
Seems like this works.