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
If you use a shell like
that reads a setup
file when every shell (not just a
starts, the shell will read your per-shell file (like
) 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
If you have interactive commands in your
, though, your
job might ignore them or might hang forever, waiting for an answer.
For instance, the
command will print the error
You can use a
file, or test
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
After an at job runs, that lets you find out how far it got before your shell ran into trouble.