On 8/21/12 7:45 AM, Ondrej Oprala wrote:
> Hi,
> unless this bug is already fixed in some way
I changed bash-4.1 to remember environment strings that are not valid shell
variable names, like those containing a dot, and add them to the
environment exported to commands. They're not valid shell vari
On 08/21/2012 05:45 AM, Ondrej Oprala wrote:
> 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.
Sorry, but this would violate POSIX, which requires that '.' is not
On Tuesday 21 August 2012 07:45:49 Ondrej Oprala wrote:
> unless this bug is already fixed in some way
yes, please retest with very latest bash-4.2 and the released patchsets
-mike
signature.asc
Description: This is a digitally signed message part.
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 20
Hi Chet,
Chet Ramey 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 ex
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 statemen
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
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 no
> 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 the
set, should be
passed on to the next program untouched.
--William
--- On Fri, 6/26/09, Christian Krause wrote:
> From: Christian Krause
> 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
>
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. A
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 t
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 n
Chet Ramey 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 and extensions (an
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 fo
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
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' -
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' -DPACKA
18 matches
Mail list logo
