From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

Description of problem:
According to man page, at/batch tries to execute commands entered
by user's environment variable SHELL, if set. For users using
e.g. tcsh this variable is set to "/bin/tcsh". Unfortunately,
the first part of the script generated by at/batch (which regenerates
the environment as seen at the time it was created) is in sh/bash
syntax, so it fails immediately when fed into "tcsh".

It seems to be indeed executed by "tcsh" (that differs from older
at versions seen in RH7.x, where it was always executed using
"(ba)sh") - it can be proven by entering Bourne-shell syntax commands
- this also fails.

Another problem arises from (strange) behavior of "bash" shell. When I
ran "bash" from my tcsh-prompt (to enter my at/batch commands in bash
syntax), it ... also failed because "bash" did not set SHELL variable,
so it remained "/bin/tcsh". Very weird.

The fix should be rather simple - I've seen a very simple solution to
the above shell-related problems in the implementation if at/batch in
Solaris. The script is *always* executed by /bin/sh, it starts with
sh-syntax set of environment rebuilding commands and then the user's
input is introduced by:

$SHELL << '...the rest of this file is shell input'
# user commands


Version-Release number of selected component (if applicable):
at-3.1.8-46.1

How reproducible:
Always

Steps to Reproduce:
1.batch                  # in a "tcsh" shell environment
2.foreach n ( 1 2 3 )
3.echo $n
4.end
5.^D  

Actual Results:  one gets e-mail complaining about dozens of
'VARIABLE=value'
commands not found.

Expected Results:  e-mail containing:
1
2
3


Additional info: