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
14 matches
Mail list logo