Bug 91233 - RHL9: batch command ignores $SHELL and user's login shell, always using /bin/sh
Summary: RHL9: batch command ignores $SHELL and user's login shell, always using /bin/sh
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: at
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Keywords: FutureFeature
Depends On: 22216
TreeView+ depends on / blocked
Reported: 2003-05-20 08:48 UTC by Michal Szymanski
Modified: 2007-04-18 16:53 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2004-12-21 21:20:00 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2003:277 normal SHIPPED_LIVE Updated "at" packages address incorrect man page, improper selection of shell 2003-12-19 05:00:00 UTC
Red Hat Product Errata RHBA-2004:593 normal SHIPPED_LIVE Updated at package 2004-12-21 05:00:00 UTC

Description Michal Szymanski 2003-05-20 08:48:41 UTC
Description of problem:
  Contrary to what man page says (and the batch command itself, when invoked),
  'batch' ignores silently both $SHELL variable and the login shell of the
  user, ALWAYS executing the commands entered interactively by "/bin/sh"
  shell. I evene tried to fool it by entering "#!/bin/tcsh" as the first
  line, but it did not work.

Version-Release number of selected component (if applicable):
  at-3.1.8-23  (but at-3.1.8-33 in RH 9 behaves identically)

How reproducible:

Steps to Reproduce:
1. invoke "batch" interactively
2. enter any "csh/tcsh" commands, e.g.:
3. foreach n ( 1 2 )
4. echo $n
5. end
6. exit 0
7. Ctrl-D
Actual results:

In the "Output from your job" mail message one gets "sh" errors:

sh: line 83: syntax error near unexpected token `('
sh: line 83: `foreach n ( 1 2 )'

Expected results:


Additional info:

Comment 1 Jens Petersen 2003-06-02 12:28:31 UTC
An erroneous warning seems was introduced by bug 22216.

Comment 2 Jens Petersen 2003-06-03 00:47:31 UTC
In at-3.1.8-41 that should be in rawhide shortly, the erroneous
patch "at-3.1.8-shell.patch" has been removed.  So now the warning
says correctly "warning: commands will be executed using /bin/sh".

Comment 3 Michal Szymanski 2003-06-03 07:20:04 UTC
Well, if the fix is by changing the warning/manual back to "always /bin/sh",
it should be still considered a bug! I'm pretty convinced that "batch/at"
commands *should* use the $SHELL or user's shell to execute the commands.
SunOS/Solaris batch/at have been working that way for years. 
Actually, I did not complain about wrong warning/documentation but about wrong

regards, Michal.

Comment 4 Jens Petersen 2003-06-17 07:46:53 UTC
Ok, I added a patch to at-3.1.8-44.1, so that it uses SHELL rather
than "/bin/sh" by default.  Please test it and close if it is
working properly.  :)

Comment 5 Michal Szymanski 2003-06-17 14:05:30 UTC
I've tested at-3.1.8-45.1 (SRPM from Rawhide rebuilt under 7.2). Unfortunately,
it does not work properly. The only output from the batch commands entered as:

foreach n ( 1 2 )
echo $n

was a long sequence of errors apparently resulting from using /bin/sh syntax for
recreating the environment, like:

PWD=/home/386/msz: Command not found.
export: Permission denied.

Strangely, there was no sign of the "actual" batch commands being executed
(echo) at the end of the output, only pairs of errors as above.


Comment 6 Jens Petersen 2003-06-18 02:02:28 UTC
I think you're indeed seeing the tcsh behaviour, since tcsh doesn't
support "export" or "VAR=val".... ;-)

Hmmm, this is a problem in that "at" assumes a Bourne shell.
ash, bash, sh and zsh seem to be ok.

Not sure what to do about that.  Perhaps for a non-Bourne shell it would
be easier to just revert to "/bin/sh" with a warning?  

Comment 7 Göran Uddeborg 2003-10-24 16:02:02 UTC
It was mentioned that at on Solaris does use $SHELL.  It does this by first
setting all environment variables, then executing $SHELL with an "here
document".  (I.e., it ends with a line "$SHELL << 'a long unlikely string'" and
then the user's input.)

For further comparison, HP-UX always uses /usr/bin/sh, and emits a warning if
$SHELL is different.  AIX produces a queue file which is not directly
executable, but must be interpreted by crond or whatever before executing the
job.  After interpretation, it uses $SHELL.

I also took a look at what the standard says.  I found this in "The Open Group
Base Specifications Issue 6, IEEE Std 1003.1, 2003 Edition"

    Determine a name of a command interpreter to be used to invoke the at-job.
If the variable is unset or null, sh shall be used. If it is set to a value
other than a name for sh, the implementation shall do one of the following: use
that shell; use sh; use the login shell from the user database; or any of the
preceding accompanied by a warning diagnostic about which was chosen.

As it is in at-3.1.8-46 (I tried on Taroon beta), "at" does not work at all when
SHELL=/bin/tcsh.  This is clearly the least desireable.  Changing it so it uses
$SHELL and it works is ok.  Changing it so it always uses /bin/sh is also ok. 
In the latter case, a warning when $SHELL is different than /bin/sh is a good idea.

If the manual correctly describes what is implemented, that is of course an
extra plus! :-)

Comment 8 Michael Fischer 2003-11-11 22:02:55 UTC
*** Bug 109587 has been marked as a duplicate of this bug. ***

Comment 9 Jens Petersen 2003-12-09 08:33:28 UTC
*** Bug 111386 has been marked as a duplicate of this bug. ***

Comment 10 Jens Petersen 2003-12-09 09:07:07 UTC
Ok, I reworked the SHELL patch to use
  $SHELL << some_random_string
in at-3.1.8-49.

Please test it and confirm that it is working correctly.

Comment 11 Göran Uddeborg 2003-12-10 13:22:54 UTC
at-3.1.8-49 requires libselinux.so.1, which isn't available on either
my RHEL3 or FC1 machines.  Should I upgrade something more from Fedora
test to try this?

Comment 12 Jens Petersen 2003-12-11 05:09:07 UTC
Yes, you need to install libselinux.  It won't actually
do anything unless you are running an selinux kernel though.

Comment 13 Göran Uddeborg 2003-12-12 07:40:08 UTC
Ah, libselinux is a package of its own!  I could have checked that I
guess.  Oh, well.

But now I have tried this (on FC1) and it works fine!

Comment 14 Michael Fischer 2003-12-13 19:30:21 UTC
I tried it (on FC1) and it works for me, too!

Comment 15 Jens Petersen 2003-12-16 00:02:43 UTC
Ok, good, there will probably be an update for this for FC1 then. :-)

Comment 16 John Flanagan 2003-12-19 14:57:57 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


Comment 17 Stephen Walton 2004-01-04 22:32:39 UTC
I'd like this bug reopened, as the cure is worse than the disease.

The old at behavior (always generate a script with '#!/bin/sh' at the
top regardless of SHELL) at least worked most of the time if a user's
login shell was csh, provided no csh-specific commands were used. 
With the new version (I'm using at-3.1.8-46.1 on Fedora Core 1), at
ALWAYS fails for a user with a tcsh login shell, because the
at-generated script has '#!/bin/tcsh' at the top but contains "export"
and "if" commands in sh/bash format.

I think one possible solution is for at to generate a script of the form:

[needed sh commands to set up environment and cd]
[user commands given to at]

so that the at commands are executed using sh but the user commands
with the login shell.  IIRC, this is what the 'at' command on HP-UX
did when I ran such systems.  The alternative is for at to generate
csh commands if the user's shell is csh but that's probably far more

Comment 18 Göran Uddeborg 2004-01-04 22:52:52 UTC
Stephen, if you look closely, the "fixed in" field says 3.1.8-49. 
Release 46 was indeed broken, but release 49 introduced something
close to what you suggest.  So as far as I can understand, there is no
need to reopen the bug.  It is fixed, though not in the version you
have installed.

Comment 19 David Juran 2004-01-05 21:17:38 UTC
IMHO, there should be an errata released for RHEL 3 as well.

Comment 20 Stephen Walton 2004-01-06 00:38:16 UTC
Fair enough (fixed in 3.1.8-49), but in my own defense :-) I read the
erratum linked to in comment #16.  That erratum describes at-3.1.8-24
and states, "This update changes the behavior to use SHELL if it is
defined, otherwise /bin/sh. It works for Bourne-style shells (bash,
sh, zsh, ksh, and ash), *but C-style shells (csh and tcsh) are
unsupported* due to their use of a different syntax for setting
environment variables." (emphasis added)  The behavior of 3.1.8-24
implied by that erratum is the same as I see in 3.1.8-46 on Fedora,
which is the most recent release.  Hence my confusion.

Anyway, though, thanks for the pointer, and for anyone else's
information, at-3.1.8-49 for Fedora can be downloaded from


Comment 21 Jim Richard 2004-01-10 02:34:07 UTC
do I understand that "at" is now unsupported for C style shells, so I
have to force my users off of tcsh if they want to use "at" ???

Comment 22 Stephen Walton 2004-01-10 05:47:34 UTC
Well, the man page for at has always stated that csh-style shells were
not supported.  Previously, though, this meant that you couldn't put
csh-specific commands in an at job, but shell-independent commands
worked fine.  The version of at up to 3.1.8-46, though, broke this.

Rawhide 3.1.8-49 works with both styles of shell, as mentioned above,
but you have to install libselinux as well.

Comment 23 Jens Petersen 2004-01-13 03:29:30 UTC
There will likely be an update for RHEL to address this.

Comment 24 Michal Szymanski 2004-10-13 08:02:18 UTC
I think this bug should be reopened.

The fix which appeared in 3.1.8-49 made csh scripts work in 'at' when
csh/tcsh is the user's shell but, as it seems, 'at' still ignores
$SHELL variable. From what I can see in the script generated by 'at'
in /var/spool/at, the $SHELL variable is removed from the environment
when building the script. There is no "SHELL=... ; export SHELL" line
in the script. It works only (as I guess) because the script is
invoked somehow through the user's shell, namely /bin/tcsh which sets
the SHELL variable. Luckily, /bin/sh (=/bin/bash) which actually
starts executing this script, DOES NOT change/set the $SHELL variable,
so it survives when the actual user's input is started through
${SHELL:-/bin/sh} << ...
If 'bash' behaved as 'tcsh' (setting $SHELL to /bin/bash), this would
not work at all.

Another bad effect is that a 'tcsh-shell' user is unable to write a
'sh' script in at/batch now. Because even if one sets SHELL to
/bin/bash before running 'at', the script will effectively be executed
by 'tcsh'.

I think this problem would be solved by not stripping SHELL from the
environment when generating the 'at' script.

BTW, the man page is now misinforming that:

> at and batch read commands from standard  input  or  a  specified
> file which are to be executed at a later time, using /bin/sh.


Comment 25 Michal Szymanski 2004-10-15 05:57:48 UTC
Just an idea: maybe instead of (or in addition to) manipulating $SHELL
by the user himself (which, as it seems, is somewhat tricky, taking
into account that some shells (tcsh) do set $SHELL, while other (bash)
do not), it would be simpler (for the user) to add options to the
at/batch invocation allowing to explicitely choose the shell. This is
like in Solaris 'at' which accepts -c/-k/-s options setting the shell
to execute the script to csh/ksh/sh.
It should be straightforward to implement in the source, as it seems
to require nothing more that just putting apropriate SHELL=...;export
SHELL line to the script.

Comment 26 Jason Vas Dias 2004-10-15 14:27:06 UTC
 The root cause problem has been fixed in at-3.1.8-60:
 at used to exclude environment variables based on 
 a prefix match, not a whole string match, so it would
 exclude 'SHELL' because 'SHELLOPTS' is always excluded.
 I agree having a -s option would also be nice. I'll add
 it to the next version .

Comment 27 John Flanagan 2004-12-21 21:20:00 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.