Sorry, I overlooked the indirection (and the missing semicolon).
On Mon, Jul 25, 2011 at 10:18 PM, Bob Proulx wrote:
> Dennis Williamson wrote:
>> Linda Walsh wrote:
>> > GLOBAL="hi there"
>> > {foo=GLOBAL echo ${!foo}; }
>
> Note that this tickles a problem since foo isn't set before $foo is
> e
Dennis Williamson wrote:
> Linda Walsh wrote:
> > GLOBAL="hi there"
> > {foo=GLOBAL echo ${!foo}; }
Note that this tickles a problem since foo isn't set before $foo is
expanded. Use this following with a semicolon instead:
GLOBAL="hi there"
{foo=$GLOBAL; echo ${!foo}; }
> You had a missing
On Tue, Jul 26, 2011 at 12:00 AM, Andreas Schwab wrote:
> "Clark J. Wang" writes:
>
> > Here the cannot expand ``*.d'' to ``long-dir-name.d''. Bug?
>
> You need to add -o bashdefault for that.
>
``-o bashdefault'' works fine for me, thanks. But from the Bash manual I
think ``-o default'' should
On 7/25/11 8:49 AM, Ralph Corderoy wrote:
> I also get, with vanilla 4.2 built from source,
>
> $ ./install/bin/bash -c "printf '%*q.\n' 10 foo -20 bar 0x8000"
>foo.
> bar .
> Segmentation fault (core dumped)
> $
Thanks for the report. That's a d
On Mon, Jul 25, 2011 at 4:45 PM, Linda Walsh wrote:
>
>
> Linda Walsh wrote:
>>
>> Bob Proulx wrote:
>>> Yes, but it is a fork(2) of the parent shell and all of the variables
>>> from the parent are copied along with the fork into the child process
>>> and that includes non-exported variables. No
Linda Walsh wrote:
> I didn't know why it behaved differently, but as you informed me
> the difference is 'one's well-defined, and the other is not, I can
> see why there 'could' be a difference... ;-)
>
> (which of course could change tomorrow, I suppose..)
Not the second well defined case. It
Eric Blake wrote:
> On 07/25/2011 03:45 PM, Linda Walsh wrote:
>> I mistyped that but it brings me to an interesting
>> conundrum:
>>
>> GLOBAL="hi there"
>> {foo=GLOBAL echo ${!foo}; }
>
> This says:
>
> evaluate ${!foo}, and pass that expansion to 'echo', with foo=GLOBAL in
> the environment of
On Mon, 25 Jul 2011 14:28:52 -0700, Linda Walsh wrote:
> Not really.
> It only seems that way because within () any "$" is usually
> expanded BEFORE the () starts from the parent
>
> You can see this by
> GLOBAL="hi there"
> (echo $GLOBAL)
> prints out "hi there" as expected, b
On 07/25/2011 03:45 PM, Linda Walsh wrote:
I mistyped that but it brings me to an interesting
conundrum:
GLOBAL="hi there"
{foo=GLOBAL echo ${!foo}; }
This says:
evaluate ${!foo}, and pass that expansion to 'echo', with foo=GLOBAL in
the environment of echo. You are invoking behavior that P
Linda Walsh wrote:
>
> Bob Proulx wrote:
>> Yes, but it is a fork(2) of the parent shell and all of the variables
>> from the parent are copied along with the fork into the child process
>> and that includes non-exported variables. Normally you would expect
>> that a subprocess wouldn't have ac
Bob Proulx wrote:
> Linda Walsh wrote:
>> DJ Mills wrote:
Because a subshell cannot access the global variables of the parent.
>>> A subshell can access its parent's variables. foo=bar; ( echo "$foo" )
>>>
>>> A sub process cannot, unless the variables are exported. It does
>>> not sound l
Linda Walsh wrote:
> DJ Mills wrote:
> >> Because a subshell cannot access the global variables of the parent.
> >
> > A subshell can access its parent's variables. foo=bar; ( echo "$foo" )
> >
> > A sub process cannot, unless the variables are exported. It does
> > not sound like you need to d
I know it wasn't designed this way, but it seems like it
is a bug.
If I do
read a b c <<<$(echo {1..3} ); echo "a:$a b:$b c:$c"
I get:
a:1 b:2 c:3
But If I do
export IFS=','; read a b c <<<$(echo {1..3} ); echo "a:$a b:$b c:$c"
I get:
a:1 2 3 b: c:
Why should the 2nd case return the w
DJ Mills wrote:
>> Because a subshell cannot access the global variables of the parent.
>
> A subshell can access its parent's variables. foo=bar; ( echo "$foo" )
>
> A sub process cannot, unless the variables are exported. It does not sound
> like
> you need to do so here.
I'm
On Mon, Jul 25, 2011 at 8:33 PM, Linda Walsh wrote:
> Pierre Gaston wrote:
>> Since you are already using global variables, why not simply use a
>> couple more for the return values?
>>
> ---
> Because a subshell cannot access the global variables of the
> parent.
uh? you don't make sens
Steven W. Orr wrote:
> On 7/25/2011 5:20 AM, Linda Walsh wrote:
> I highly recommend reading this, but read it *very carefully*. I have
> adopted this in my production system and it works great. The idea is to
> implement passing variables by reference and to allow the values to be
> either scala
> Because a subshell cannot access the global variables of the
> parent.
>
A subshell can access its parent's variables. foo=bar; ( echo "$foo" )
A sub process cannot, unless the variables are exported. It does not sound like
you need to do so here.
Pierre Gaston wrote:
> Since you are already using global variables, why not simply use a
> couple more for the return values?
>
---
Because a subshell cannot access the global variables of the
parent.
The only 'hack' I came up with overnight for a quick & dirty, is
to pass
"Clark J. Wang" writes:
> Here the cannot expand ``*.d'' to ``long-dir-name.d''. Bug?
You need to add -o bashdefault for that.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely differen
On 7/25/2011 5:20 AM, Linda Walsh wrote:
I got great help in learning about how to do the perl equiv of (var1,
var2, var3)= (list) using read var1 var2 var3<<<(list).
I use it often to get back lists of values from subroutine calls, but with
sometimes useful, and sometimes hindering fact tha
Hi Chet,
> On 7/22/11 10:38 AM, Ralph Corderoy wrote:
> > On a related note, I can't interrupt this, e.g. Ctrl-C.
> >
> > printf '%-92233720368547758q.\n' foo
>
> That's interesting, since the fieldwidth (and precision) end up
> getting set to 0 if they overflow INT_MAX, at least on my machi
For example:
[bash-4.2.8] # ls -lF
total 4
drwxr-xr-x 3 root root 4096 2011-07-25 16:52 long-dir-name.d/
[bash-4.2.8] # ls -lF long-dir-name.d/
total 4
drwxr-xr-x 2 root root 4096 2011-07-25 16:52 bar/
[bash-4.2.8] # complete -d -o default cd
[bash-4.2.8] # cd *.d
Here the cannot expand ``*.d''
On Mon, Jul 25, 2011 at 12:20 PM, Linda Walsh wrote:
>
>
>
> I got great help in learning about how to do the perl equiv of (var1,
> var2, var3)= (list) using read var1 var2 var3 <<<(list).
>
> I use it often to get back lists of values from subroutine calls, but with
> sometimes useful, and some
I got great help in learning about how to do the perl equiv of (var1,
var2, var3)= (list) using read var1 var2 var3 <<<(list).
I use it often to get back lists of values from subroutine calls, but with
sometimes useful, and sometimes hindering fact that when I do
read var1 var2 var3 <<<$(funct
24 matches
Mail list logo
