On 08/04/2005 03:57:10 AM, Emiliano Castagnari wrote:
You could try something like: $ command1 && command2 && command3
Better would be command1 ; command2 ; command3, because then it won't depend on the previous command coming out true. But nevertheless it lacks the ability for me to add and remove commands from the queue after it's started, which is almost the main feature that I need.
Basically it would be good enough if "at" could do "at -next", which would run the job after any that were already running completed.
The "batch" command is good but bases whether or not to do a job on cpu load levels, whereas I'm looking for the same but for disk load levels.
Another way, is to simply develop it ... it doesn't seem like a very hard one to code :)
This may be true. It might be easiest to do it as an addition to "at", since all the spooling logic and daemon is already there.... I can't code worth a damn, but maybe I could swing altering "batch" to monitor disk load levels instead...if only there was a general disk load monitor that was as reliable as loadavg...
Or perhaps "at -next" would be easier. Instead of looking at the time, look if a job is running - if one is, postpone the job by a few minutes.
- : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
