Hi,
unless this bug is already fixed in some way
https://groups.google.com/forum/?fromgroups=#!topic/gnu.bash.bug/xpZl_-eiFCY
...I've created a tiny patch that should fix it.
Cheers,
Ondrej.
diff -up bash-upstream/general.h.patch bash-upstream/general.h
--- bash-upstream/general.h.patch
On Tuesday 30 June 2009 07:21:12 Stephane CHAZELAS wrote:
2009-06-29, 10:03(-04), Chet Ramey:
The question is whether tolerant just means that the shell doesn't
display a warning message about the assignment, as it does when you use
an invalid variable name in an assignment statement, or
2009-06-29, 10:03(-04), Chet Ramey:
and it's a bug that bash-4 is filtering them.
Maybe, maybe not. That's open to interpretation. Here's how I see it.
not allowing them to be used in
the shell is fine (echo ${vmlinux.lds}), but removing them from the
environment and thus not allowing
Stephane CHAZELAS wrote:
Posix also says that variables are inherited from the environment. That
word has a very specific meaning, as was reiterated during the $@ and set -u
discussion. The same variables language is used when Posix talks about
creating the environment for shell execution
and it's a bug that bash-4 is filtering them.
Maybe, maybe not. That's open to interpretation. Here's how I see it.
not allowing them to be used in
the shell is fine (echo ${vmlinux.lds}), but removing them from the
environment and thus not allowing other applications to leverage them
be
passed on to the next program untouched.
--William
--- On Fri, 6/26/09, Christian Krause c...@plauener.de wrote:
From: Christian Krause c...@plauener.de
Subject: Re: bash 4.x filters out environmental variables containing a dot in
the name
To: chet.ra...@case.edu
Cc: bug-bash@gnu.org
2009-06-26, 13:58(+02), Christian Krause:
Hi Chet,
Thanks for the answers. The problem is now, that this behavior of the
bash creates some real problems outside, probably with a larger impact.
Before asking the kernel developers to change parts of linux kernel's
build system, I'd like to be
Christian Krause wrote:
Given all of these facts I still tend to say that the bash shouldn't
filter them...
There's always the following argument:
Other characters may be permitted by an implementation; applications
shall tolerate the presence of such names.
I agree with Christian here. As
Chet Ramey chet.ra...@case.edu writes:
It's not a bug. Posix explicitly restricts environment variable names
to consist of uppercase letters, lowercase letters, digits, and
underscores.
POSIX only talks about their use in POSIX utilities. It does not say
anything about non-POSIX utilities
Hi Chet,
Thanks for the answers. The problem is now, that this behavior of the
bash creates some real problems outside, probably with a larger impact.
Before asking the kernel developers to change parts of linux kernel's
build system, I'd like to be sure whether bash-4.x's behavior is correct
or
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
Christian Krause wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat'
On Thursday 25 June 2009 19:17:38 Chet Ramey wrote:
Christian Krause wrote:
Bash Version: 4.0
Patch Level: 16
Release Status: release
Description:
During the compilation of the linux kernel (configured to user mode
linux) I've discovered the following problem of bash 4.0 (which is
Mike Frysinger wrote:
On Thursday 25 June 2009 19:17:38 Chet Ramey wrote:
Christian Krause wrote:
Bash Version: 4.0
Patch Level: 16
Release Status: release
Description:
During the compilation of the linux kernel (configured to user mode
linux) I've discovered the following problem of bash
14 matches
Mail list logo
