Bug 23587 - OSTYPE (etc) is clobbered by BASH2
Summary: OSTYPE (etc) is clobbered by BASH2
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-08 16:56 UTC by Aric
Modified: 2008-05-01 15:37 UTC (History)
0 users

Clone Of:
Last Closed: 2001-01-08 17:09:59 UTC

Attachments (Terms of Use)

Description Aric 2001-01-08 16:56:32 UTC
We have a system-wide standard for the environment variable OSTYPE that has
been in place for years. Whenever bash is run, it clobbers this variable.
On my platform, it always sets it to linux-gnu. The older versions of Bash
set this to "linux" so this problem has not popped up until now. This
messes up Makefiles because make runs subshells all the time, and the
OSTYPE is being clobbered all the time.

First, I can understand wanting to set this variable, but bash should not
set the variable if it is already set. This is a design decision with which
some may disagree, but you cannot disagree with the second problem here:

Second, when bash is run as sh (e.g., /bin/sh) it is supposed to behave as
much as possible like the old Bourne Shell, yet bash2 still clobbers OSTYPE.

It does the same thing, BTW, with MACHTYPE, etc.

Here's how to reproduce the problem:

% help | grep version
GNU bash, version 2.04.11(1)-release (i386-redhat-linux-gnu)
% export OSTYPE=vxworks-target
% echo $OSTYPE
% /bin/sh -c 'echo $OSTYPE'
% (/bin/sh -c 'echo $OSTYPE')

Here is the same thing run on Solaris:
$ OSTYPE=vxworks-target
$ export OSTYPE
$ echo $OSTYPE
$ /bin/sh -c 'echo $OSTYPE'
$ (/bin/sh -c 'echo $OSTYPE')

Comment 1 Bernhard Rosenkraenzer 2001-01-10 23:11:03 UTC
This is the intended behavior according to the bash manpage and probably POSIX.
If you don't like it, talk to bug-bash@gnu.org - we're not changing it in our
package and breaking compatibility with everyone else.

Comment 2 Aric 2001-01-11 14:04:55 UTC
First, this is definitely not the intended behavior according to the bash
manpage. I quote it here: "If bash is invoked with the name sh, it tries to
mimic the startup behavior of historical versions of sh as closely as possible,
while conforming to the POSIX standard as well." The behavior I describe is not
even close to the "historical versions of sh". "probably POSIX" is not good
enough. How about checking into it?

Second, I don't expect you to break compatibility with everyone else, but other
linux distributions forward bug reports like this to the appropriate people. I
have seen many debian bug reports on the Vim and mutt email lists. With lazy
product support like this, is it any wonder that your stock price is where it is?

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