Conversation
|
With all three PRs merged, T-W finally works on Windows:
\o/ |
|
I'd like to get feedback on the PRs first and when things look good release Terminal-API. This will allow me to still make changes to T-API without burning version numbers. |
| IO::Handle:D :$input = $tty.open(:r), | ||
| IO::Handle:D :$output = $tty.open(:a), | ||
| IO::Handle:D :$input = $*IN, | ||
| IO::Handle:D :$output = $*OUT, |
There was a problem hiding this comment.
This one I'm hesitant about. I've been trying to keep T::W able to handle multiple TTYs from the same program, and this would block that out (unless $*IN and $*OUT were overridden, of course).
Why doesn't TTY opening work on Windows? Is there an equivalent operation that could be used instead?
There was a problem hiding this comment.
Quoting myself 😋:
This is a hack, as I'm now ignoring the $tty parameter for actual in/out retrieval.
Any ideas of how to do this cleanly in a cross-platform manner?
IIUC the $tty parameter (a path to /dev/ttyX is in general only used as an identifier for a tty of which there can be many. I'll have to read up on how this works on Windows, but I think TTYs are not represented as files. I'll dig into this some more. But if you have an idea, do tell! Maybe use the FD as an identifier?
There was a problem hiding this comment.
Quoting myself 😋:
This is a hack, as I'm now ignoring the $tty parameter for actual in/out retrieval. Any ideas of how to do this cleanly in a cross-platform manner?
Yep, I was meaning more "What actually is the Windows replacement, or is there one?" But I guess your following paragraph indicates it's not clear what the replacement should even be ....
IIUC the
$ttyparameter (a path to/dev/ttyXis in general only used as an identifier for a tty of which there can be many. I'll have to read up on how this works on Windows, but I think TTYs are not represented as files. I'll dig into this some more. But if you have an idea, do tell! Maybe use the FD as an identifier?
Supposedly /dev/tty (no additional characters) is special, and supposed to always be the name of the program's controlling terminal on POSIX-like systems -- this is why that's the default for the name used at line 47 of that file. Maybe there is an equivalent special name for the controlling TTY on Windows?
By the time control flow gets to line 17, the TTY is supposed to be in the form of a (Raku-level) open IO handle, either because of the .IO coercion on line 48 or the pass-through on line 43. Then lines 18 and 19 are simply asking to dup that Raku-level handle with different R/W modes, assuming they weren't provided explicitly.
So maybe an alternative is to either explicitly pass input and output on Windows, or to change the defaulting logic there.
There was a problem hiding this comment.
I've shuffled things around a bit. I think the situation should be better now.
patrickbkr
force-pushed
the
unblock-windows
branch
from
9df7299 to
e698b5a
Compare
|
@japhb Can we get this PR, next to these merged and released?
People keep hitting missing Windows support. |
|
Merging and then cleaning up comments slightly. |
2 participants
This is a hack, as I'm now ignoring the
$ttyparameter for actual in/out retrieval.Any ideas of how to do this cleanly in a cross-platform manner?
Part of a set of PRs in Terminal-LineEditor, Terminal-Print and Terminal-Widgets.
Don't merge yet, Terminal-API isn't released yet!