If you are using BSD UNIX, the -c option tells to execute your script via the C shell; the -s option tells at to use the Bourne shell. at defaults to the shell you log in with. If you're lucky (and many users are), this will work the first time. But I've seen a fair number of users run into sticky problems when they first use at on a new system. If you're one of those unlucky users, here's some help.
at jobs are run in an environment that's different from your normal login sessions. Be careful about using command aliases, shell functions, and variables, and other things that may not be set for you by the system. The easiest way to find out what's happening is by having your job write its environment into some temporary files, then read them after the job runs:
(On some systems you'll need
$LOGDIR instead of
and env instead of printenv.)
If you use a shell like csh or bash that reads a setup
file when every shell (not just a
starts, the shell will read your per-shell file (like .cshrc
or .bashrc) when the job starts running.
This is good news and bad news.
The good news is that you can set shell parameters to be used by your at
If you have interactive commands in your .cshrc, though, your at
job might ignore them or might hang forever, waiting for an answer.
For instance, the
command will print the error
not a tty;
if you try to use tty to set a shell variable, it can cause "unset
variable" errors, which can abort your .cshrc file... and so on.
That's the bad news.
You can use a
in your .cshrc file, or test
$- in ksh or
bash, to make sure that there are no interactive commands
run by at.
But unless I need shell features, I usually just use at s
to run the job under the Bourne shell. (Note that some systems use
ksh or bash as their "Bourne" shell.)
Our SunOS 4.1.3 system has a problem: It sets the prompt variable in the C shell that runs at jobs; this makes the shell read my .cshrc file as if I were doing an interactive login! My at jobs were all failing with a complaint about an unset TERM variable. There's a workaround for this in article 2.10.
Here's a way to track down problems like that.
Temporarily add the command
set verbose echo to the first line of your .cshrc file,
to the first line of your Korn Shell ENV file or bash
When the at job starts your shell, you'll see verbose messages that
show commands running and variables being set in the shell startup
You'll probably also see your shell execute the commands from the
at job itself.
All of this information will be emailed to you (on versions of at
I've seen, at least) with a subject like "Output from your at job."
This is a great way to track down tricky at problems in your shell
Another tip for spotting problems: sprinkle commands like these
through your shell startup file:
echo "got to
After an at job runs, that lets you find out how far it got before your shell ran into trouble.