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
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: at (Show other bugs)
(Show other bugs)
Version: 9
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
URL:
Whiteboard:
Keywords: FutureFeature
Depends On: 22216
Blocks:
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)

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


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:
  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 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
behavior!

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
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-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"
(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 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.

http://rhn.redhat.com/errata/RHBA-2003-277.html


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:

#!/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 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

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-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.

Michal.

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.
Michal.

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.

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.