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
> > }
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 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() {
>
Put the cursor after the word "list" and hit TAB:
# find /etc/apt/sources.list.d/*list #|cpio -o|ssh 192.168.44.4 cpio -ivdm
Emacssources.list eeepc.list tw.list
# find /etc/apt/sources.list.d/ #|cpio -o|ssh 192.168.44.4 cpio -ivdm
Notice how we are shown the completions, but then the "*l
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
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
The following $ while read l ; do continue; done < <(ls -l / 2>/dev/null)fails
on: BASH_VERSINFO=4 BASH_VERSION=4.1.2(1)-release SHLVL=1 (the machine I'm
on doesn't have bashbug).with """-bash: /dev/fd/62: Permission denied"""and
not on bash3, bash2. And not on bash4 with a $SHLVL -gt 1.
On 4/30/10 2:51 AM, jida...@jidanni.org wrote:
> Put the cursor after the word "list" and hit TAB:
> # find /etc/apt/sources.list.d/*list #|cpio -o|ssh 192.168.44.4 cpio -ivdm
> Emacssources.list eeepc.list tw.list
> # find /etc/apt/sources.list.d/ #|cpio -o|ssh 192.168.44.4 cpio -ivdm
>
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
> "CR" == Chet Ramey writes:
CR> I have to assume that you're using programmable completion,
CR> and the compspec for `find' doesn't impose the same restriction.
Same happens with cat or ":", not only find. It doesn't happen for
# su - nobody
And I've isolated the problem to somewhere in this
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
11 matches
Mail list logo
