Subject: Re: [ast-users] exec {n}<>&-, exec {n}<&-, exec {n}>&-
--------
> I see that:
> exec {n}<>&-
There is no need for this, since <& and >& both close the file
descriptor n.
>
> is syntactically invalid in ksh and zsh. However "n" is a file
> descriptor for open terminal, in ksh you can do this:
>
> exec {n}<&-
> exec {n}>&-
>
> and not get an error while in zsh, you do get an error because zsh
> says n is already closed. (Probably more relevant is the fact that n
> is open read/write than it is a terminal.)
>
> The zsh folks seem to think that giving an error on the second close
> is the right thing to do.
It probably is right but it appears to be unspecified by the standard.
If the value is non-zero ( and you don't use command exec), the standard
requires that any redirection error terminate the script. If I were
to change the behavior to the way zsh works( which makes sense),
it could cause existing script to fail.
>
> So
> 1. Does the first close close *both* input and output
Yes,
> 2. If 1 is true, should one get an error message on the second close?
Unspecifed.
>
> The zsh thinking and discussion starts here:
> http://www.zsh.org/mla/workers/2008/msg01791.html
>
> Thanks.
> _______________________________________________
> ast-users mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/ast-users
>
David Korn
[email protected]
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
