Re: soliciting opinions about potential new cron/at features.

[Roderick Schertler <roderick@argon.org>]

On 23 Feb 1999 13:32:42 -0600, Rob Browning <rlb@cs.utexas.edu> said:
>
> Given that, and the (simpler) modification to at I proposed (the addition
> of optional unique job id's), I think I could have a workable solution.

It's better than that, the change you proposed isn't required.  You'd
said

> Right now you only get an integer that I don't think is guaranteed to
> be unique across invocations/removals/reboots, etc.

but that's not true, the id that at prints is unique.  The is by
definition, the id is meant to allow you to remove the job with
atrm.  This obviously wouldn't work if the same id could refer to
multiple jobs.  The current Linux implementation uses integers which
are incremented for each job, but they aren't reused after reboots
(the last number used is stored in a file under /var/spool/cron
somewhere).

The real ugly part about this is that you've got to parse at's stderr in
order to get the id.  (Let alone for now that this informational message
is on stderr rather than stdout, this design bug looks to be widespread
and historic.)  Also, the format varies.  Here's what it looks like on
the systems I have handy:

    Linux:
	warning: commands will be executed using /bin/sh
	job 43 at 1999-02-25 13:15

    SCO:
	warning: commands will be executed using /bin/sh
	job 920049300.a-18260:0 at Fri Feb 26 13:15:00 1999

    DGUX:
	UX:at: WARNING: Commands will be executed using /usr/bin/sh
	UX:at: INFO: Job 919966501.a at Thu Feb 25 13:15:00 1999

-- 
Roderick Schertler
roderick@argon.org