Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!ittvax!dcdwest!sdcsvax!sdcrdcf!hplabs!sri-unix!jpm@BNL.ARPA From: jpm@BNL.ARPA Newsgroups: net.unix-wizards Subject: Bugs in the at command - summary Message-ID: <1336@sri-arpa.UUCP> Date: Wed, 27-Jun-84 15:20:05 EDT Article-I.D.: sri-arpa.1336 Posted: Wed Jun 27 15:20:05 1984 Date-Received: Sat, 30-Jun-84 07:13:57 EDT Lines: 70 A few weeks ago I asked if anybody knew of bugs in the "at" command. I got three responses which I am including below. Sorry for not posting this sooner but this site has been having problems and every time I get ready to create a summary something goes wrong (the editor breaks, the disk breaks, the Arpanet breaks, etc.). Date: Sun, 17 Jun 84 2:56:10 EDT From: Doug Gwyn (VLD/VMB) To: jpm@bnl.arpa Subject: Re: bug in at command UNIX System III and V do not have an "at" command. UNIX System V Release 2 provides "user cron tables" which is the same sort of facility but totally redone. ---- From: philabs!decvax!tektronix!jerryp Date: Monday, 18 Jun 84 08:08:01 PDT To: decvax!philabs!sbcs!bnl!jpm, jerryp Subject: Re: bug in at command John, We have BSD here, so I'm not sure... but I've heard that the bug involves quoting of the environment variables in the /usr/spool/at/* file. In other words, our version (BSD) of "at" puts statements like this in the /usr/spool/at/* file: SYSPATH='/usr3/jerryp/.bin /usr/local /usr/tek /usr/ucb /bin /usr/bin' I heard that the bug in other versions of "at" is that they don't quote the variable strings. In other words, the file would have SYSPATH=/usr3/jerryp/.bin /usr/local /usr/tek /usr/ucb /bin /usr/bin ...and, when atrun tries to execute the /usr/spool/at/* file, and the shell reads a line like that, with blanks, it chokes. --Jerry Peek, UNIX Training Instructor, Tektronix, Inc. uucp: {allegra,decvax,hplabs,ihnp4,mit-eddie,ucbvax}!tektronix!jerryp ARPAnet: jerryp.tek@csnet-relay ---- Date: Mon, 18 Jun 84 22:22:23 edt From: yba@mit-athena (Mark H Levine) To: jpm@BNL.ARPA Subject: Re: bug in at command The bug I am most fond of in "at" is that it did not quote shell variables in the generated script. In more detail: Say your prompt is set to the character greater-than, ">". You run an "at" command creating a file in /usr/spool/at that begins: PS1=> which causes a syntax error in the shell, and the at file dies quickly and quietly having done nothing. A fix to this was to force quoting of all arguments which were invisibly set for the user in order to guarantee the "at" command ran in the same environment in which the request was made, that is the above would begin: PS1=">" ----