Bug 91233

An erroneous warning seems was introduced by bug 22216.

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

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.

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

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.

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?  

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

*** Bug 109587 has been marked as a duplicate of this bug. ***

*** Bug 111386 has been marked as a duplicate of this bug. ***

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.

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?

Yes, you need to install libselinux.  It won't actually
do anything unless you are running an selinux kernel though.

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!

I tried it (on FC1) and it works for me, too!

Ok, good, there will probably be an update for this for FC1 then. :-)

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

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.

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.

IMHO, there should be an errata released for RHEL 3 as well.

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

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" ???

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.

There will likely be an update for RHEL to address this.

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.

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.

 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 .

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