exec {_Dbg_new_fd}<>&-

exec {_Dbg_new_fd}<>&-

[Rocky Bernstein]

In all of the terminal detection stuff I noticed that running script
bug.zsh with this contents:

exec {_Dbg_fd}<>$TTY
exec {_Dbg_fd}<>&-

prints this:
  bug.zsh:2: parse error near `&'

I think this agrees with ksh93t

However if I change the offending line to:
  exec {_Dbg_fd}<&-
  exec {_Dbg_fd}>&-

I get:


bug.zsh:3: file descriptor 12 out of range, not closed. And ksh
doesn't seem to complain.
I gather that closing _Dbg_fd for input also closes it for output.

Is this the expected or okay?

Thanks.

Re: exec {_Dbg_new_fd}<>&-

[Peter Stephenson]

"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.
> I gather that closing _Dbg_fd for input also closes it for output.
> 
> Is this the expected or okay?

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.  I'm happy to hear alternative interpretations, of course.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: exec {_Dbg_new_fd}<>&-

[Greg Klanderman]

>>>>> Peter Stephenson <pws@csr.com> writes:

> Certainly expected by me: "close" means completely close the file
> descriptor.

Are you saying that

  exec {fd}<&-
  exec {fd}>&-

do exactly the same thing?  Then does it make sense to have both?

> 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.  I'm happy to hear alternative interpretations, of course.

I guess socket fds could support half close with shutdown()..

greg

Re: exec {_Dbg_new_fd}<>&-

[Peter Stephenson]

Greg Klanderman wrote:
> Are you saying that
> 
>   exec {fd}<&-
>   exec {fd}>&-
> 
> do exactly the same thing?

I believe so; I can't see any obvious difference.

> 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.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: exec {_Dbg_new_fd}<>&-

[Bart Schaefer]

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.