On 10/17/14, 11:34 AM, Greg Wooledge wrote:
> 3) Everything else. These are ignored.
>
Not quite. Bash saves them and adds them to the environment it passes to
the external commands it invokes. Bash is transparent with respect to
environment variables it doesn't handle.
Chet
--
``The lyf so
On 10/17/14, 11:22 AM, lorenz.bucher@rohde-schwarz.com wrote:
> No, I can't.
> $ foo%%="bar"
> foo%%=bar: command not found
You just demonstrated what I wrote:
> No, shell variable names should continue to be shell identifiers. You
> can already use `%' (any character, really) in environmen
On 10/16/14, 4:37 PM, Geir Hauge wrote:
> Regardless though, shouldn't source <(declare -xp) work whether or not
> the environment contains invalid identifiers? It doesn't at present:
>
> $ env %=% bash -c 'echo "$BASH_VERSION"; source <(declare -xp)'
> 4.3.30(1)-release
> /dev/fd/63: line 1: dec
> Von:Chet Ramey
> No, shell variable names should continue to be shell identifiers. You
> can already use `%' (any character, really) in environment variable
> names.
On Fri, Oct 17, 2014 at 05:22:30PM +0200, lorenz.bucher@rohde-schwarz.com
wrote:
> No, I can't.
> $ foo%%="bar"
> foo%
chet.ra...@case.edu
Datum: 10/16/2014 03:09 PM
Betreff: Re: Issue with Bash-4.3 Official Patch 27
Gesendet von:
bug-bash-bounces+lorenz.bucher.ext=rohde-schwarz@gnu.org
On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote:
> But anyway.
> In my opinion I should trus
2014-10-16 15:09 GMT+02:00 Chet Ramey :
> On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote:
>
> > But anyway.
> > In my opinion I should trust a shell not violating their own rules and be
> > able to import their own variables.
>
> That's not the issue. The shell can import variabl
On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote:
> But anyway.
> In my opinion I should trust a shell not violating their own rules and be
> able to import their own variables.
That's not the issue. The shell can import variables like that just fine,
as evidenced by exported fun
On 10/15/14, 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote:
> Hello,
> in refer to
> http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
> with suffix "%%" can't be set/exported.
> This makes problems restoring environments which where saved by external
> programs lik
On 10/15/2014 11:49 AM, lorenz.bucher@rohde-schwarz.com wrote:
> Yes, you got it. I just gave an example to reproduce that Bug. In my case
> I didn't find the save script/binary yet.
> I use unset -f function as workaround.
>
> But anyway.
> In my opinion I should trust a shell not violatin
o the % character should be allowed to be used in variable names.
Von:Greg Wooledge
An: Eduardo A. Bustamante López ,
Kopie: lorenz.bucher@rohde-schwarz.com, bug-bash@gnu.org
Datum: 10/15/2014 05:58 PM
Betreff:Re: Issue with Bash-4.3 Official Patch 27
On Wed, Oct 15, 2014 at
On Oct 15, 2014, at 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote:
> Hello,
> in refer to
> http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
> with suffix "%%" can't be set/exported.
> This makes problems restoring environments which where saved by external
> prog
On Wed, Oct 15, 2014 at 08:50:25AM -0700, Eduardo A. Bustamante López wrote:
> On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com
> wrote:
> > variables with suffix "%%" can't be set/exported.
> > This makes problems restoring environments which where saved by external
On Wed, Oct 15, 2014 at 03:38:01PM +0200, lorenz.bucher@rohde-schwarz.com
wrote:
> Hello,
> in refer to
> http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
> with suffix "%%" can't be set/exported.
> This makes problems restoring environments which where saved by ext
Hello,
in refer to
http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
with suffix "%%" can't be set/exported.
This makes problems restoring environments which where saved by external
programs like printenv (see example below)
I saw this issue on Ubuntu 12.04 with
bash ve
Linda Walsh wrote:
> wrote:
> > The change only affects environment variables **loaded as exported
> > functions**. Bash won't forbid you from using / inside the name of an
> > environment variables.
> >
>
> The below doesn't demonstrate bash doing anything with the variable you
> decla
2014-09-27 22:48:44 -0600, Eric Blake:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> > BASH PATCH REPORT
> > =
>
> > /* Don't import function names that are invalid identifiers from the
> > environment, though we stil
> I'd send it to your vendor. If appropriate they can send it upstream.
>
>
>
> Chet
I've sent this to a debian person following advice on the Arch list I initially
asked. I probably won't get used as I imagine they'll want a more general
approach to all the various versions of the bash fixe
On 9/28/14, 12:10 PM, becker...@gmail.com wrote:
> On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote:
> ..
>> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
>> then I have a patch against the at(1) source which converts exported
>> functions i
� wrote:
The change only affects environment variables **loaded as exported
functions**. Bash won't forbid you from using / inside the name of an
environment variables.
The below doesn't demonstrate bash doing anything with the variable you
declared.
Y
On 9/28/14, 11:38 AM, becker...@gmail.com wrote:
> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
> then I have a patch against the at(1) source which converts exported
> functions into something that sh can parse and allows exported functions to
> be used in the envi
On 9/28/14, 12:48 AM, Eric Blake wrote:
> This patch forbids importing function names containing '/' (yay!), and
> we already established that bash has never been able to properly import
> functions with names containing '='. But I'm assuming there will need
> to be a followup patch to actually r
The change only affects environment variables **loaded as exported
functions**. Bash won't forbid you from using / inside the name of an
environment variables.
You can easily confirm with:
> env -i 'foo/bar=baz' bash -c env
Best regards
| correction: variable called "/tmp/exploit=me" => a variable called
"/tmp/exploit" with a value "me"
On Mon, Sep 29, 2014 at 2:26 AM, Jon Seymour wrote:
> To clarify, I am not sure that the presence of a variable called
> "/tmp/exploit=me" represents a huge vuilnerability for at(1) since
> any
To clarify, I am not sure that the presence of a variable called
"/tmp/exploit=me" represents a huge vuilnerability for at(1) since
anyone who can arrange for this to happen can probably mutate the
user's environment in anyway they choose, but I did want to point out
that atrun will attempt to exec
On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote:
..
> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
> then I have a patch against the at(1) source which converts exported
> functions into something that sh can parse and allows exported func
On Sunday, September 28, 2014 3:50:07 AM UTC+1, Chet Ramey wrote:
> BASH PATCH REPORT
>
..
> --
>
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
>``Ars longa, vita brevis'' - Hippocrates
>
> Chet Ramey, ITS, CWRUc
If I use the Arch linux [t
Does anyone know if Red Hat intends on remerging with official bash? (This
may be better directed at a seperate thread with them.)
-Nathan
On Sep 28, 2014 12:49 AM, "Eric Blake" wrote:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> >BASH PATCH REPORT
> >
On 09/27/2014 08:50 PM, Chet Ramey wrote:
>BASH PATCH REPORT
>=
> /* Don't import function names that are invalid identifiers from the
>environment, though we still allow them to be defined as shell
>
Chet Ramey wrote on Sat, 27 Sep 2014 22:50:07:
> Bash-Release: 4.3
> Patch-ID: bash43-027
> Bug-Reported-by: Florian Weimer
Excellent.
Thanks for pulling in Florian Weimer's prefix/suffix approach. This is a big
help.
--- David A. Wheeler
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-027
Bug-Reported-by:Florian Weimer
Bug-Reference-ID:
Bug-Reference-URL:
Bug-Description:
This patch changes the encoding bash uses for exported funct
30 matches
Mail list logo
