[burglekutt]

Intriguing idea! I love the idea of having a database of the commands you’ve run and their output. I use tmux religiously, but it’s sometimes frustrating using a crappy interface to spelunk my terminal history and manually look for the various commands I’ve run amidst voluminous output. And of course it’ll lose that history when it runs out of buffer.

Question: You refer to this as a shell, but it seems more like a terminal emulator. Am I missing something?

A couple ideas for different ways to achieve the goal:

1. It seems like a web UI rather than a native app would be beneficial for various reasons (run anywhere, connect remotely, coded in the UI lingua franca, etc).

2. I could see value in separating the shell and the history browser. Like the shell is just your shell, and it can be used via whatever terminal emulator that people want to use, or even thru ssh. The only thing the shell does above and beyond any other shell is to pipe stuff to the database. If the user wants to look at history, then they go to the web UX (ala suggestion 1) to do that.

Doing this would make it more palatable for people to start using it because it wouldn’t change the feel of their daily experience, but in the background, they’d be getting the cool features.

[snapplebobapple]

You can run atuin locally or synced for that feature. Atleast, that is how i have been doing it up to now.

https://atuin.sh/docs/

[jyxent]

You're missing the 'and their output.'

[yjftsjthsd-h]

> I love the idea of having a database of the commands you’ve run and their output.

Once upon a time, I rigged... I can't recall if I did it in tmux or the shell profile, but I made my system spawn every new shell under script(1) by default (with some logic to check that you weren't already nested to avoid infinite loops, and some way to start a shell that didn't use it just in case), which resulted in a nice directory with text files listing every terminal session i had. I think it ended up not being all that useful and there was either real or perceived performance impact so I didn't bother implementing it again when I switched machines, but the idea did seem neat.

[LarryClapp]

Thanks!

> You refer to this as a shell, but it seems more like a terminal emulator. Am I missing something?

It has elements of both. I think it's closer to a shell because its primary purpose is to run commands, like bash. It has a terminal emulator, and you can run interactive programs (like Vim, or even bash) inside a hucksh command widget, but (from my point of view) the terminal emulator is there mostly so that programs that output ANSI/ncurses escape sequences don't look like absolute crap. (Many programs don't even check whether they're writing to a TTY, and/or don't check what kind of terminal they're in, they just unconditionally write xterm or vt100 ANSI codes.) I don't think you're missing anything, we just focus on different things.

> web UI

That's funny, I initially started with a web UI. Before, I was using Angular, and called it "ntla", which meant "Never Type `ls` Again". As a mostly backend-developer, the, uh, intricacies of HTML and CSS, even using Angular or Vue, ended up being a pretty difficult learning curve to climb. When I saw Gio, the completely-Go-based library I'm using now, presented at GopherCon a couple of years back, I fell in love and that actually got me to restart development of hucksh.

Gio can actually compile to WASM and I'd like to eventually enable a web-based interface. Which is admittedly not what you're saying. :)

Hucksh can actually connect remotely by forwarding the connection it uses over ssh. There are instructions for that in the documentation. Admittedly that requires more configuration and permissions than a webpage, but there are other tradeoffs. I use hucksh remotely all the time, with the UI running locally and talking to a remote backend. Using autossh and hucksh's native auto-reconnect, my laptop can go to sleep and automatically reconnect to the remote within a few seconds of awakening.

> separating the shell and the history browser

Yeah, I could see that.

There is a rudimentary command-line interface to the back-end. `hucksh cli <some-command>`. There might be a way to shim that into the bash REPL so that it uses "hucksh cli" to run commands instead of executing them directly. I, at least, would miss the rest of the UI. It's worth thinking about, if other people like the idea too.

Thanks for your comment and encouraging words!

[20after4]

Personally I thought it was cool that you replaced the shell AND the terminal. I honestly feel like we need a re-imagining of computer interfaces. CLIs are cool but the current state of the art is lacking. So kudos on what you're doing.

I don't think I will become a user because I'm a radical free software purist but I like what you're doing and I think it's the kind of outside the box thinking that's needed if the shell is to ever move far beyond "1980s state of the art".

Another interesting take on entirely rethinking the shell: https://arcan-fe.com/about/

[LarryClapp]

Thanks! Yeah, improving the state of the art beyond TTYs is a core idea of hucksh.

> ... radical free software purist ...

Yeah, I get that. Someone on Reddit mentioned the same thing. No worries. I'm definitely a fan of free software too (Vim user since, like, 1995, to name one), just not a purist.

I'll take a look at Arcan.

Cheers & thanks again!