r/w access to calling function's $@

r/w access to calling function's $@

[Roman Neuhauser]

hello,

zparseopts can modify $@ in the calling scope.  i'm playing with my own,
slightly different option parser.  what do i have to do to get access to
this feature?

-- 
roman

Re: r/w access to calling function's $@

[Peter Stephenson]

On Tue, 13 May 2014 18:01:40 +0200
Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> zparseopts can modify $@ in the calling scope.  i'm playing with my own,
> slightly different option parser.  what do i have to do to get access to
> this feature?

The trick is it's not a different scope, it's just a builtin within the
current function scope.  The equivalent would be to implement your own C
plugin, which I presume is not what you're after.  Failing that you
have to do something nasty like using "eval" to avoid exposing the
point where it gets transferred to the current argument set.

Passing back values has always been one of my chief annoyances about
shell functions, nor do I think generically allowing references to
higher level parameters is a good idea.  We need something more
specific that I haven't thought of to do parameter references.

(While I've been distracting you, Bart will meanwhile have thought
of a way of doing it.)

pws

Re: r/w access to calling function's $@

[Roman Neuhauser]

# p.stephenson@samsung.com / 2014-05-13 17:13:21 +0100:
> On Tue, 13 May 2014 18:01:40 +0200
> Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> > zparseopts can modify $@ in the calling scope.  i'm playing with my own,
> > slightly different option parser.  what do i have to do to get access to
> > this feature?
> 
> The trick is it's not a different scope, it's just a builtin within the
> current function scope.  The equivalent would be to implement your own C
> plugin, which I presume is not what you're after.

yeah, i was hoping there was a way to implement "builtins" in zsh
(as opposed to C).

> Failing that you have to do something nasty like using "eval" to avoid
> exposing the point where it gets transferred to the current argument
> set.

not sure what exactly you have on mind here, could you give me a sketch?

> (While I've been distracting you, Bart will meanwhile have thought
> of a way of doing it.)

That reminds me: thanks for the many years of work on zsh, and great support
you two provide seemingly tirelessly. 

-- 
roman

Re: r/w access to calling function's $@

[Bart Schaefer]

On May 13,  5:13pm, Peter Stephenson wrote:
}
} Passing back values has always been one of my chief annoyances about
} shell functions, nor do I think generically allowing references to
} higher level parameters is a good idea.  We need something more
} specific that I haven't thought of to do parameter references.
} 
} (While I've been distracting you, Bart will meanwhile have thought
} of a way of doing it.)

No such luck this time.  You can do it with the "trap" command or a
parameter declared "local" if the caller cooperates, but you can't do
it all from inside the called function.

I believe ksh namerefs can reach across scopes this way, but you still
have to declare the nameref in the outer scope, and zsh doesn't have
real namerefs yet in any case.

Of course the "standard" way to do this is to use the $reply array or
the $REPLY scalar, which are semi-reserved names for the purpose.

Re: r/w access to calling function's $@

[Peter Stephenson]

On Tue, 13 May 2014 18:42:06 +0200
Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> > Failing that you have to do something nasty like using "eval" to avoid
> > exposing the point where it gets transferred to the current argument
> > set.
> 
> not sure what exactly you have on mind here, could you give me a sketch?

Use "reply" as alluded to by Bart but disguise the update to argv.  I
can't think of a good reason to do this rather than just living with the
limitation and manipulating $reply explicitly.  Also, this method makes
it hard to pass *in* arguments.


my_function_that_does_the_real_stuff()
{
   typeset -g reply # in case the caller didn't localise it
   reply=(my reply value)
}

my_disguise='
my_function_that_does_the_real_stuff
argv=("${reply[@]}")
'

# Call a function, disguising the fact that it updates $argv.
eval $my_disguise


Bart's idea of an EXIT trap is a bit neater.  For functions the EXIT
trap explicitly gets called in the caller's scope.


% print $*

% pass_back() { trap 'argv=(my results)' EXIT; }
% pass_back
% print $*
my results


There's still what amounts to an eval in there, however.

pws