Re: f() { ...; } > file

[Stephane Chazelas <Stephane_Chazelas@xxxxxxxx>]

On Wed, Nov 05, 2008 at 02:49:24PM -0800, Phil Pennock wrote:
> On 2008-11-05 at 21:20 +0000, Stephane Chazelas wrote:
> > $ bash -c 'foo() { echo a >&3; } 3>&1; foo'
> > a
> > $ ksh -c 'foo() { echo a >&3; } 3>&1; foo'
> > a
> > $ zsh -c 'foo() { echo a >&3; } 3>&1; foo'
> > foo: 3: bad file descriptor
> > $ ARGV0=sh zsh -c 'foo() { command echo a >&3; } 3>&1; foo'
> > foo: 3: bad file descriptor
> > 
> > It looks like zsh evaluates the redirection at the time the
> > function is defined rather than when it is called.
> 
> Back to front.
> 
> I think that you're misunderstanding what bash et al are doing.  They're
> not deferring the redirection, they're resolving the redirection at
> definition time so that it remains bound to stdout.

hi Phil,

no, there're not.
If that were true (and if I understand correctly what you're
saying), bash -c 'f() { :; } 3>&1; echo foo >&3' would output
foo on stdout.

defining a function foo is sticking foo() in front of a
statement. That has been like that since functions have been
implemented in the Bourne shell.

So foo() echo bar > baz

is defining a function foo that does "echo bar > baz".

All the shells are doing that, except zsh and only if the
statement is of the form { ...; } <redirections> (there might be
other cases).

> 
> % bash -c 'foo() { echo a >&3; } 3>&1; exec >/dev/null; foo'

Yes.

It's as if you had run:

bash -c 'exec >/dev/null; { echo a >&3; } 3>&1'

My understanding is that for some reason,

% zsh -c 'foo() { echo a >&3; } 3>&1; exec >/dev/null; foo'

Is as if you had run:

% zsh -c '3>&1; exec >/dev/null; { echo a >&3; }'

-- 
Stéphane