I took a look at my shell history and a frequent pattern of commands was "cd, ls, cd, ls, ...". And I thought "I love my keyboard, but you know, point and click might be nice in this context."
And then I thought, "It'd be even cooler if you could run commands there."
Skip forward several years, a few earlier implementations, a name change, and now there's Hucksh(ell), a bash-like shell that makes it easy to do all that.
There's a directory navigation tab, where you can click around to navigate, use forward and back buttons (like a browser), and also a "navigate" mode where you can select the directory to change to with a single keystroke.
The system remembers every directory you do anything in and lets you choose them from a list, which you can order by name, time last used, or frequency of use.
And finally, of course, there are shell tabs where you can run individual commands.
Each command gets its own widget in the UI, separate from the others, in its own tty, with no overlap.
The system saves each command you run, along with its start & stop times, the directory you were in, the result code when it finishes, and (this is the fun part) the command output, all in a sqlite database, on disk. (Disk is cheap, yeah? Might as well do something with it.)
This allows you to do some neat things with history and context.
* Keep the same tab open forever, maintaining months or years of context and history
* Pick up where you left off a month or a year ago
* Pick up where you left off after a system restart (like when you restart your browser and it reopens all your windows and tabs)
* Review everything you've done in a project directory
* Review everything you did yesterday, or a month ago
I hope in the future to make it easy to share history, which could help with new employee onboarding, teaching, asking or answering questions on StackOverflow, documenting a penetration test, or anywhere else you want to easily share your work or consume someone else's work.
Everything is in Go.
* The front-end uses Gio UI, a cross-platform GUI for Go
* The shell itself is https://github.com/mvdan/sh, a bash-like command interpreter
* The terminal emulator is a fork of Darktile (https://github.com/liamg/darktile) with very few changes.
This is not a SaaS. You download code and run the front- and back-end yourself, like ssh/sshd. (Except it doesn't run as root.)
This is a commercial product. Without a license, the app limits you to a single top-level window, with two shell tabs. (Similar to a single iTerm window with two tabs.) With a license, as many windows and tabs as you like.
I'm looking for any kind of feedback whatsoever, positive or negative, from the app itself, to the documentation and other online information, to this very post.
hucksh is currently available for macOS and Linux.
Learn more: https://huckridge.notion.site/Hucksh-overview-2fdcaf7d639145...
Download, etc: https://huckridge.notion.site/Hucksh-online-download-purchas...
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.
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.
> 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!
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/
I see this as capture of processes -- their invocation, context, and results -- in a relatively normalized form for analysis and re-use.
There are many possible applications based on analyzing these: automatically creating, porting, or refactoring code, showing that foreign code or ports are behaving as expected, providing audit trails, etc. Any environment where code is typically prototyped then hoisted into some kind of workflow container is a candidate.
No one likes to have this level of intrusion or monitoring, but everyone seems to accept running code in containers, so if this were built in to the container, it might be easily deployed and widely accepted.
To me the way to proceed could be to generate a bunch of pseudo-data and start prototyping use-cases based on analyzing the data (or monitoring the stream). The general themes would be in the realm of software evolution, to productize prototypes, refactor legacy bloatware to MVP, model the effect of selectively changing subsystems, etc. Sure, this might benefit the programmer, but it could also be of interest to managers or senior developers helping juniors level up their code. Once you have some valuable use-cases, you'll know more about your deployment targets and business model (OS-freemium?).
As for workflow comparables, the original MPW (Macintosh programmers workshop) used the text document for input, output, and commands in a kind of early notebook (perhaps following mathematica notebooks of the time). And Eclipse as an extensible IDE has a number of terminal window and command integrations with UI, following emacs. I could even see this as a python context manager in a notebook.
A more narrow goal based on the current implementation could be to build and maintain a library of bash functions or scripts, possibly shared by a team. Monitor and capture results, then let developer select a series of commands to wrap, with your tool providing help with capturing, documentation, generating precondition checks, browsable/html cross-linked docs, etc.
But generally I wouldn't try to recreate notebooks or IDE's for bash. My goal is always to migrate any bash that gets big to a language with types, error-handling, logging, etc.
That's a nice, neat, concise way of putting it. Thanks.
> There are many possible applications based on analyzing these ...
Those are some neat ideas. I'd certainly have to talk about them with some real users to understand the demand and use-case. I think the easy sharing I mentioned could go a long way to achieving that goal.
You can also already pretty easily extract just the commands run, to (as you put it) hoist it into a larger script or workflow. E.g. in my current instance, `hucksh sql "select command from command_history where id > 2863 order by id"` dumps out the most recent 10 commands you ran.
> No one likes to have this level of intrusion or monitoring, but everyone seems to accept running code in containers, so if this were built in to the container, it might be easily deployed and widely accepted.
Hmm, perhaps.
That does give me an idea for another use-case for hucksh in containers: mount the hucksh database file into a container, across invocations, to have a more seamless history of working in the container.
> A more narrow goal based on the current implementation could be to build and maintain a library of bash functions or scripts, possibly shared by a team.
Indeed. That's where I was going when I said "I hope in the future to make it easy to share history, which could help with new employee onboarding, [etc]."
> My goal is always to migrate any bash that gets big [...]
Yes, I agree.
Thanks again for your comment. Some neat stuff here.
I am a happy user of warp.dev They are enhancing the standard terminal experience with a lot of features- some of the same ones in hucksh (they just added showing the directory and other metadata of the command in the history search).
IMHO it's going to be hard to get developers to pay for a terminal when there are a lot of free options. Warp is trying to sell based on team collaboration features- often this is the right model although at the moment their team collaboration features doesn't seem to meet my needs.
Yeah, I've looked at warp.dev. Funny story: I heard about them from Daniel Martí, aka mvdan, the author of the shell library I'm using.
It looks really neat, though I confess I haven't explored it much; dogfooding, don't'cha know. :) I felt a little threatened by them but also weirdly encouraged, since they got $50M in funding. It made me think that hey, somebody thinks a new experimental shell/terminal is a viable commercial product; why not mine? Also, Warp is pretty expensive by comparison (for teams of 6 or more, anyway; granted it's free for 5 or less).
Yeah, getting people to switch will be difficult, especially since most terminals are pretty rock-solid as far as their actual ncurses emulation, and mine still has some rough edges. I'm hoping that I can at least get a few happy users and go from there.
Thanks again for the kind words!
I'm glad people are working on these although as you say yourself, commercial viability is tricky. I like the non-SaaSyness of this but then I'm still left with having to:
1. change my shell
2. change my terminal
3. but not on Windows
4. rely on a single person for bugfixes, security issues, features
5. pay $40/yr for the privilege
None of these things are individually an insurmountable hurdle but they add up to a pile of friction. In the words of sales theorist J. Winnfield, "Well we'd have to be talkin' about one charming motherfuckin' pig".
It works very well but IIRC there are some quirks but nothing that was game ending. It's still notion and not a website in the end.
There are so many free players in that space (e.g., https://news.ycombinator.com/item?id=31402095), $40/yr is probably a hard sell.
If I'm reading the resh page correctly, they search the history of the commands you've run, but don't store or allow searching of the command output, or do any of the other historical features hucksh offers.
Also, it appears that all such searching happens server-side; in hucksh it's all client-side. If you have a fast connection, that admittedly wouldn't matter much; where I live, I'm on cellular or satellite and sometimes the latency suuuucks.
Would you care to speculate on what price-point would work for you? Everywhere else I've posted (mostly Reddit) I've offered a discount code. I saw zero guidance about that in the "Show HN" rules or guidelines, and I didn't want to be banned, so I didn't mention it. But happy to offer one here if it's okay to offer.
I don't think hucksh (or any shell) could provide an automatic way to undo some series of arbitrary commands. If nothing else, "/bin/rm" is forever, generally speaking.
What it could do is let you select individual commands and then automatically combine them all into a single command that you can save or copy&paste to someone else. Right now, the UI shows the command ID, which is a database key, so you could do something similar yourself, something along the lines of
hucksh sql "select command
from command_history
where id in (101, 103, 105, 107, 109)
order by id"
Hope this helps. If I've misunderstood you in some way, let me know. Thanks for your comment, regardless. :)
Also, KDE Dolphin can run commands in the current folder.
You can get the history to last forever by appending history to a file.
It's as good and stable as I can make it at the moment, but I'm not going to pretend it's, you know, absolutely rock solid against anything you can throw at it, and I'd hate for it to crash out from under you in the middle of a competition.
On the plus side, of course, if it does you should be able to just restart it and be on your merry way; that's what I do. :) So maybe it'd be fine.
mvdan/sh | gio | darktile
Do you think showing an md5 hash would help, or is it just Dropbox itself?
Would (for example) dl.huck.sh be better? (I own huck.sh (and huckridge.com and several others) and have a site there, but don't have anything at dl.huck.sh.)
I actually kind of thought that Dropbox would be better than my own webserver, on the assumption that people would trust them more than me. I dunno.
A too-slick website here on HN is a strong deterrent for me.
Googling "security audit my code" finds several companies that offer such a service. My concern would be (aside from the admittedly non-trivial benefit of just having better code), would it make a difference to anybody that was on the fence about it? I suspect that the matrix of "potential customers" vs "what auditing service they'd trust" is large.
Thank you for the comment.
Considering it seems to be constituted significantly of open source libraries and tools (which you commendably are up front about), I would want to see a lot more justification for why this is closed (e.g. those third party elements are only a tiny fraction of the product), and what significant value is being added. Or if I'm wrong, a clearer link to the repo.
> I would want to see a lot more justification for why this is closed
I'm not sure what justification I can offer besides "because I want to try to make a living selling my own software, starting with this product, and I think that'll be easier if it's closed source".
We might certainly differ over price points or value added. Pricing is a bit of a black art and this is my first commercial software product. (As I mentioned in another comment, I'm happy to offer a discount code, if that would help and not get me banned.) Like, would you be happier if it were 1, 5, 20 dollars? Or does the price, as such, even bear on the open-vs-closed question?
I'm unclear on how you (or I) would correlate "added value" or "private lines of code" vs. "justification for being closed source".
Thank you for your comment, this is an interesting discussion.
Edit: My apologies. I was mistaken. Carry on :)
You just found the difference between Open Source (MIT/BSD and friends) and Free Software (GPL without copyright assignment.).
It ain't about money ;)