Hacker News Reader

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.

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!

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/

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!

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/

You're missing the 'and their output.'

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

Clickable links:

https://huckridge.notion.site/Hucksh-overview-2fdcaf7d639145...

https://huckridge.notion.site/Hucksh-online-download-purchas...

Thanks, that's weird. The ones in the post are clickable on my end.

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.

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

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.

Thanks!

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!

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

Say "what" again! I dare you! I double dare you!!

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

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.

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

I actually see them compounding... either one alone isn't great, but combine them and you're left with a tool that can be rug-pulled out from under you at any time for any reason. OSS with some monetization gives you a fallback of maintaining it yourself, while commercial non-OSS with a perpetual license at least means you can keep using an old version as long as you can manage. Commercial subscription software is at best ephemeral, and not something I'd invest (time, money, transition effort, etc...) in without a strong fallback option, and even then the benefit offered has to be pretty impressive to overcome those switching costs.

> commercial non-OSS with a perpetual license at least means you can keep using an old version as long as you can manage

That's what hucksh has. Today's license will work with today's code (and code released in the next year) forever. Sorry if that was unclear.

Oh, ok, that's at least more reasonable. Thanks for clarifying. (and for using such a license)

Not really unclear, now that I look closer, I just saw the annual rate and hadn't actually clicked through to the license/pricing details and assumed that to mean a typical SaaS subscription model. (it's cool and all, but not a fit for me based on the direction you're going.)

UNC paths are pretty universally supported on modern windows and make things more similar to other platforms. (essentially there are symlinks that make the drive letter look like just an element of the larger path)

Wait, is it a perpetual license with 1 year of upgrades or is it a license that expires after a year? The latter would make this a no-go for me even if I really like everything else that I'm seeing.

It's the former. A license today will work with today's code forever.

I am not a fan of subscription software, and as much as I would love a recurring income, I don't want to inflict that on my users, if I can avoid it. At the same time, I think it's fair to try to have some way to fund ongoing improvements. It's a delicate balancing act.

Thanks, I've bought a license now.

Another question: Is there a publicly accessible changelog anywhere? All I see is a Discord link and a newsletter, neither of which I'm interested in using just to see what's changed in a new version. This is the kind of thing that should have its own page on your Notion and be available as a separate text file in the downloaded zip/tgz.

> Thanks, I've bought a license now.

Thanks, that's awesome!

> Is there a publicly accessible changelog anywhere?

Not at present. I'll definitely do one for future releases. I added a reminder in my Makefile, too :) . Thanks for pointing that out.

I highly recommend buying a domain and putting together a professional-looking website, if you intend to sell this software.

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.

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.

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

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.

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.

You can offer a discount if you want, it's well within the rules.

Neat tool. Thanks for pointing it out.

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)

I've read your comment a couple of times, and I think (maybe) I finally understand it.

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"

where the "101, 103, 105, ..." are the IDs of the commands you entered and want to reify into a single "one-liner". Noting them and entering them by hand would be a drag, but it'd work.

Hope this helps. If I've misunderstood you in some way, let me know. Thanks for your comment, regardless. :)

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.

This will come in handy in CTF competitions and studies. I often find it difficult to keep track of my work.

Please give the trial version a shot before using it (literally? :) in anger.

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.

Small world : - ) Great work, Larry!

:laugh: Indeed! Thanks!

This is a compilation of other people's work, but not a business. No one is going to pay for it. Because honesty is more useful and kinder than false praise, sorry and good luck.

It's really not. But if it were, that seems strangely apropos for something calling itself a shell.

  mvdan/sh | gio | darktile

:)

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.

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.

If you happen to have a GitHub space for storing things you can upload release artifacts there for folks to download.

Preferably, these release artifacts are generated by a pipeline, and the hashes are verifiable.

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.

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)?

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.

Agreed. I would not consider running a closed source shell because it's not auditable.

Yeah, I've worried about this a lot. Perhaps there's someone I could hire to give hucksh a clean bill of health. I wonder how much Bruce Schneier would charge? :) (That's a joke; I'm confident that, even if he'd do it, I couldn't afford him. But something like that is what I'm thinking of.)

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.

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.

EULA https://huckridge.notion.site/Hucksh-EULA-5f69019f12a04487a9...

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.

The licenses for the three libraries / software they mention are MIT or BSD. They don't need to make it open source.

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.

I'm not the previous poster and I don't think you need to "justify" anything, but the main reason I'd like the source code is so I can fix my own problems and don't need to rely on you. I care a lot less whether that's under an open source license or NDA or whatever: as long as I can build it and include any changes I want.

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 :)

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.

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.

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?

It must be, because I misunderstood that difference myself. I've edited my original comment to reflect this.

Very stand-up of you, kudos!

Thanks!

Isn't this possibility to strip users of the freedoms in derived works exactly what is touted as the "permissiveness" of these licenses?

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 ;)

Show HN: Hucksh – A shell with a very good memory