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

31–40 of 90 posts

Re: ht: Headless Terminal

#31

Post by hitchstory »

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

Re: ht: Headless Terminal

#33

Post by remram »

I 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.

Re: ht: Headless Terminal

#34

Post by TickleSteve »

remram wrote: post #33

I 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.

libtmux https://github.com/tmux-python/libtmux

Re: ht: Headless Terminal

#35

Post by radlad »

mbreese wrote: post #30
shanemhansen wrote: post #25

Earlier quoted context omitted.

That would work but wouldn't making http requests to the docker socket itself be a little easier? Example: curl --silent --unix-socket /run/user/1000/docker.sock http://v1.41/version From: https://dev.to/smac89/curl-to-docker-through-sockets-1mhe You could even do something like a reverse proxy to very limited paths although I tend to think that would ultimately be a bad idea and making your own http calls is probabl…

You probably don’t want to expose that service to the internet… I see this as something like the console management for VPS. Back in the day, I remember reading about how prgmr.com had setup a console that you’d directly SSH into. That’s now this interface [1] (and a company name change), but I could see how programmatically working with this would be helpful. [1] https://tornadovps.com/documentation/vps-console

The comment you're replying to mounted the Docker daemon as a local socket, accessible only on the machine. (It exposes an HTTP server still.)

I don't see why one would be any more comfortable exposing a shell to the internet than the Docker daemon. It grants _more_ capabilities. Either should likely be protected by authentication.

Re: ht: Headless Terminal

#36

Post by andyk »

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).…

Hey, project lead here. I had a very specific use case in mind: I’m playing with using LLM agent frameworks for software engineering - like MemGPT, swe-agent, Langchain and my own hobby project called headlong (https://github.com/andyk/headlong). Headlong is focused on making it easy for a human to edit the thought history of an agent via a webapp. The longer term goal of headlong is collecting large-ish human curated datasets that intermix actions/observations/inner-thoughts and then use those data to fine-tune models to see if we can improve their reasoning.

While working on headlong I tried out and implemented a variety of ‘tools’ (i.e., functions) like editFile(), findFile(), sendText(), checkTime(), searchWeb(), etc., which the agents call using LLM function calling.

A bunch of these ended up being functions that interacted with an underlying terminal. This is similar to how swe-agent works actually.

But I figured instead of writing a bunch of functions that sit between the LLM and the terminal, maybe let the LLM use a terminal more like a human does, i.e., by “typing” input into it and looking at snapshots of the current state of it. Needed a way to get those stateful text snapshots though.

I first tried using tmux and also looked to see if any existing libs provide the same functionality. Couldn’t find anything so teamed up with Marcin to design and make ht.

playing with the agent using the terminal directly has evolved into a hypothesis that I’ve been exploring: the terminal may be the “one tool to rule them all” - i.e., if an agent learns to use a terminal well it can do most of what humans do on our computers. Or maybe terminal + browser are the “two tools to rule them all”?

Not sure how useful ht will be for other use cases, but maybe!

Re: ht: Headless Terminal

#39

Post by andyk »

TickleSteve wrote: post #34
remram wrote: post #33

I 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.

libtmux https://github.com/tmux-python/libtmux

Oh this is cool. I looked at using tmux before we built ht because I’ve used screen and tmux forever. I didn’t find libtmux though. Will def check it out.

Re: ht: Headless Terminal

#40

Post by andyk »

m1keil wrote: post #2

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

I shared the motivating use case for why Marcin and I built this (LLM agents using terminals) in a diff comment but I’ll also expand the readme to give examples of use cases.
Post reply on HN