Earlier quoted context omitted.
Potentially readline? https://en.wikipedia.org/wiki/GNU_Readline
More likely reinforcement learning, I think.
Yes reinforcement learning. Apologies for the jargon.
ht: Headless Terminal
71–80 of 90 posts
Re: ht: Headless Terminal
#72Reading 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).…
to me this seems essentially like 'screen/tmux without the multiplexing features' which is useful because most of us do 'terminal multiplexing' via our window manager and we're really just using screen because we want to detach the process from the terminal session (e.g. as a glorified nohup wrapper). another similar tool is `nq`.
That’s “most of us who aren’t ssh’d into a remote machine” because ssh once and tmux thereafter beats ssh’ing in ever window/tab.
Re: ht: Headless Terminal
#73Earlier quoted context omitted.
`expect` is absolutely geared towards scripting, as it's an extension of TCL. Though as far as getting a "current terminal view" `expect` has `term_expect`: https://core.tcl-lang.org/expect/file?name=example/term_expe...
Sorry, my wording wasn't very clear. I wasn't trying to imply that ht is more geared towards scripting than `expect` (in fact I'd say `expect` is more scripting-oriented being an extension of a scripting language) but rather that ht is more geared towards scripting the terminal as a UI than `expect`. Am I wrong about that? (I may very well be since I haven't used `expect` before)
I see what you're saying. When I was writing scripts in `expect`, I didn't really ever try to automate tui programs. So, this could absolutely be a better way to script the the terminal as a ui as you said.
I'll certainly tuck it into my toolbox. Thanks :)
Re: ht: Headless Terminal
#74I 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 s…
Look up OSC 52 for a standard that lets apps and the terminal exchange clipboard data.
Re: ht: Headless Terminal
#75Thank you for providing a musl binary. https://github.com/andyk/ht/releases/expanded_assets/v0.1.1
Is it even feasible to provide gnu binaries? I only upload statically linked musl binaries as Linux releases for my cli stuff.
Re: ht: Headless Terminal
#76Earlier quoted context omitted.
I don't think you can reasonably use expect with TUIs, but you can use this with TUIs.
I tried to contrast to `expect` in a couple of my other responses, but yeah this is my sense too after looking briefly at `expect` - that ht always transparently sets up a terminal for you under the hood and you interact with that so you can always grab a screenshot of any terminal UI. I don’t think `expect` is targeted at this use case (though I am only learning about `expect` right now so could be wrong)
Is it fair to say that 'expect vs ht' is the same as 'curl vs headless browser'?
Re: ht: Headless Terminal
#77Reading 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).…
The immediate thought I had upon reading the description was "this would be great for Minecraft servers". Most of us running Minecraft servers on Linux have it wrapped in screen or tmux because the CLI is the only way to issue certain commands including stopping it properly. This could provide an alternative.
What I typically do is create a systemd service for game servers and attach a TTY. That way it starts with the rest of my web services, and linux already handles "i/o to processes" via files that other process can access(e.x. /run/minecraft/{stdin,stdout,stderr})
Re: ht: Headless Terminal
#78This is an awesome project. It aligns with what I was hoping to get out of expect for certain interactive commands but had a hard time doing. Like selenium or cypress for terminals. I could see this being valuable for end to end testing developer tooling workflows. Maybe it was me not knowing enough about expect. Looking forward to seeing what comes next!
Re: ht: Headless Terminal
#79Earlier quoted context omitted.
I tried to contrast to `expect` in a couple of my other responses, but yeah this is my sense too after looking briefly at `expect` - that ht always transparently sets up a terminal for you under the hood and you interact with that so you can always grab a screenshot of any terminal UI. I don’t think `expect` is targeted at this use case (though I am only learning about `expect` right now so could be wrong)
Is it fair to say that 'expect vs ht' is the same as 'curl vs headless browser'?
I believe it’s a pretty good analogy, yes.
Re: ht: Headless Terminal
#80Thank you for providing a musl binary. https://github.com/andyk/ht/releases/expanded_assets/v0.1.1
You’re welcome :) The asset names got slightly weird in this release (and GH doesn’t let me change it because there’s a dot in the name and it prevents removal of file extension), but with a future release the GH action should name them better. But you would probably rename the downloaded file anyway.