Re: PATCH: functions with redirections

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.

} The main sticking point is where you need to add the wrapper
} you have an Eprog, and it's hard to convert that back into the form you
} need for adding additional components or glueing bits together ---

Yes.  This was what I ran into as well.

} So I'll simply document around this and be satisfied with the fact that
} it is possible to compile an autoload file like
} 
} foo() { echo foo } >&3
} 
} with or without the zsh kludge 'foo "$@"' stuck at the end.  I suspect
} compiling existing autoload files is much more common than compiling
} functions typed into the shell.

Hmm.

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%