x/term: create subrepo for terminal, console, pty and tty related packages

[davecheney]

Following the lead of #13058 towards smaller, more focused, sub repositories, I would like to propose the creation of a sub repo for packages related to handling the interaction with tty like things. This includes

• posix ttys and ptys
• serial termios control, like terminals and rs232 devices.
• windows cmd console

Much of the code for this exists in various packages, some in other sub repos like x/crypto/ssh/terminal, others has been duplicated incompletely by package authors with a specific use case; most times without a comprehensive story for windows.

Various informal proposal have been made, like #12853, relating to posix termios.

Other proposals like #12101 for the creation of an x/sys/terminal group of packages have been rejected on the grounds that sys is too low level, which also dovetails into the desire for more smaller sub repos, rather than larger ones.

There is also the the long standing question of why the code to disable terminal echo lives in the x/crypto/ssh package.

With the exception of the name of the repository, which I'm sure will require debate, is there general support for a sub repository along the lines outlined in this proposal ?

[gdamore]

I don’t think so, no. Properly handling ANSI starts to get a lot more complex, because then you want a full terminfo parser, except on Windows where you do something different. Frankly, that’s a meaty bit of work (I know because it exists in my tcell package), and I don’t really think that belongs in core go. That really feels like more of a 3rd party package delivery, like tcell, to me. (Much like GUI/widget toolkits don’t really belong in core go either, I think.)

On Tue, Nov 10, 2015 at 9:16 PM, Andrew Gerrand notifications@github.com wrote:

Would ANSI escape sequences not be in this repository? Maybe I misunderstand the scope.​

— Reply to this email directly or view it on GitHub https://github.com/golang/go/issues/13104#issuecomment-155669424.

[techtonik]

Let me offer up x/tty

While nobody actually uses teletypes anymore this interface used with stty and the termios ioctls on UNIX systems covers all the bits one needs for handling tty devices while remaining low level.

Furthermore it will be possible to emulate this functionality easily for Windows. The idea of setting raw mode, disabling or enabling buffering and echo are pretty universal. Windows consoles can offer some enhanced functionality as well but for something like the needs of ssh that is entirely unnecessary. (Extras like double buffering and mouse reporting.)

Please don't use TTY for cross-platform stuff. It is overly complicated concept that may take up to 3 days to understand what is it about. The idea of setting raw mode, buffering and echo doesn't belong to the world of text mode user interfaces at all - all these hacks are made to make limited one-input-channel serial interface work for users, so maybe x/serial is what you need? My perception is that Linux terminal is slow and error-prone state machine - it is not nearly as fast as Windows console, and all this multiplexing/demultiplexing is the reason. Also think that clipboard copy/paste functions are also the things that are expected from the console, as well as multiple buffers that help to work with multiple outputs in parallel.

[techtonik]

If I understand correctly, both Windows console and ncurses use asynchronous events while TTY and Linux terminals with are synchronous beasts.

[davecheney]

@techtonik thank you for your feedback.

I understand that this proposal is not an exact match for the capabilities of the windows console, but this is not the specific goal of this proposal.

There is a need for a set of packages that manages tty like streams of bytes connected to text console like devices. These might be terminals, or windows cmd.exe, or remote ssh sessions, or serial terminals, and so on.

These facilities have been implemented over and over again on an as needs basis by many authors and are usually incomplete -- And the missing piece is overwhelmingly windows support. There are many serial handling packages, few support windows. There are many ncurses style packages, few support windows.

You are correct that adopting an api that treats cmd.exe as a stream of bytes will be an incomplete abstraction. Such limitations also exist by treating xterm's like pty's. I'm sure similar restrictions exist for plan9 rio windows, but I have no direct experience.

In return for giving up a little performance, or a little control, what all Go developers stand to gain is one package that everyone can use to do simple things like

• open a serial device, and set it's baud rate
• disabling terminal echo when entering passwords
• the raw mechanics necessary to implements readline type cli interfaces
• and of course to be a base for more complicated projects.

I'm also confident that where necessary the correct holes can be poked in the API to permit developers who want to exploit platform specific facilities to have access to those APIs.

Can you see your way to agreeing that this proposal is trying to make things better for windows developers ?

Thanks

Dave

[techtonik]

Why so many people tried to reinvent the console/terminal and failed? Being able to compare two worlds, I don't see that stateful OS API works at all. State belongs to user level. OS should only define who has focus to receive input and filter the critical key combinations that are needed by parent.

• "open serial device and set baud rate" - x/serial
• "entering password" - ideally it should be readkey/getkey - to process Y/n in one keypress, but this is really hard - see my code below - maybe even impossible to do with terminal abstraction - terminal doesn't process keys like F1, it doesn't return scancodes and if you make TUI menus with shortcuts (like all Linux programs do) - they break when you change keyboard layout - in Far Manager (my "vimacs" for Windows) it doesn't happen
• "the raw mechanics necessary to implements readline type cli interfaces" - what mechanics exactly? why readline is different from other console programs that need to receive keys from keyboard and write colored chars at arbitrary location of screen?
• "and of course to be a base for more complicated projects" - it won't be the base, because the basis - the concept of one stream that does it all is flawed - it is impossible to debug and deal with

My opinion is that terminals, TTY and all that serial stuff must die for text mode interface. Maybe reengineered from scratch for better latency and removed legacy like MOSH, stripped of features that add to technical debt, but these are specialized products.

Just for the example of how things are badly broken - this is my attempt to read the key from terminal/console on Windows and Linux. https://bitbucket.org/techtonik/python-pager/src/2936adb19c9407b8e890949f9e88bf4f0461a524/pager.py?at=default&fileviewer=file-view-default#pager.py-196 What I see here is that if somebody interrupts my program on Linux while I listen for input, the terminal will be broken with no echo. Also there is no way to peek if there are characters in keyboard input. And users report that this stuff doesn't work on OS X, and piping the output is also broken when there is a terminal readkey call in the program flow.

I really hate terminal interfaces, sorry. =/ stdin is not enough for user interface not matter what. The read console interface needs to start with user stories and instead of concentrating on that should be done with two wires, separate the stuff into what is practically possible over the terminal and what should use things like https://mosh.mit.edu/ and https://bitbucket.org/libtcod/libtcod and provide support for latter.

For me, the user is primary, so if we start with TTY and then at some point discover that https://bitbucket.org/libtcod/libtcod is not possible - that's would be fail - the same fail that the dozen of other packages already did. So, I feel that creating and good library for text mode interfaces for Linux, Windows and ... may be impossible at this point, but what can help is to form an API for a operating system that may not yet exists. Going with plain terminals for something that libtcod does is the same as trying to build the house by sticking balls with a chewing gum. That's my point.

[techtonik]

To summarize, if you need to emulate those crutches on Windows, go with x/term.

[cznic]

My perception is that Linux terminal is slow and error-prone state machine - it is not nearly as fast as Windows console, and all this multiplexing/demultiplexing is the reason.

I don't think this claim is based on evidence and I believe it is important to get the facts right before adopting a decision based on them.

There exist opposite experiences. Quote from golang-codereviews

This adds at one new syscall for every print to without a console and four new syscalls for every print to with an attached console. The Windows console is extreemly slow so the extra syscalls won't be noticable.

Also, googling for "windows console slow" shows a different story wrt what @techtonik is telling us.

[alexbrainman]

Dave,

Serial port is easy: open port, change speed (and other parameters), then read and write bytes. Also read and change serial port status / flags. (I also wander who uses serial ports these days). Serial port can be in a separate package, it does not need to be related to anything else.

Console input and output is something I have never done before. But I just googled and found this http://www.benryves.com/tutorials/winconsole/all - it is a start. I am not sure what you are trying to do, so take it with a grain of salt.

As always I am happy to help any way I can.

Alex

[gdamore]

Huh? Events arrive and are picked up by calling a function in both cases. In the case of ttys it is read while Windows programs can either use read of a console handle or a Windows specific API that can return more than just keyboard presses.

The tty abstraction works equally well for both Windows console.

Sent from my iPhone

On Nov 10, 2015, at 11:17 PM, anatoly techtonik notifications@github.com wrote:

If I understand correctly, both Windows console and ncurses use asynchronous events while TTY and Linux terminals with are synchronous beasts.

— Reply to this email directly or view it on GitHub.

[gdamore]

My work with tcell on both Windows and UNIX is different too. The Windows console is both more and less featureful than UNIX terminals. And I think some confuse cmd.exe with conhost.

Nonetheless this proposal isn't about creating a package that can do all that a package like tcell can or his Far manager needs. Frankly for rich TUIs a bit of OS-specific work is needed for sure. For example terminfo handling is wildly different than the call to manage output attributes on Windows.

What however this proposal is trying to achieve is to give a more portable view of adjusting some basic tty/console handling so that thinks like simply prompting for a password become a little more straight forward. Think of it as a foundation to permit a getpassphrase() implementation to be created.

It also is about providing the low level foundation so that a package like tcell or termbox can be created on top of it, in a way that allows it to run pretty much everywhere without having to hard code specific ioctls or resort to cgo to function.

Sent from my iPhone

On Nov 11, 2015, at 2:06 AM, cznic notifications@github.com wrote:

My perception is that Linux terminal is slow and error-prone state machine - it is not nearly as fast as Windows console, and all this multiplexing/demultiplexing is the reason.

I don't think this claim is based on evidence and I believe it is important to get the facts right before adopting a decision based on them.

There exist opposite experiences. Quote from golang-codereviews

This adds at one new syscall for every print to without a console and four new syscalls for every print to with an attached console. The Windows console is extreemly slow so the extra syscalls won't be noticable.

Also, googling for "windows console slow" shows a different story wrt what @techtonik is telling us.

— Reply to this email directly or view it on GitHub.

[alexbrainman]

Another example of reading from Windows console:

https://helloacm.com/modern-getch-implementation-on-windows-cc/

Alex

[gdamore]

Right. GetConsoleMode() and SetConsoleMode() are the functions I'd probably want to use when building this Windows analog.

There's code for this in tcell too btw:

For example:

https://github.com/gdamore/tcell/blob/master/console_win.go

Note that not everything there is something I'd consider a candidate for this repo.

On Wed, Nov 11, 2015 at 2:55 PM, Alex Brainman notifications@github.com wrote:

Another example of reading from Windows console:

https://helloacm.com/modern-getch-implementation-on-windows-cc/

Alex

— Reply to this email directly or view it on GitHub https://github.com/golang/go/issues/13104#issuecomment-155935181.

[davecheney]

Hi Alex,

How do you control the serial line parameters on windows, guessing its some WSASetSerial type syscall. As far as I know that isnt available in the std lib or x/sys.

Also, at a higher level there is no nice wrapper that takes parameters like baud rate and converts those to their lower level windows or Unix syscalls.

This is what this proposal is, in part.

Thanks

Dave

On Wed, 11 Nov 2015, 21:24 Alex Brainman notifications@github.com wrote:

Dave,

Serial port is easy: open port, change speed (and other parameters), then read and write bytes. Also read and change serial port status / flags. (I also wander who uses serial ports these days). Serial port can be in a separate package, it does not need to be related to anything else.

Console input and output is something I have never done before. But I just googled and found this http://www.benryves.com/tutorials/winconsole/all - it is a start. I am not sure what you are trying to do, so take it with a grain of salt.

As always I am happy to help any way I can.

Alex

— Reply to this email directly or view it on GitHub https://github.com/golang/go/issues/13104#issuecomment-155727833.

[davecheney]

I am genuinely frustrated by the lack of consensus on the utility of this proposal. I had thought that it was something that was clearly needed given the number of overlapping proposals for various ioctl and termios tweaks.

Perhaps it is appropriate that is there is no support I should withdraw this proposal.

[gdamore]

I hope you don't. The missing low level functionality is sorely needed and addressing it here is about the only chance for me to be able to support a package like tcell without having to resort to cgo.

Sent from my iPhone

On Nov 11, 2015, at 8:51 PM, Dave Cheney notifications@github.com wrote:

I am genuinely frustrated by the lack of consensus on the utility of this proposal. I had thought that it was something that was clearly needed given the number of overlapping proposals for various ioctl and termios tweaks.

Perhaps it is appropriate that is there is no support I should withdraw this proposal.

— Reply to this email directly or view it on GitHub.

[adg]

I see a lot of posts in favor of creating such a sub-repo? The only contentious thing I see here is the name. It seems that x/os is out. Of the other proposed names, the original x/term seems best to me.

[gdamore]

As long as we agree about the scope (that is I don't want a curses replacement here! Just low level termios style functionality) then the name isn't such a big deal to me. I can live with x/os too even though it's not my favorite. I'd rather have something than nothing. :-)

Sent from my iPhone

[alexbrainman]

How do you control the serial line parameters on windows, guessing its some WSASetSerial type syscall.

It has been a while, but, I believe, I've used GetCommState/SetCommState.

As far as I know that isnt available in the std lib or x/sys.

GetCommState and SetCommState aren't available, but I can help you with that. Just let me know. I even happy to try and implement windows parts of serial port once you have something working on unix. I have some old code of mine to help me get started.

Alex

[davecheney]

I see a lot of posts in favor of creating such a sub-repo? The only contentious thing I see here is the name. It seems that x/os is out. Of the other proposed names, the original x/term seems best to me.

Thanks @adg. To be clear, I wasn't complaining about the discussion about the name of the repo.

[rsc]

It sounds like this repository will contain code for (1) dealing with consoles/ttys/ptys, (2) termcap-style escape sequence generation and parsing, and (3) code for configuring serial ports. It's a bit of an odd mix, but it's certainly a common grouping historically. Is that list correct, @davecheney?

Based on the discussion here and the inability to find a better name, I think x/term is fine for this set of code. If you can confirm the scope, I'll throw my hat in with x/term and then I think there is sufficient agreement to approve the proposal. Thanks for bearing with us.

[gdamore]

On Nov 12, 2015, at 7:33 AM, Russ Cox notifications@github.com wrote:

It sounds like this repository will contain code for (1) dealing with consoles/ttys/ptys, (2) termcap-style escape sequence generation and parsing, and (3) code for configuring serial ports. It's a bit of an odd mix, but it's certainly a common grouping historically. Is that list correct, @davecheney?

No. Just 1 & 3. Item 2 really doesn't belong here IMHO. It is something easily provided by a third party package like tcell. I don't believe escape sequence handling is something the core ought to be concerning itself with.

That said I would support the idea of one higher level interface being added because it's likely to be so widely used and useful as to warrant being here. That is something akin to getpassphrase() for password prompting. Probably 90% of the most common uses for the lower stuff are based on a need to do just this. Including btw the ssh use case.

• Garrett

  Based on the discussion here and the inability to find a better name, I think x/term is fine for this set of code. If you can confirm the scope, I'll throw my hat in with x/term and then I think there is sufficient agreement to approve the proposal. Thanks for bearing with us.

  — Reply to this email directly or view it on GitHub.

[rsc]

Re @gdamore, this isn't the core. It's a subrepository. And x/crypto/ssh/terminal already has escape code code in it. So if escape codes are out of scope, we can't move x/crypto/ssh/terminal, which was at least part of the point.

[gdamore]

Oh wow. I just saw that. It was a big surprised to me, because IMO there is no reason for that code to live in ssh. Terminfo handling is a much bigger issue, and simple colorizing of text is non-trivial to handle in the general case. What I see there is basic codes suitable for ANSI terminals, but those won't work on every terminal type and are completely inappropriate for Windows consoles.

Indeed, the way you colorize text on Windows really can't be handled by Escape codes at all. The logic here is just Wrong, because it is too naive.

Given all this, I'd argue for leaving that code where it is, deprecating it if we can, and having x/term (or whatever it is called) not provide replacement functionality. Alternatively, we could provide a set of ANSI escapes codes along with an admonition that they should not be used unless an ANSI terminal is use, and that many terminals don't support these escapes.

Looking at what is in ssh, it looks like a naive attempt to provide a limited replacement for readline or somesuch. I'm ... astonished. Is this code "new"?

I feel like this ought to be placed in a package called "prompt" or somesuch, which could import higher level functionality. That would include both terminfo parsing (for UNIX like systems) and probably native console manipulations for Windows. I could build this type of functionality on the low-level bits in tcell ( or contribute parts of tcell to make up this functionality.)

Still, this is far and away larger scope than what I think is absolutely critical, which is providing lower level functions for manipulation of terminfo, etc. That is functionality which I cannot do in native Go on all platforms, so it has to be fallback to cgo. All this other stuff for prompting etc. is higher level functionality that could easily be done in pure Go, given the lower level functionality. (As the ssh package shows.)

The ssh Terminal package is also horribly broken with respect to runes that have a visible width other than 1. That its, it understands neither full width East Asian runes, nor special composing characters.

In retrospect, maybe it is time to promote tcell (or modifications of it) as a replacement for this package. Again, we need to have the core supply the low-level terminfo manipulations for us, though.

Do we know who the consumers of this ssh Terminal package are?

[rsc]

The main user of ssh/terminal is the ssh server. Even if the ssh server is run on Windows, that code makes sense, because ssh clients know about (and send) terminal escape codes as a wire protocol. More generally I think it's okay for the escape codes to be in x/term just as much as serial speeds are. It's all part and parcel of the same 1970s era technology.

[gdamore]

but terminal escape codes aren't part of the wire protocol of ssh.

[rsc]

but terminal escape codes aren't part of the wire protocol of ssh.

In theory, no. In practice, they kind of are. Otherwise there's no way to send, for example, an up-arrow keystroke.

[mattn]

terminal code in ssh package should be internal package or private methods. but too late.

[gdamore]

Agreed. Too late. :-(

The details of an up-arrow mapping are not part of the SSH protocol. Its better to think of SSH like a serial line (8-bit). It passes byte streams unmolested (mostly) between two parties.

The fact that one of those parties is an environment running perhaps in a terminal that can parse certain sequences of bytes as e.g. an up arrow keypress, or as a command to clear the screen, is a private negotiation done between the two parties communicating over SSH. Typically in the case of the server, this means the program that is forked by the server. (E.g. your editor.)

For UNIX, as I'm sure you're aware, this involves setting a $TERM variable, and using a database (terminfo/termcap) that expresses these capabilities. But the thing that looks up the fields in the database is not the ssh server (or client), but rather any interactive program that such server spawns.

(NB: For something like a program running on a Windows console, this is not used at all. That's a very very different environment, and control data like extended key codes and window management operations are sent out of band.)

Scanning briefly at the SSH server code, I have to confess I have no idea why we have this code here. It doesn't look like the SSH server implements a shell, or anything like that. But maybe I'm missing something?

So, all this said, given the unfortunate precedent, I'm ok with extending the scope of x/term to include this type of handling. I think it becomes something like curses or curses-lite (or tcell or termbox) to be useful -- the interfaces exposed by ssh Terminal are just plain wrong, and I wouldn't like to see those interfaces promulgated further.

That said, there are a few interfaces there that are nice. ReadPassword() is a nice/good interface. That can be done entirely without this logic. The only "escape" sequences it needs to understand are CTRL-H (backspace) and perhaps CTRL-U (delete back to beginning of line). Those aren't even escape sequences properly. I'm not convinced that even this is necessary. I think it should be possible to do this entirely without escape sequences by just disabling echo. (Meaning I don't think full raw mode is required to prompt for passwords.)

As I think about this, it feels like there are really several different packages here:

a) x/tty -- low level termio/console mode setting stuff. This is the most basic functionality and the thing that cannot be done without using either cgo or help from the runtime. A reasonable argument can be made for this to live in x/os. I prefer it separate, but as long as the interfaces are agnostic I'm happy to see this limited scope stuff live in x/os. This could include the low level stuff for serial ports too, since historically these are frequently linked together with termios.

b) x/term - building upon the above, adding support for echoing with attributes, getting terminal size, setting cursor location, etc. Sort of termbox or tcell functionality. This is where a terminfo parser for example would live, and where the knowledge of manipulation of Windows consoles would live. This provides the abstraction of different terminal types, etc. This is equivalent to the low level terminfo handling on UNIX (though it would need to have an interface that also supports out-of-band metainformation like Windows consoles use.)

c) x/prompt -- this could involve both a simplistic password prompter, but also a readline or editline replacement, with command history and so forth. This would make it possible to build nice CLIs with an interactive line-editing mode, etc. This could be built upon x/term.

d) x/tui -- this is a full blown TUI package, with windows or view ports, etc. It would build upon x/tty and x/term. In tcell I have a package that does this called tcell/views -- its somewhat limited but it does have widget layering and scrollable view ports, etc. This is sort of the full curses type functionality.

Now I'll point out that its probably quite reasonable for b, c, and especially d to be implemented as 3rd party packages. Indeed, there are two packages that have already done this -- termbox and tcell -- for b & d. (Other packages that do c exist, but they do it via cgo and libeditline or libreadline usually, I think.)

What's really become obvious is that the name is important because it helps define the scope, and I think that we need to resolve the scope before getting to fixated on the name. :-)

• Garrett

On Thu, Nov 12, 2015 at 9:51 AM, mattn notifications@github.com wrote:

terminal code in ssh package should be internal package or private methods. but too late.

— Reply to this email directly or view it on GitHub https://github.com/golang/go/issues/13104#issuecomment-156182504.

[rsc]

We're only creating one subrepo for this code. Subdirectories like x/term/tty and x/term/prompt are fine (and expected).

[davecheney]

We're only creating one subrepo for this code. Subdirectories like x/term/tty and x/term/prompt are fine (and expected).

Yes, this was the design I had in mind.

[rsc]

Proposal accepted. Assigning to @adg for subrepo creation.

[gdamore]

Sounds perfectly reasonable I think. Are we at consensus finally?

Sent from my iPhone

On Nov 12, 2015, at 11:55 AM, Dave Cheney notifications@github.com wrote:

We're only creating one subrepo for this code. Subdirectories like x/term/tty and x/term/prompt are fine (and expected).

Yes, this was the design I had in mind.

— Reply to this email directly or view it on GitHub.

[kim-racktop]

I am not exactly sure what we have consensus on other than the repo name. I do think we should factor out things like the Posix tc* routines into their own subdirectory/package. I agree that something like a full curses replacement is outside the scope of this repository. I am not exactly sure where we should draw the line between these two extremes. What I am hoping to see is that whatever we put into the packages inside this repo isolates me from needing cgo or needing os specific code.

[davecheney]

Hi Kim,

A cursors interface is out of scope, both by the original proposal, and also because none of the underlying plumbing exists.

I suggest we work on that plumbing and we'll probably find the natural boundary around the level of a type that represents the attributes of a tty or console; its echo state, its raw dimensions, possibly its speed (if necessary). Anything above that is probably out of scope for this package

[alexbrainman]

Here https://github.com/alexbrainman/winapi/commit/26571130fc308d5a9dcc6dba41df3a91865ac4f4 are some serial port related APIs.

Alex

[techtonik]

@cznic about performance of Linux terminal vs Windows console. As I said, it is my perception that Gnome terminal (which is default on Ubuntu) is slow as hell. And quick search reveals that Linux terminals are indeed slow https://unix.stackexchange.com/questions/41225/can-a-terminal-emulator-be-as-fast-as-tty-1-6

As for your "windows console slow" the first thing I've got is this https://stackoverflow.com/questions/14295570/why-is-console-animation-so-slow-on-windows-and-is-there-a-way-to-improve-spee and there user runs "CLS" external process for every frame. As for https://groups.google.com/forum/#!msg/golang-codereviews/hq63SCACMJo/KL97UzWeEQAJ which says The Windows console is extreemly slow so the extra syscalls won't be noticable. phrase, then there are two points:

1. there are no any reference to this claim
2. the context in which it was mentioned is that Go doesn't use WinAPI's WriteConsole which probably should be used if you want performance on Windows

If you have any idea how to measure FPS of Linux terminal vs Windows console, I'll be happy to run tests on my machine. Please also note that stdout.print() performance is not the only parameter for measuring speed - keyboard response equally matters (if not even more important).

[techtonik]

It sounds like this repository will contain code for (1) dealing with consoles/ttys/ptys, (2) termcap-style escape sequence generation and parsing, and (3) code for configuring serial ports. It's a bit of an odd mix, but it's certainly a common grouping historically. Is that list correct, @davecheney?

I'd say 2 and 3. Because I believe that dealing with windows console is impossible in the same way as ttys and ptys.

[techtonik]

Right. GetConsoleMode() and SetConsoleMode() are the functions I'd probably want to use when building this Windows analog.

WinAPI contains stateless getch() and kbhit() functions that are more clean and I think more useful. See this implementation in Python https://bitbucket.org/techtonik/python-pager/src/2936adb19c9407b8e890949f9e88bf4f0461a524/pager.py?at=default&fileviewer=file-view-default#pager.py-190

Still there is a big problem how to get exact keycode indifferent of language layout and encoding. Something kind of readKey() function. For some reason I think it is impossible on Linux, but it would be nice if Go could provide an interface for that once kernel is patched to forward that information to active user space process.

[techtonik]

And JFYI, I am working on Windows client for LXC (yes, Linux Containers) and we've just committed ANSI colors support there with the help of external package that parses them and now I am looking how to read arrow keypresses to forward to remote server - https://github.com/lxc/lxd/issues/1317

[gdamore]

Um. I did this. (Get a key etc.) Windows actually has a pretty sane API, and it does map reasonably well. The console modes can be used to construct a fair facsimile of POSIX termios, and for richer console I/O there are the ConsoleOutputCharacter(), ConsoleOutputAttribute(), ReadConsoleInput(), etc.

These don’t play entirely perfectly well with simple input/output (stdin/stdout), but using them its perfectly possible to build a curses or termbox API. This has indeed been done multiple times.

I recommend you have a look at my tcell package, this file in particular: https://github.com/gdamore/tcell/blob/master/console_win.go

On Tue, Nov 17, 2015 at 3:24 PM, anatoly techtonik <notifications@github.com

wrote:

And JFYI, I am working on Windows client for LXC (yes, Linux Containers) and we've just committed ANSI colors support there with the help of external package and now I am looking how to read arrow keypresses to forward to remote server - lxc/lxd#1317 https://github.com/lxc/lxd/issues/1317

— Reply to this email directly or view it on GitHub https://github.com/golang/go/issues/13104#issuecomment-157543038.

[gopherbot]

CL https://golang.org/cl/17020 mentions this issue.

[adg]

The term repo is now created.

[techtonik]

Great! =) Now how can I track all issues there? (and also, is it already possible to use it right from the start in Go 1.5.x?)

[adg]

We still use a centralized bug tracker. Related bugs should have the prefix 'x/term'.

[techtonik]

Okay. Github doesn't allow to subscribe to that. So the only strategy I see is to create all the issues myself. =0

[Julio-Guerra]

• posix ttys and ptys
• serial termios control, like terminals and rs232 devices.

@davecheney @adg I think this package shouldn't expose a unix-like TTY interface but should rather build something smarter and cleaner on top of it. By separating concerns, it should then be even easier to port this package on non unix-like OSes. TTY and PTY are low-level POSIX/*NIX interfaces that should go to x/sys/unix like termios partly is already (the structure only so far)...

In my opinion, this package should only provide an abstraction based on the canonical-mode API (line disciplines + terminal capabilities? + readline?). And make the most out of go's beautiful IO stack: this package should see a serial device as nothing more than a stream of bytes ([]byte) with hardware or software control-flow management.

It is commonly admitted that the TTY API is a messy melting pot of distinct concerns:

• line disciplines.
• serial device management including data transmission, control-flow/handshaking...
• non-canonical/raw mode for blocking/polling/timed reading modes.

Of course it made sense at the time it was built (the 80's is synonym of high space and time constraints), but only time constraints require special kernel attention nowadays (i.e. save time/be fast by letting a kernel handling special cases like clocking a serial line transmission or handling C-z signal asap)...

I even think the 100% user-land implementation in pure go could be experienced given the CPU/serial device speed ratio. This is for example what GNU readline does.