-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/30/12 5:24 AM, Dan Douglas wrote:
> On Monday, April 23, 2012 04:56:09 PM Clark Wang wrote:
>> On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote:
>>> It appears that `unset' is capable of traversing down the call-stack and
>>> ...
>
> I reverse e
On Monday, April 23, 2012 04:56:09 PM Clark Wang wrote:
> On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote:
> > It appears that `unset' is capable of traversing down the call-stack and
> > ...
I reverse engineered most of this behavior a few months ago and wrote a
detailed explaination and examp
On 4/23/12 4:56 AM, Clark Wang wrote:
> When I revisit this 2 years old thread I don't understand why following
> foo() function does not output the global var:
>
> $ cat foo.sh
> var=global
> foo()
> {
> local var=foo
> unset var
> echo foo: $var
> }
> bar_unset()
> {
> unset var
On 4/26/12 8:11 AM, Greg Wooledge wrote:
> Bash uses "dynamic scoping", which is a somewhat controversial choice, and
> has led to a whole lot of confusion in the past. Most other shells use
> static scoping.
I really wish people would stop saying "most other shells," unless by that
they mean "k
On Fri, Apr 27, 2012 at 02:49, Greg Wooledge wrote:
>
> I don't see this as a surprise. It's how you return values from functions
> in bash. Pick a global variable (r, ret, whatever you want) and stuff the
> return value into that. You can even declare your "r" locally somewhere
> so that the
On Fri, Apr 27, 2012 at 02:02, Bill Gradwohl wrote:
>
> So, if you want to make sure a sub
> function can't touch a variable, put another function in between that
> localises and then unsets the variable.
>
Sounds interesting. Will see if I can take advantage of this in future. :)
>
>
> --
> Bi
On Thu, Apr 26, 2012 at 01:37:57PM -0600, Bill Gradwohl wrote:
> When the child creates a global to pass back information, and then
> terminates, the parent had no control over that variables creation and is
> now stuck with something in the global name space that via the hierarchy of
> calls, it d
On Thu, Apr 26, 2012 at 12:49 PM, Greg Wooledge wrote:
> I don't see this as a surprise. It's how you return values from functions
> in bash. Pick a global variable (r, ret, whatever you want) and stuff the
> return value into that. You can even declare your "r" locally somewhere
> so that the
On Thu, Apr 26, 2012 at 12:02:20PM -0600, Bill Gradwohl wrote:
> bar_unset() {
> unset var
> echo ${FUNCNAME[@]}: $var
> displayVar
> displayVarbar_unset() {
>echo ${FUNCNAME[@]}: $var
> }
> displayVarbar_unset
> echo
> newVar=bar_unset
> }
> When newVar is
I added a bit if code to show some things that I did and did not expect.
#!/bin/bash
var=global
foo() {
echo
local var=foo
unset var
echo ${FUNCNAME[@]}: $var
displayVar
displayVarfoo() {
echo ${FUNCNAME[@]}: $var
}
displayVarfoo
}
bar_unset() {
unset
On Mon, Apr 23, 2012 at 04:56:09PM +0800, Clark Wang wrote:
> When I revisit this 2 years old thread I don't understand why following
> foo() function does not output the global var:
>
> $ cat foo.sh
> var=global
> foo()
> {
> local var=foo
> unset var
> echo foo: $var
> }
> bar_unset(
On Wed, Apr 25, 2012 at 04:46:02PM -0700, Linda Walsh wrote:
> I would guess (without looking at the codE), that
> when you do a local, it creates another copy of 'var' at the end of an
> array.
> like var[0][1]
> so global is at 0, and local is at 1.
I'm pretty sure bash doesn't use a multidimen
Clark Wang wrote:
On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote:
It appears that `unset' is capable of traversing down the call-stack and
unsetting variables repeatedly:
a=0 b=0 c=0 d=0 e=0
_unset() { unset -v b c c d d d e; }
t1() {
local a=1 b=1 c=1 d=1
t2
}
On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote:
> It appears that `unset' is capable of traversing down the call-stack and
> unsetting variables repeatedly:
>
>a=0 b=0 c=0 d=0 e=0
>_unset() { unset -v b c c d d d e; }
>t1() {
>local a=1 b=1 c=1 d=1
>t2
>}
>t2
Thanks, but I think I found a very nice, less complicated solution, and
as I now understand from the investigation of the intricacies of `unset'
elsewhere in this thread, it is perfect legitimate. A speed comparison
between all different solutions/workarounds would be interesting though?
My solut
On 5/4/10 1:57 PM, Freddy Vulto wrote:
> It appears that `unset' is capable of traversing down the call-stack and
> unsetting variables repeatedly:
>
> a=0 b=0 c=0 d=0 e=0
> _unset() { unset -v b c c d d d e; }
> t1() {
> local a=1 b=1 c=1 d=1
> t2
> }
> t2() {
>> Except that it forks a subshell and consumes trailing newlines, and
>> the whole point of this exercise is to avoid forks and spurious
>> corruption of trailing newlines.
>
> I will try to find an alternative to eval $( )
The code below allows the callee to return any kind of values (including
On 5/3/10 3:30 PM, Freddy Vulto wrote:
> On 100503 08:57, Chet Ramey wrote:
>>> On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote:
I prefer to avoid using eval by using declare, but declare inside a
function makes the variable local. Wouldn't it be nice to have a
glob
On 5/3/10 5:38 PM, Freddy Vulto wrote:
> I think I found a much cleaner workaround. It looks like a called
> function can really unset local variables in the caller(?!),
This isn't surprising. A function could always unset variables at a
higher scope; e.g., a function can unset a variable with
It appears that `unset' is capable of traversing down the call-stack and
unsetting variables repeatedly:
a=0 b=0 c=0 d=0 e=0
_unset() { unset -v b c c d d d e; }
t1() {
local a=1 b=1 c=1 d=1
t2
}
t2() {
local a=2 b=2 c=2 d=2 e=2
_unset
ec
On 05/04/2010 09:35 AM, Marc Herbert wrote:
> Are you are worried about the *cost* of the subshell? How can
> interactive completion be performance-sensitive?
Anything repetitive, done often enough, is observable even in an
interactive environment. The bash-completion library of functions does
a
Le 04/05/2010 14:40, Eric Blake a écrit :
> Except that in computing tab completion, side effects are _all_ that
> you want - basically, Freddie's problem is how to populate the
> global completion variables from within helper functions.
Of course you want a side-effect in the caller, and my examp
On 05/04/2010 03:11 AM, Marc Herbert wrote:
> I'd like to know why you absolutely want the callee to perform a
> side-effect on the caller. This is your original sin
> IMHO. Side-effects are evil, use as little of them as you can.
Except that in computing tab completion, side effects are _all_ tha
Le 01/05/2010 09:18, Freddy Vulto a écrit :
> I would like to call t(), and let it return me a filled variable by
> reference, that is without polluting the global environment.
I'd like to know why you absolutely want the callee to perform a
side-effect on the caller. This is your original sin
IM
Freddy Vulto wrote:
# Param: $1 �variable name to return value to
# Public library function
blackbox() {
local __1
_blackbox __1
[[ $1 == __1 ]]&& echo "ERROR: variable name conflicts"\
"with local variable: $1"
printf -v $1 %s
I think I found a much cleaner workaround. It looks like a called
function can really unset local variables in the caller(?!), so that
passing by reference works:
_blackbox_unset_vars "$2" "$3"
If you would try to unset local variables directly in "blackbox()",
using:
unset -v "$2" "$3"
On 100503 08:57, Chet Ramey wrote:
> > On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote:
> >> I prefer to avoid using eval by using declare, but declare inside a
> >> function makes the variable local. Wouldn't it be nice to have a
> >> global flag (declare -g) like zsh's typeset -
On 5/3/10 8:21 AM, Greg Wooledge wrote:
> On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote:
>> I prefer to avoid using eval by using declare, but declare inside a
>> function makes the variable local. Wouldn't it be nice to have a
>> global flag (declare -g) like zsh's typeset -g.
On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote:
> I prefer to avoid using eval by using declare, but declare inside a
> function makes the variable local. Wouldn't it be nice to have a
> global flag (declare -g) like zsh's typeset -g.
Yeah. It definitely would. (This comes up
On 5/1/10 6:19 PM, Freddy Vulto wrote:
> I have to give local variables a value (append an equal sign) in order
> to get them listed with 'local' in "blackbox()". Is there a bash
> builtin which lists all defined local variable names, even those not
> having a value yet?
A variable that has not
I would discourage the use of "l" (ell) as a variable name for readability.
I like the fact that _blackbox_called_by uses a parameter rather than
parsing the caller's name. This allows you to permit multiple callers
to a common private function, if needed. However, I'm assuming that
you will name
Here's another revised version.
I figured I could use bash internal `printf -v' just before the `eval'
to check if the variable name is a valid identifier. This should be an
exceptional case, so I don't mind doing this at the end of the function
- checking just before the eval. Now it's also eas
In Bash 3.2.0(1)-release, "local" displays local variables that do and
do not have values. In Bash 4.0.33(1)-release and 4.1.0(1)-release
only those with values are printed. Oops.
f () { local var1 var2=abc var3=; local; }; f
Bash 3:
var1=
var2=abc
var3=
Bash 4:
var2=abc
var3=
So it looks like
Here's another revised version.
It seems like a lot of bookkeeping (I wish we could transfer to bash?),
but I don't see another way if you want to pass "variables by reference"
in a bash library and prevent both yourself and public users from being
bitten by a conflict with a local variable - othe
Wouldn't you want your name collision test before your call to the
private function - just to save the wasted call? (And to have its
message redirected to stderr and have a "return 1" or other non-zero
value?) Otherwise, I think your idea is a good one, especially if the
public function can be as s
On 100501 12:40, Pierre Gaston wrote:
> On Sat, May 1, 2010 at 12:26 PM, Dennis Williamson wrote:
> > As Chet said, use internal variables that are unlikely to conflict.
> You can use workarounds like:
> printf -v $a "%s" foobar
> read $a <<< "%s"
The problem with obfucscated internal variables I
On Sat, May 1, 2010 at 12:26 PM, Dennis Williamson
wrote:
> As Chet said, use internal variables that are unlikely to conflict.
>
> # Param: $1 variable name to return value to
> blackbox() {
> local __bb_a # internal: __, blackbox: bb, a: _a
> eval $1=bar
> }
>
> f() {
>
As Chet said, use internal variables that are unlikely to conflict.
# Param: $1 variable name to return value to
blackbox() {
local __bb_a# internal: __, blackbox: bb, a: _a
eval $1=bar
}
f() {
local a
blackbox a
echo $a
}
f# no conflict
I
On 100430 08:19, Greg Wooledge wrote:
> On Fri, Apr 30, 2010 at 12:02:58AM +0200, Freddy Vulto wrote:
> > Passing variables by reference however, has a caveat in that
> > local variables override the passing by reference, e.g.:
> >
> > t() {
> > local a
> > eval $1=b
> > }
On Fri, Apr 30, 2010 at 12:02:58AM +0200, Freddy Vulto wrote:
> In an attempt to improve the bash-completion package we're trying to
> improve the bash completion library functions by passing variables by
> reference.
http://mywiki.wooledge.org/BashFAQ/006
> Passing variables by reference however
> In an attempt to improve the bash-completion package we're trying to
> improve the bash completion library functions by passing variables by
> reference. Passing variables by reference however, has a caveat in that
> local variables override the passing by reference, e.g.:
This isn't a problem
41 matches
Mail list logo
