Bug 91233 - RHL9: batch command ignores $SHELL and user's login shell, always using /bin/sh
RHL9: batch command ignores $SHELL and user's login shell, always using /bin/sh
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: at (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
: FutureFeature
Depends On: 22216
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-20 04:48 EDT by Michal Szymanski
Modified: 2007-04-18 12:53 EDT (History)
5 users (show)

See Also:
Fixed In Version: 3.1.8-49
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-21 16:20:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Szymanski 2003-05-20 04:48:41 EDT
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:
  always

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:

1
2

Additional info:
Comment 1 Jens Petersen 2003-06-02 08:28:31 EDT
An erroneous warning seems was introduced by bug 22216.
Comment 2 Jens Petersen 2003-06-02 20:47:31 EDT
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 03:20:04 EDT
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
behavior!

regards, Michal.
Comment 4 Jens Petersen 2003-06-17 03:46:53 EDT
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 10:05:30 EDT
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
end

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.

Michal.
Comment 6 Jens Petersen 2003-06-17 22:02:28 EDT
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 12:02:02 EDT
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"
(http://www.opengroup.org/):

SHELL
    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 17:02:55 EST
*** Bug 109587 has been marked as a duplicate of this bug. ***
Comment 9 Jens Petersen 2003-12-09 03:33:28 EST
*** Bug 111386 has been marked as a duplicate of this bug. ***
Comment 10 Jens Petersen 2003-12-09 04:07:07 EST
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 08:22:54 EST
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 00:09:07 EST
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 02:40:08 EST
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 14:30:21 EST
I tried it (on FC1) and it works for me, too!
Comment 15 Jens Petersen 2003-12-15 19:02:43 EST
Ok, good, there will probably be an update for this for FC1 then. :-)
Comment 16 John Flanagan 2003-12-19 09:57:57 EST
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.

http://rhn.redhat.com/errata/RHBA-2003-277.html
Comment 17 Stephen Walton 2004-01-04 17:32:39 EST
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:

#!/bin/sh
[needed sh commands to set up environment and cd]
$SHELL << AT_EOF
[user commands given to at]
AT_EOF

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
complicated.
Comment 18 Göran Uddeborg 2004-01-04 17:52:52 EST
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 16:17:38 EST
IMHO, there should be an errata released for RHEL 3 as well.
Comment 20 Stephen Walton 2004-01-05 19:38:16 EST
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

http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/at-3.1.8-49.i386.rpm
Comment 21 Jim Richard 2004-01-09 21:34:07 EST
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 00:47:34 EST
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-12 22:29:30 EST
There will likely be an update for RHEL to address this.
Comment 24 Michal Szymanski 2004-10-13 04:02:18 EDT
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.

Michal.
Comment 25 Michal Szymanski 2004-10-15 01:57:48 EDT
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.
Michal.
Comment 26 Jason Vas Dias 2004-10-15 10:27:06 EDT
 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 16:20:00 EST
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.

http://rhn.redhat.com/errata/RHBA-2004-593.html

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