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:
Thanks, I think this is a good solution. Modifying SHELL patch to this effect in at-3.1.8-49. *** This bug has been marked as a duplicate of 91233 ***
*** This bug has been marked as a duplicate of 109587 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.