That's pretty interesting. What would be an example use case of this?
could be useful for llm tools using the command line
Yep this was my main reason for wanting it, though lots of other good ideas in these HN comments.
ht: Headless Terminal
41–50 of 90 posts
Re: ht: Headless Terminal
#42I think it is a really good idea to separate vt100 emulation "backend" from the UI. Then all terminal emulators could use a common implementation and just focus on displaying the text, instead of emulating quirks of 50-year old devices. Using JSON as RPC also seems like a good idea, especially when SSH-ing in, as the language server protocol has shown. That being said, I don't see this project doing anything (yet?) a…
Is there an actually convincing simple protocol for a 2D character buffer? (As opposed to a jumped-up typescript like the DEC terminals.) I’ve tried looking at the IBM tradition, and while it’s certainly different, I wouldn’t say it’s better on this particular point.
(There is also the part where a VT100-style display is a bit more than just a character buffer—there’s rewrapping on resize, for example, which IIUC be on for some lines and off for others—but let’s assume we’re willing to postpone updating window contents until the resize is concluded so can afford to do that on the application/VT100-processor side. Even though that feels like 1995.)
Re: ht: Headless Terminal
#43i dont see any way of actually typing key presses, like modifiers. This project looks pretty interesting, maybe i'm missing something.
Include in your input json the ascii control character that the keyboard combo would generate (e.g., \x03 for ctrl-c).
To send control-c to the terminal, for example, you'd send the following JSON message to ht:
{ "type": "input", "payload": "\x03" }Re: ht: Headless Terminal
#44I think it is a really good idea to separate vt100 emulation "backend" from the UI. Then all terminal emulators could use a common implementation and just focus on displaying the text, instead of emulating quirks of 50-year old devices. Using JSON as RPC also seems like a good idea, especially when SSH-ing in, as the language server protocol has shown. That being said, I don't see this project doing anything (yet?) a…
Most sequences used by CLI apps that are supported by popular (widely used) terminal emulators are supported here, i.e. there's good compatibility with VT100/VT220/VT520/etc.
At the moment there's no support for mouse and clipboard - ht uses asciinema's avt for terminal emulation, where this was never needed (although may be added to avt if ht will need it).
Regarding the colors: internally there's full support for standard indexed colors (palette) and RGB. The "getView" call currently returns a plain text version of the screen buffer, stripped of all color information (plaing text is what andyk's headlong project, which uses ht, needs), but we can easily make it return color attributes for each cell or segment of text (either by modifying "getView", or adding complementary "getRichView" or sth like that).
Re: ht: Headless Terminal
#45I was wondering about this, is there a tmux API that is not command-line? A way to access the tmux socket directly? I would rather not multiply the number of tools I use, even though ht might be more appropriate in a clean-room environment.
I've created tmuxr, an R package to manage tmux [0].
Re: ht: Headless Terminal
#46Seems like it could be useful for e2e testing of command line applications
You could always try https://github.com/microsoft/tui-test too. It could still use some more polishing on my part though
Re: ht: Headless Terminal
#47Would be awesome for ui testing.
Re: ht: Headless Terminal
#48Reading the readme, I find myself wondering what problems this solves for. The example of wrapping nano strikes me as particularly odd, since editing files is already fairly easy to do programmatically either via direct file operations or with tools like sed. Aside from editors, most tools that offer a tui also expose the functionality for programmatic access (typically with some additional flags to the same binary).…
I wrote an integration testing framework which I wanted to integrate with a tool exactly like this so it could be used to, e.g. test a command line app like vim. Expect is what I tried to integrate with first. It falls over quite quickly with any kind of app that does anything mildly complicated with the terminal.
Interesting. When we decided to build ht we didn't compare it to expect (which I hadn't heard of or used) but I'm comparing the two now as they seem related.
How exactly did `expect` fall over?
From what I can tell, expect does not provide the functionality of a stateful terminal server/client under the hood for you so it isn't as easy to grab "text" screenshots of a Terminal User Interface, which is one of the main motivations behind ht (will update the readme to make this main use-case more clear)
Re: ht: Headless Terminal
#49First impression: nifty. Having sat with it a few minutes though, why would I choose this over the classic: https://core.tcl-lang.org/expect/index or any of its analogs such as: https://pkg.go.dev/github.com/google/goexpect https://pexpect.readthedocs.io/en/stable/ https://www.rubydoc.info/gems/ruby_expect/1.6.0/RubyExpect/E... edit: ah. it preserves the UI. This has potential.
thanks for surfacing `expect` to our attention. I'll add a compare/contrast to the ht readme
Re: ht: Headless Terminal
#50i dont see any way of actually typing key presses, like modifiers. This project looks pretty interesting, maybe i'm missing something.
To expand on what andyk wrote in the sibling comment:
Programs running in a terminal don't get individual components of composite key presses such as ctrl+a, shift+b, so they don't see "a with ctrl modifier" or "b with shift modifier". The modifier keys are handled by terminal emulator before sending the key's ascii value to the program, modifying the regular ascii letters appropriately. So when "a" (ascii value 0x61) is pressed while holding shift, its ascii value is ... shifted (down) by a constant 0x20, making it ascii 0x41, which represents "A". Similar with ctrl key, which shifts down the ascii value by 0x60, turning "a" into 0x01. So to send "ctrl+d" you send input with a single byte of value 0x04 ("d" ascii 0x64 minus 0x60). ht uses PTY under the hood, and this is how you send keyboard input into to a program via a PTY. This is kinda low level though, and there's definitely a possibility of implementing a high level input method in ht, which would parse string such as "" and automatically turn it into 0x04 before sending it to the process.
In other words, the way input in ht works right now was the easiest, simplest way of implementing this to get it out the door.