If you are using BSD UNIX, the -c option tells at ( 40.3 ) 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:
set printenv |
% |
---|
(On some systems you'll need
$LOGDIR
instead of
$HOME
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
login shell (
2.8
)
) 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
job. 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
tty
(
3.8
)
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
set prompt
test (
2.9
)
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, or add
set -xv
(
46.1
)
to the first line of your Korn Shell
ENV
file or
bash
.bashrc
file. When the
at
job starts your shell, you'll see verbose messages that show commands running and variables being set in the shell startup file. 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 setup files. 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.
-
,