Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ht: Headless Terminal

github.com

Post reply on HN
Print view View original

11–20 of 90 posts

Re: ht: Headless Terminal

#11

Post by MobiusHorizons »

Reading 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). So it just strikes me as the wrong abstraction to interact with most things.

The other potential goal I could imagine was automation. If that is the case, I would recommend the author to make that more clear in the examples and also to describe it in relation to `expect`, which would probably be my go to tool for such use cases.

Whatever the case it does look like a fun project, even if I don’t see any cases where it would be the right tool for the job.

Re: ht: Headless Terminal

#14

Post by craftkiller »

m1keil wrote: post #2

That's pretty interesting. What would be an example use case of this?

My first thought was using it as a compatibility layer for VT100-style CLI programs. Hypothetically, if we wanted to finally replace VT100 emulation and move to some new legacy-free protocol for terminals, we would need some sort of shim for running legacy VT100 programs and displaying them in our shiny new VT-next terminal. Similar to the `vt` program from plan 9.

Re: ht: Headless Terminal

#16

Post by jauntywundrkind »

Combined with nohup, this could probably be useful for detaching/reattaching to long running processes across user sessions?

I'm back to using tmux again, but for a while I was using another program dtach, to start vim sessions that I could disconnect and reattach to. Inside neovim I'd have a bunch of terminals & buffers & what not, so it felt redundant having tmux also hosting an event higher level environment.

Dtach is super super lightweight. Tmux is keeping copies of each screen in memory, is doing some reprocessing. Dtach is basically a pipe wrapping input a program's input and output, data in data out.

I even wrote a little shell script to let me very quickly 'dta my-proje' which will go autocomplete my-project name and either open the existing dtach session in that project or go create dtach session with vim in it. https://github.com/jauntywunderkind/dtachment/blob/master/dt...

It would be interesting to see something like dtach used for automation or scripting, as it seems targeted for. The idea of being able to relay around the input and output feels like it should have some neat uses. There isn't really a protocol, afaik, and there's definitely no retained state for a getView like ht. But it should in many ways function similarly?

Re: ht: Headless Terminal

#17

Post by woodrowbarlow »

MobiusHorizons wrote: post #11

Reading 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`.

Re: ht: Headless Terminal

#20

Post by mariocesar »

MobiusHorizons wrote: post #11

Reading 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 had this issue of needing to control Docker containers in a VPS, without sharing access to the server itself. It seems like it will be easy to create a simple web service that can communicate with the ht API, list my containers, show me the stats, and restart containers if I want to. I can manage all security in the web service.

This could be a nice case.

Post reply on HN