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 ?

[mattn]

👍 x 256

[sbinet]

yes, please. especially the pty feature (which currently lives under github.com/kr/pty) which is always a bit subtle to handle right.

[rsc]

I am not sure about this one: terminal handling may not be significant enough for its own subrepo.

In general the subrepos seem to be mirroring our top-level standard library directories (sync, net, crypto, ...). It's certainly true that the ssh terminal code does not belong in crypto.

That said, I don't know where else to put it either. Let's see if any other suggestions arrive.

[gdamore]

yes! I am willing to help here. I'd like some higher level primitives, and frankly expressing things in terms of POSIX termio functions would be really nice. It could even be possible to express Windows console APIs in such terms.

In addition to just enabling / disabling raw & cooked mode (and echo/noecho), I see specific needs around:

• baud rate determination (used for real serial lines, but even console programs need it -- for example curses type apps need to know "baud" rate when calculating padding character delays required in terminfo strings
• tcflush & tcdrain
• serial port manipulation (stop bits, parity, etc.)

I'd far rather this all be expressed in terms of POSIX termios than some other way, at least to applications. (Using ioctls or whatever under the hood is fine.)

[bradfitz]

@rsc wrote:

In general the subrepos seem to be mirroring our top-level standard library directories (sync, net, crypto, ...).

Perhaps in that spirit we create golang.org/x/os then, for operating-system specific packages. I have a bunch of code myself in various repositories I'd love to centralize, for things that differ between Linux/Mac/Windows. Terminals seem like it could go under x/os.

[distributed]

Yes, please. I'm the author of github.com/distributed/sers, a way too noncomprehensive serial port library. I basically wrote it because I needed to set "non standard" baud rates to speak with hardware.

I would be glad to help out, should the proposed subrepo become reality.

[kim-racktop]

I have some preliminary code I wrote for the Posix tc functions that I have tested on Illumos. I could contribute that if people think it would be useful. I created a branch of x/sys in my local copy and have the code in x/sys/term.

[peterh]

With respect, I disagree that there isn't enough terminal handling to warrant its own subrepo. The termcap/terminfo parser alone would probably be a decent size, in addition to all the other things already mentioned. Plus all the os-specific versions of the interfaces for output (colours/styles/cursor positioning) and input (Ctrl-, Alt-, Fn-, Arrow-, etc keys) on non-Unix-like OSes.

I looked at the links in the proposal, and (like my own liner) none appear to support terminfo (or... is there a Plan 9 equivalent?). That's probably because everybody independently figured it wasn't worth the effort to write a terminfo parser for a single project. If the library and the effort are going to be shared, I'd be more likely to help.

[gdamore]

If we go beyond just termios, into terminfo parsing and so forth, yes, this
would be quite a bit bigger.

I wrote a fairly complete terminfo parser in tcell see
github.com/gdamore/tcell

(Its a little special purpose, because I don’t pick up all terminfo
keywords for storage, because most terminfo capabilities are useless in
modern terminals. But I have a full parser and expander, including a
complete implementation of TParm and TGoto.)

The low level half of tcell (basically everything in the base tcell
package) is probably what you’d want if you’re going to be doing rich
terminal work. This API may still be a little higher level than we’d like
to express in the core Go library though. (For example it has fairly rich
color mapping support, mapping any RGB value into the supported colors of
the terminal, including best-match color on 256 color terminals.) The
entirety of the base tcell package is about 7KLOC, plus a few KLOC for the
preparsed embedded terminfo database. (Basically I precompile the most
likely terminals into the code in an attempt to minimize dependencies on
external database files.)

On Fri, Oct 30, 2015 at 11:52 AM, Peter Harris notifications@github.com
wrote:

With respect, I disagree that there isn't enough terminal handling to
warrant its own subrepo. The termcap/terminfo parser alone would probably
be a decent size, in addition to all the other things already mentioned.
Plus all the os-specific versions of the interfaces for output
(colours/styles/cursor positioning) and input (Ctrl-, Alt-, Fn-, Arrow-,
etc keys) on non-Unix-like OSes.

I looked at the links in the proposal, and (like my own liner
https://github.com/peterh/liner) none appear to support terminfo (or...
is there a Plan 9 equivalent?). That's probably because everybody
independently figured it wasn't worth the effort to write a terminfo parser
for a single project. If the library and the effort are going to be shared,
I'd be more likely to help.

—
Reply to this email directly or view it on GitHub
#13104 (comment).

[frederich]

I quite agree like Brad x/os.