Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 22216 - Commands executed using user's own shell (but manpage disagrees)
Commands executed using user's own shell (but manpage disagrees)
Product: Red Hat Linux
Classification: Retired
Component: at (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Mike McLean
Depends On:
Blocks: 82857 91233
  Show dependency treegraph
Reported: 2000-12-13 06:55 EST by Ed Avis
Modified: 2007-04-18 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-17 03:19:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ed Avis 2000-12-13 06:55:45 EST
The manual page at(1) says:

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

But this isn't what happens.  If the user's shell is /bin/tcsh, for
example, then commands are executed using that shell instead.  For example,
change your shell to tcsh and run:

% echo 'hello, this is $SHELL' | at now

The output from the job will say:

Hello, this is /bin/tcsh

Hence the manual page is wrong.  I'm not sure whether the implementation or
the manpage needs to change - I would favour always using /bin/sh.
Comment 1 Ed Avis 2000-12-13 07:07:08 EST
Sorry, that example is broken.  You need an extra 'echo' in there... I
reproduced this bug myself by typing stuff directly into at's stdin.
Comment 2 Philip Rowlands 2000-12-13 07:14:26 EST
Working example:

% echo $SHELL
% echo 'echo "Hello, this is $SHELL"' | at now
warning: commands will be executed using /bin/sh
job 1 at 2000-12-13 12:14
% mail
Subject: Output from your job  1

Hello, this is /bin/tcsh
Comment 3 Bill Nottingham 2000-12-13 11:53:00 EST
Rather than change the behavior, I think it's best to simply change the
documentation to match the existing behavior. This has been done in at-3.1.8-13.
Comment 4 Ed Avis 2000-12-13 12:34:05 EST
Did you also remove the 'warning: commands will be executed using /bin/sh' message?

The fact that at prints this message suggests that the original author's
intention was for /bin/sh to be used.  But as long as the manual page, the
warning message and the implementation all agree, it doesn't much matter which
shell is used.
Comment 5 Jens Petersen 2003-06-02 04:03:38 EDT
ICBW but it looks to me that this change was erroneous.

Changing shell doesn't automatically change the value of SHELL....

% printenv SHELL
% bash
$ printenv SHELL
Comment 6 Ed Avis 2003-06-02 14:20:07 EDT
When originally submitting the bug I picked 'echo $SHELL' as an example of a
command to show the current shell; perhaps the example was wrong because $SHELL
is not a reliable indicator, but nonetheless the bug report described the
behaviour when it was submitted.  I'm sure that 'at' jobs were being executed
using root's shell, not /bin/sh.

This was on 6.2 mind you, perhaps it has changed since then (in which case the
documentation might need to be changed back again!).
Comment 7 Jens Petersen 2003-06-07 15:44:59 EDT
Ok, well I reverted the warning patch in at-8.1.3-41,
but if this has ever worked I would really like to know
in which version.

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