hpr-knowledge-base/hpr_transcripts/hpr4637.txt

Episode: 4637
Title: UNIX Curio #6 - at and batch
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4637/hpr4637.mp3
Transcribed: 2026-07-31 16:15:39 (official HPR transcript)

---

This is Hacker Public Radio Episode 4637, for 2026-05-12
Today's show is entitled, "UNIX Curio #6 - at and batch"
The host is Vance and the duration is 00:11:06
The flag is Clean, and the license is CC-BY-SA
The summary is "Running a non-interactive job at a particular time, or just now"
Hi there, I'm Vance and welcome to Unix Curio number 6.
This series is dedicated to exploring little known and occasionally useful, trinkets lurking
in the dusty corners of Unix-like operating systems.
I would imagine that most users of Unix-like systems have heard of Cron, certainly any
system administrators should have.
Briefly, Cron is a way of running a job repeatedly based on the time and date.
For example, a job could run every hour at 5am every Tuesday or the third of each month.
It is commonly used for administrative or maintenance tasks that should be done on a regular
schedule, such as checking for software updates, rotating long files, or
updating the database for the locate command.
As well known as Cron is, there is a similar utility that very few seem to be aware of.
At, this is the word at spelled AT or in the phonetic alphabet, alpha tango, and has
nothing to do with the at symbol that appears above the numeral 2 on a U.S. Quarty keyboard.
An AT job is very much like a Cron job, except that an AT job only runs one time.
A job is submitted by running AT time spec where time spec is the time and date the job
is to be run.
The POSIX specification page linked from the show notes describes acceptable formats for time spec.
Some examples are now 1,400, noon tomorrow 1,400 plus 3 months and 1,400, January 19, 238.
The utility then waits on standard input for U2 enter a set of commands to be run in
the job.
You end input by typing control D to mark the end of text.
As an alternative to typing in the job, you could instead use the less than symbol to redirect
standard input to come from a file containing the commands you want to run.
When the specified time arrives, the job will be run.
It is the theory anyway, but some things may interfere.
The normal configuration for some implementations only checks for do AT jobs every 5 minutes,
so there can be a delay before the job is actually run.
Also if the system isn't running, obviously it can't execute any jobs.
When it comes back up, typically it will check for any pending AT jobs that are currently
or passed through and run those.
It is best to think about an AT job being run no earlier than the time it was scheduled
for and probably soon after provided the system is up.
The pause extandered doesn't specify anything about when jobs are actually run just
that they are scheduled for a particular date and time.
The user does not need to be logged in for a job to run.
If the job outputs anything to standard output or standard error, that text will be emailed
to the user, presuming the system is set up to send mail.
This is often true for a server which might be running a mail transfer agent like send
mail, postfix or xm, but many desktops are not.
If nothing is output to standard output or standard error, or if that output is redirected
to a file, then mail will not be sent on job completion.
This behavior can be changed with the hyphen m option that is mic in the phonetic alphabet.
In that case, mail will always be sent when the job finishes whether or not there is any
output.
The batch command is very similar.
Puzzles specifies it as being equivalent to at now with two differences.
First jobs are put into a different queue and second, mail is always sent when a job
completes as if the hyphen m option was used with at.
In practice, however, certain aspects of the behavior of batch depend on the implementation.
On the large majority of systems I investigated, but not all, batch jobs will only be run
when the system load level drops below a certain point.
This can typically be configured by the administrator, but has a default value.
The manual pages for a couple of systems don't actually list a default value and just say
batch shops will run quote when system load levels permit unquote.
Basing execution on the load level makes sense if the batch utility as seen as a way of running
potentially resource intensive jobs when the system is not being heavily used.
However, this behavior is not required by Puzzles.
Another question that the standard leaves unanswered is how Q's behave.
From the normal understanding of the word Q, you might expect that each successive job
is run one at a time once the previous job completes.
However, this is not stated in Puzzles and some implementations explicitly allow a configurable
number of jobs to run simultaneously.
Manual pages for other systems simply don't mention the subject.
I researched this episode by looking at documentation for a number of BSD Linux and commercial
unit systems, but didn't actually test out how they behave.
Puzzles only require systems to have two Q's, one named A for at jobs and one named
B for batch jobs, but allows implementations to have more.
It also says nothing about how different Q's compete for resources.
One implementation assigns a higher nice value to jobs in a Q whose name comes later in
the alphabet, giving them a lower priority in the process scheduler.
So what good are at and batch?
While I think they certainly meet the obscure requirement for a Unix Curio, I have to admit
that they aren't particularly useful today.
They were designed for an era where a typical Unix Lake system would run around the clock
and had multiple users who might log in at various times of the day but weren't connected
24-7.
In that context, using batch to run a job when the system is lightly loaded might
be useful.
Nowadays, you can just run it whenever you like on your own machine.
I have never actually used batch myself.
On a machine where there is serious competition for resources among users, batch is probably
not sophisticated enough tool to manage their jobs.
The net BSD and Debian manual pages explicitly suggest using something different.
Supercomputing environments have even more complex requirements and a number of specialized
solutions exist for scheduling jobs there.
I have used at a couple of times.
One example was for an organization I was part of that had paid for its domain name registration
several years into the future.
On the organization's server, I set an at job to email the administrator, a reminder to
renew the registration a few months before the domain was due to expire.
It was useful in that case because I didn't know whether I would even continue to be involved
in, so a personal reminder for myself wouldn't necessarily help.
But in my experience, administrative tasks don't tend to be one-off events.
Instead, they repeat, making Kron the right tool to use.
For reminders, a calendar app is probably a better solution in most cases.
While you might never have a use for at and batch, I still think it's good to know that
they exist.
Just be aware that you'll probably need to read the manual page on your system to fully
understand how they will behave.
Thanks for listening and keep an eye out for our next Unix Curio, which will be about
compression here on Hacker Public Radio.
If you have a question or a suggestion for a future topic, please comment on this episode
on the HPR website.
You have been listening to the Hacker Public Radio podcast, at hackerpublicradio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, then visit the HPR site to find out how easy it really is.
Hosting for HPR has been kindly provided by anhonesthost.com, the Internet Archive, rsync.net, and the HPR Community Content Delivery Network.
Unless otherwise stated, today's show is released under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.