40.4 Choosing the Shell Run (We Hope) by at

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
 

% 

at 1234


set

 > $HOME/at.set


printenv

 > $HOME/at.env



[CTRL-d]

(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 

here

" | mail 

yourname


echo "got to 

here

" >> $HOME/at.log

After an at job runs, that lets you find out how far it got before your shell ran into trouble.