Re: exec {_Dbg_new_fd}<>&-

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 11,  8:09pm, Rocky Bernstein wrote:
}
}   exec {_Dbg_fd}<>$TTY
}   exec {_Dbg_fd}<&-
}   exec {_Dbg_fd}>&-
} 
} bug.zsh:3: file descriptor 12 out of range, not closed. And ksh
} doesn't seem to complain.

At first I thought you meant that {_Dbg_fd}>&- never worked, but now
I see you mean it complains when the fd has previously been closed.  

I suspect this is just a case of zsh being more vocal about a possible
error than ksh.  Closing an already closed fd _could_ be silently
ignored, which I imagine is what ksh is doing.

} I gather that closing _Dbg_fd for input also closes it for output.
} 
} Is this the expected or okay?

Yes on both counts.  A descriptor is either open or not.  If you want
separate read and write handles, you have to create them explicitly:

   exec {_Dbg_rfd}<&$_Dbg_fd
   exec {_Dbg_wfd}>&$_Dbg_fd
   exec {_Dbg_fd}<&-


On Dec 12,  9:47am, Peter Stephenson wrote:
}
} Certainly expected by me: "close" means completely close the file
} descriptor. I think the only alternative (that would allow you to
} leave it open for one of reading or writing after opening it for both)
} would be to close it and reopen it, which is a larger side effect than
} I would expect.

It's also possible to do it explicitly, so having it happen implicitly
would be strange.

} I'm happy to hear alternative interpretations, of course.

It can't work differently without breaking a lot of stuff. It's quite
common for all of stdin/out/err to be open for both reading and writing
when the shell gets them.  If <&- closed only the "reading half" of fd
0, that descriptor slot would remain occupied and other scripts/programs
that rely on the "lowest available numbered descriptor is re-used on
next open" semantics would go haywire.

On Dec 12, 11:08am, Peter Stephenson wrote:
} Subject: Re: exec {_Dbg_new_fd}<>&-
}
} Greg Klanderman wrote:
} > Then does it make sense to have both?
} 
} If you didn't (i) people would forever be guessing which one they were
} supposed to use (ii) you would have to match "exec {fd}>file" with
} "exec {fd}<&-" or vice versa (iii) it would be incompatible with what
} we've got anyway.

And incompatible with the way the Bourne shell has worked for decades.