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 $(function x
On Mon, Jul 25, 2011 at 12:20 PM, Linda Walsh b...@tlinx.org 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
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 that
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
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.
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 scalars
On Mon, Jul 25, 2011 at 8:33 PM, Linda Walsh b...@tlinx.org 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
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 not sure
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 do so here.
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 like you need to do
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 access to
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
On Mon, 25 Jul 2011 14:28:52 -0700, Linda Walsh b...@tlinx.org 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,
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 echo. You are
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
On Mon, Jul 25, 2011 at 4:45 PM, Linda Walsh b...@tlinx.org 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.
Sorry, I overlooked the indirection (and the missing semicolon).
On Mon, Jul 25, 2011 at 10:18 PM, Bob Proulx b...@proulx.com 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
17 matches
Mail list logo
