[HN Gopher] Show HN: Hucksh - A shell with a very good memory
___________________________________________________________________
Show HN: Hucksh - A shell with a very good memory
In the deep mists of time (circa 2012), I was playing with the Go
standard library, and saw how easy it was to stand up a webserver
that let you navigate a remote file system, and I thought it was
pretty neat. 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...
Author : LarryClapp
Score : 71 points
Date : 2023-12-21 13:53 UTC (9 hours ago)
| anon25783 wrote:
| So you have a commercial product under a proprietary license,
| which forks a BSD-3-clause shell and an MIT-licensed terminal
| emulator? I don't think you can do that.
|
| Edit: My apologies. I was mistaken. Carry on :)
| LarryClapp wrote:
| I don't follow. Both the BSD 3-clause license and the MIT
| license allow commercial use. Granted, I might need to double
| check that I credit them & reproduce their licenses
| appropriately.
| knewter wrote:
| Yeah it seems like this guy explicitly doesn't understand the
| licenses but will go tell people things they cannot do under
| the licenses anyway. Weird.
| jampekka wrote:
| anon25783 seems to be even using BSD for their own
| projects. Even weirder.
|
| Maybe the constant GPL bashing going on is making people
| misunderstand the crucial difference between "permissive"
| and free software licenses?
| anon25783 wrote:
| It must be, because I misunderstood that difference
| myself. I've edited my original comment to reflect this.
| jampekka wrote:
| Very stand-up of you, kudos!
| LarryClapp wrote:
| Thanks!
| jampekka wrote:
| Isn't this possibility to strip users of the freedoms in
| derived works exactly what is touted as the "permissiveness" of
| these licenses?
| ilc wrote:
| Indeed.
|
| You just found the difference between Open Source (MIT/BSD
| and friends) and Free Software (GPL without copyright
| assignment.).
|
| It ain't about money ;)
| gregwebs wrote:
| Great project!
|
| 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.
| LarryClapp wrote:
| Thanks!
|
| Yeah, I've looked at warp.dev. Funny story: I heard about them
| from Daniel Marti, 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!
| pvg wrote:
| _somebody thinks a new experimental shell /terminal is a
| viable commercial product; why not mine?_
|
| 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".
| gabrielsroka wrote:
| Say "what" again! I dare you! I double dare you!!
| LarryClapp wrote:
| All of that is fair and I appreciate the comment. Hmm.
|
| #1 - I could fork an instance of bash for every command
| instead of using an internal interpreter. I've shied away
| from that because it adds an extra layer of complexity, and
| also on the theory that if you're trying something that
| hucksh can't run by itself, then you should probably write
| a stand-alone script anyway. But perhaps as an option it'd
| help ease the transition or make people more willing to try
| it.
|
| #3 - A Windows version is possible. Hucksh has worked there
| in the past. I think my hurdle there is a build error on
| Windows in one of the libraries I use. It's probably one of
| those things that when I actually look closely at it, it'll
| take an hour to fix, but so far I haven't. More fool I,
| perhaps.
|
| I also shy away from Windows a tiny bit because it's not my
| primary platform (macOS), or even my secondary platform
| (Linux), and the Windows file system structure (with drive
| letters and so on) requires different code.
|
| On the other hand, a Windows client talking to a Linux
| server would cover a big use-case.
|
| #4 - If enough people buy it, I could hire other people! ;)
| I realize that doesn't make it any easier to be an early
| adopter.
|
| #5 - Would you care to speculate on what you think is a
| fair price?
|
| Also, based on your other comment, I've added a discount
| code for 90% off (HN-1223).
| pvg wrote:
| I don't think there's anything 'unfair' about your price,
| it's just something I don't want to have to think about
| yearly for a shell/terminal. One possible workaround is
| longer term licenses (especially promotionally to early
| adopters) or a different paid upgrade cadence.
|
| I think the fundamental problem to me is similar to that
| expressed by some of the other commenters - a vague sense
| of unease with using a closed source shell/terminal
| combo. That's much harder to overcome than paying for a
| shell/terminal combo. Of course, getting reasonably
| compensated for open source work is an even trickier
| problem.
| artisin wrote:
| Here's my 2c. It's unlikely that many users, here or elsewhere,
| would be comfortable downloading and executing this Hacksh binary
| from your Dropbox, regardless of its benefits.
| LarryClapp wrote:
| Thanks, that's good to know. I never thought of that as a
| stumbling block. _I_ trust me!
|
| 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.
| wolftickets wrote:
| If you happen to have a GitHub space for storing things you
| can upload release artifacts there for folks to download.
| tutfbhuf wrote:
| Preferably, these release artifacts are generated by a
| pipeline, and the hashes are verifiable.
| jrm4 wrote:
| Offhand, I _love_ this as an anti-signal and I 'll probably
| try it out because of this.
|
| A too-slick website here on HN is a strong deterrent for me.
| LarryClapp wrote:
| Ha, fascinating. (And thanks for trying it out!)
|
| So would a tarball on Github put you off, do you think?
| Would you prefer a raw directory listing from Apache at
| dl.huck.sh (et al)?
| artisin wrote:
| Personally, my primary concern is security and, by extension,
| trust. My shell environment functions as the gatekeeper to my
| castle, and installing this binary would be akin to blindly
| handing over the keys, especially since the source code is
| not accessible. I'm unsure if it's feasible given Hacksh's
| requirements, but using Flatpak could largely address your
| distribution issue as well as my security issue.
| chromakode wrote:
| Agreed. I would not consider running a closed source shell
| because it's not auditable.
| burglekutt wrote:
| 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.
| LarryClapp wrote:
| 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 wrote:
| 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 wrote:
| 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!
| snapplebobapple wrote:
| 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 wrote:
| You're missing the 'and their output.'
| yjftsjthsd-h wrote:
| > 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.
| wavemode wrote:
| I highly recommend buying a domain and putting together a
| professional-looking website, if you intend to sell this
| software.
| LarryClapp wrote:
| Thanks, that's valuable feedback. I do have huckridge.com (a
| Wordpress site), and some others like huck.sh (which mirrors
| huckridge.com), but I've been using Notion and Dropbox so as to
| focus on my product and outsource stuff that wasn't in my core
| competency, if that's the right word.
| swozey wrote:
| You can put a domain in front of a notion workspace. You can
| either pay something like https://super.so (I've used them)
| or a few others, also there's a way to front it with your own
| proxy and maybe a cloudflare method but I forget. I set it up
| a year ago for my go wiki but I can't even remember the url
| to show you right now..
|
| 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.
| thisismyaccoun7 wrote:
| Seems like resh (https://github.com/curusarn/resh) plus a
| directory tab and unlike resh it isn't free. I like the directory
| history, but that isn't a $40/yr value add over resh for me.
|
| 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.
| LarryClapp wrote:
| Thanks, I wasn't aware of resh. (They don't call it "re.sh"?)
|
| 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.
| pvg wrote:
| You can offer a discount if you want, it's well within the
| rules.
| ilc wrote:
| Neat tool. Thanks for pointing it out.
| beeburrt wrote:
| Clickable links:
|
| https://huckridge.notion.site/Hucksh-overview-2fdcaf7d639145...
|
| https://huckridge.notion.site/Hucksh-online-download-purchas...
| LarryClapp wrote:
| Thanks, that's weird. The ones in the post are clickable on my
| end.
| mellosouls wrote:
| I couldn't immediately find the repo for this, and get the
| impression its not open source.
|
| 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.
| lucideer wrote:
| EULA https://huckridge.notion.site/Hucksh-
| EULA-5f69019f12a04487a9...
| seanhunter wrote:
| I see the section on "Fees". It is certainly a ballsy move to
| try to charge fees for a shell in 2023 when shells have been
| free for like about 50 years at this point. This was a "no"
| from me just based on the description of the web based point
| and click yadda yadda but it's a "hell no" from me baed on
| reading that EULA.
| jyxent wrote:
| The licenses for the three libraries / software they mention
| are MIT or BSD. They don't need to make it open source.
| LarryClapp wrote:
| Correct, it's not open source. I did mention that it's a
| commercial product, but of course some commercial products are
| also OSS. Mine is not.
|
| > 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.
| LarryClapp wrote:
| Use code HN-1223 at checkout for 90% off ($40 -> $4) a license
| key through the end of the year. (... Which is a lot closer than
| it used to be, sigh. Time marches on.)
| pjf wrote:
| Small world : - ) Great work, Larry!
| LarryClapp wrote:
| :laugh: Indeed! Thanks!
| w10-1 wrote:
| I think you're on to something, but tangled in the
| implementation.
|
| 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.
| LarryClapp wrote:
| > I see this as capture of processes -- their invocation,
| context, and results -- in a relatively normalized form for
| analysis and re-use.
|
| 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.
| tesdinger wrote:
| Reusing the outputs isn't universally possible because commands
| typed into bash generally aren't pure functions. You might have
| to run them again to get the current correct output. It's an
| interesting feature though.
|
| Also, KDE Dolphin can run commands in the current folder.
|
| You can get the history to last forever by appending history to a
| file.
| millzlane wrote:
| This will come in handy in CTF competitions and studies. I often
| find it difficult to keep track of my work.
| samstave wrote:
| This might sound strange, but one of the things I shave always
| wanted are what I would call "routes" --> A journey one goes down
| to either connect to something through some circuitous method, so
| to save that. Or to attempt to install or implement something
| that keeps package-creeping on you, so you could just have
| massive undo route. Or to be able to send someone a route that
| they can just watch, read or playback on their system. (obviously
| you'd need validation, auth, logging, etc- but savable, sharable
| cli route would be pretty dope, unless something like this exists
| and im an idiot.... (this is different than orchestration, it
| should be a native capability of the shell)
___________________________________________________________________
(page generated 2023-12-21 23:00 UTC)