Re: PATCH: functions with redirections

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Wed, 01 Oct 2014 21:07:41 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Oct 1,  8:17pm, Peter Stephenson wrote:
> } Subject: Re: PATCH: functions with redirections
> }
> } On Mon, 29 Sep 2014 14:37:35 -0700
> } Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> } > 
> } > foo () { echo foo } >&3
> } > 
> } > becomes
> } > 
> } > foo () { { echo foo } >&3 }
> } 
> } This appears to be about the only way I could even conceivably get this
> } to work --- otherwise it means reengineering multiple different ways of
> } constructing and reading a dump file --- but even this appears too
> } difficult.
> 
> It's also apparently wrong, if this ...
> 
> } +function is executed.  Any variables in the redirection are expanded
> } +at the point the function is executed, but outside the function scope.
> 
> ... is actually the way it's supposed to work.

It doesn't make any obvious practical difference simply to expanding
variables given that no variables appear in the function before the
redirection is applied.

> torch% cat /tmp/foo
> foo() { echo foo } >&3
> torch% zcompile -k /tmp/foo
> torch% autoload foo
> torch% FPATH=/tmp foo      
> foo
> 
> Oops, the redirection didn't get applied.  But it does once the function
> is loaded and then called:
> 
> torch% functions foo
> foo () {
>         echo foo
> } >&3
> torch% foo
> zsh: 3: bad file descriptor
> torch% 

Not sure how that could happen --- there must be some kludge to run the
function the first time.  I guess this is specific to ksh style ---
there may be something funny with the EF_RUN flag.

pws