bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 'local -x VARIABLE' does not clear variable for subprocesses


From: Michał Górny
Subject: Re: 'local -x VARIABLE' does not clear variable for subprocesses
Date: Wed, 27 Jan 2016 09:27:50 +0100

Hello,

On Tue, 06 May 2014 10:47:45 -0400
Chet Ramey <address@hidden> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 5/5/14, 5:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2014-05-05 22:12 Chet Ramey napisa?(a):  
> >>> Ability to locally unset a variable also for subprocesses would be 
> >>> preferable solution.  
> >>
> >> OK.  I'm not sure exactly what this means.  Can you give me an example?
> >> How would you use this in a situation where `unset' or `declare +x' are
> >> unusable?  
> > 
> > I would like to be able to unexport a variable for subprocesses called in 
> > given function, but
> > not subprocesses called later outside of given function.  
> 
> OK.  I believe that the bash-4.2 behavior was a bug (and it was, it caused
> several reported seg faults with null pointer dereferences and the
> aforementioned inconsistent behavior).  What you want is fundamentally at
> odds with how the shell is intended to behave. Is it enough to assign
> empty values to the local variables?

I'm sorry for reviving this old thread but I just hit the same issue.
I don't know why Arfrever never replied to this but a few points of my
own...

1. The old behavior was there since at least bash-3.0 (older versions
don't build for me). Which means more than 10 years. I don't know if it
was intentional or a bug but people effectively could have relied on it,
and some of them did. They considered it a feature.

2. Removal of the old behavior can result in tricky. silent bugs. Like
if you used that to locally shadow an environment variable potentially
coming from user's system, this will mean the variable suddenly is no
longer shadowed. You don't notice the problem till someone sets
the environment variable in problematic way.

3. And replying to your question, no, assigning an empty value is not
the correct solution here. Both getenv() and shell scripts distinguish
between unset and empty variables, and a number of programs and scripts
use that. Sometimes they use it with distinct meanings, sometimes they
just don't check for empty value explicitly.

Please make it possible to get the old behavior back.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

Attachment: pgp35rqGddSNC.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]