From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6655 invoked by alias); 9 Mar 2013 15:13:28 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31130 Received: (qmail 18533 invoked from network); 9 Mar 2013 15:13:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130309071252.ZM19892@torch.brasslantern.com> Date: Sat, 09 Mar 2013 07:12:52 -0800 In-reply-to: Comments: In reply to Mikael Magnusson "Somewhat unexpected results of {myfd}>&1 when noclobber set" (Mar 9, 11:33am) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: Somewhat unexpected results of {myfd}>&1 when noclobber set MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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).