Re: Somewhat unexpected results of {myfd}>&1 when noclobber set

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 9, 11:33am, Mikael Magnusson wrote:
}
} % bar=( 14 15 )
} % : {bar}>&1
} zsh: bad math expression: operator expected at `15'
} % echo $bar
} 16

This is clearly a bug.  Failing the math eval should either abort the
entire operation, or not print the warning.  I think the latter would
be considered the intended behavior, that is, bar does not contain a
descriptor so it simply gets assigned a new one by the redirection.

} % bar=foo
} % : {bar}>&1
} zsh: can't clobber parameter bar containing file descriptor 15
} % foo=
} % : {bar}>&1
} zsh: can't clobber parameter bar containing file descriptor 15
} % echo $bar
} 15

I can't reproduce that one.  For me, after unsetting foo or setting it
to empty, {bar}>&1 simply assigns a new descriptor to bar.

} (at this point bar somehow became of type "integer", i think after it
} was an array, so the earlier assignment bar=foo resolved foo to 15).

Variables to which descriptors are assigned by redirection are set to
integer type, even if their original type was something else.  Given
that I can't reproduce other parts of your steps, I can't say whether
this happened coincident with the spurious "bad math expression" or
somewhere else.

} I think it's at least not expected that this parameter is only subject
} to math evaluation if the clobber option is unset.

Just to clarify:  The statements

    setopt clobber
    bar=15
    : {bar}>&2

do NOT result in 2 being dup'd to 15, it results in 2 being dup'd to a
new descriptor and that new descriptor being assigned to bar.  The
value is *examined* only when noclobber, so whether it is also math-
evaluated is really beside the point.

The real question is whether math evaluation is applied when you do

    print something >&$bar

If $bar is not evaluated in that context, then it should not be in the
dup context either, but if it IS evaluated in that context, then it
should be treated consistently .  Guess what:

    integer bar=1+1
    print something >&$bar

DOES print to stderr, so I would argue that the current behavior is
the correct one (except for the spurious warning message).