Sounds like a similar family of problems to [Wish](https://github.com/charmbracelet/wish) by charm.sh. They've been pushing this curious paradigm of "ssh apps", where ssh keys are used to automatically create identities for small self-hosted CLI/TUI apps.
As a useful comment for messh, it looks like you've committed the ssh_server binary file to git; you may want to add that to gitignore, as binary file handling isn't a traditional git strength. I _think_ it's better than it was a decade ago when I last investigated this, but I can see that Pro Git still recommends explicitly setting gitattributes to mark a file as binary https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
Looking at their demos immediately brought back the memories of parsing TUI's using ad-hoc "expect" rules.
I honestly don't get the point of TUIs...
A real command-line interface is extremely useful - it's trivially scriptable, works direct or with ssh, scroll-back buffer logs what happened, commands stay in my shell history, I can copy-paste commands to a friend over chat system, or into shell script, and it's easy for app authors too. Its my first choice for my apps.
If low-color fixed-width character grid is not cutting it, then native app or web app is a great second step, or even intermediate solutions, like generating HTML files from CLI tool and opening them in default browser. You have to invest some effort, but you have infinite ways to design your interface, and it's still in user's familiar environment.
But those charm.sh TUI applications seem utterly useless and highly annoying. They give up all of the terminal advantages: my shell's history is useless, my favorite ways to edit commands does not apply (as they have their own editor), I cannot scroll back and see what the program just printed, I cannot script it, I cannot log it, I cannot search it, I cannot redo the previous action, the color scheme is not the one I've picked... At least with web apps I can parse html and/or hit underlying API directly - no such luck with TUI apps.
At least the good news is that TUI apps are not getting any traction, and I can completely understand why.
* lf (file manager)
* vim
* htop
* moc and ncmpcpp (music)
* emacs (which is its own world)
TUI apps are great for one-time actions that needs feedback, especially having a list of something, filtering it, and applying an action on one or more items.
But, I still like to have a CLI version so I can script any reccuring workflow.
I totally agree with you, I prefer good autocomplete to a TUI for all these reasons (and more). Well, I actually prefer any CLI to a TUI. The most TUI thing I use in my toolkit is `top` (yes, the "classic" one)
There are one or two advantages over regular GUIs, but that's it.
The biggest is probably that they are lightweight since there are no GUI library dependencies (and if there are TUI ones, they are usually much lighter than their GUI sisters). This also means there are fewer (if any) dependencies to distribute compared to a GUI.
The only other advantage I can come up with is that a TUI will have to be usable by keyboard only (in almost all cases). This is not a given for regular GUI libraries.
I'm not a fan of TUIs either. I think the only one I am using regularly is `tig` (https://jonas.github.io/tig/). I guess the reason is that I don't have to remember the git revision list syntax that way and that `tig` allows for easy commit searching with `/` ...
Another interesting set of ssh apps is https://pico.sh/ . These focus on networking and lightweight hosting (pastes, simple blog), all via ssh or rsync.
Regarding ssh-apps, this seems super duper niche to me even for developers. Like, I get that many devs are terminal savvy, and it's cool that it's possible to serve apps like this but is it practical (to pick for your new product /internal app)?
As a bare metal cloud service provider, we built a little TUI app over ssh so that people could upload their public keys to us without having to use a web interface. It has worked out really well because it makes it possible to "upload" the public key without having to do anything but login.
We automatically configure ssh on the servers to auth against our own internal api for serving up the keys. This way, customers can add to authorized_keys and also use our TUI for management as well.
It's meant for inherently server-based CLI's like Github, Stripe, Fly, Heroku, or any other SaaS and can be plugged directly into web frameworks. My thinking is that more companies would ship command-line interfaces if they didn't have to maintain APIs for them, deal with distributing binaries (and all the compatibility issues that come with that), or deal with all the configuration involved in hooking up SSH to their app servers.
It's in beta at the moment, and I'm currently focused on Rails apps to get the ergonomics dialed-in. My goal is to make it possible for people in any web framework to build and ship a CLI to customers in under an hour and never have to touch an API or worry about binary distribution for as long as their CLI exists.
At my org the biggest issue with out CLI is not the initial distribution, but supporting and maintaining multiple platforms, code signing the binaries, and making sure customers actually update the binaries.
Yeah, I put all of that under the umbrella of “distribution”—the last mile is a huge pain in the SaaS that SaaS CLIs shouldn’t have to deal with or even think about.
Terminalwire will handle the builds for all the different platforms, signing, etc. so companies can instead focus on shipping their unique features to customers.
I’m also going to ship clients that automatically update to match the version of the client that’s compatible with the server in a way that the client won’t even notice.
At the large enterprises I've worked at, signing with our certs had to happen on our own build machines. And I don't think there was any precedent if we could sign third party binaries that had been built for us.
Having some my-company.terminalwire.com as the signing identity could work; I bet most SMB wouldn't bat an eye to ship like that.
As a developer, I agree. Give me a great CLI, please, not a server rendered TUI.
This gives me another thought though, a "server-rendered" CLI. A tiny shim binary that just sends argv to the server, and the server sends back stdout/stderr. Haven't seen anyone try that.
Yeah, in retrospect, I'm an idiot. I wasn't considering `ssh foobar.io dothething` to be equivalent to what I was thinking in my head even though it is exactly equivalent.
`Wish` and also `terminal.shop` were both great sources of inspiration. I hope to see many more ssh apps in the future. I'm already working on the next one
> CR by itself is occasionally useful for when you want to overwrite a line of text you have just written. LF, on the other hand, is completely useless. Nobody ever wants to be in the middle of a line, then move down to the next line and continue writing in the next column from where you left off. No real-world program ever wants to do that.
I realise this isn't core to the author's point, and I mean the question to learn something rather than trying to be a pedant. I think it uses python byte offset semantics rather than CR, but for all I know the python implementation uses CR under the hood.
The article overall is a fun read! I love the idea of trying to identify simple pieces of legacy ideas and clear them out.
You sound much more experienced as a web developer than me, so you probably know this exists, but just trying to be helpful I want to be sure you know about client side form validation in html5 https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va...
I appreciate this doesn't cover anything more than the basics, so something like the normal behaviour of comparing two password fields for the same content doesn't work, but I find these controls are useful for getting something simple up and running.
Following up again, today I tried adding a primary key to a table in sqlite and didn't figure it out. I revisited the sqlite docs and found https://sqlite.org/faq.html#q11, showing that the alter statement is restricted to add, rename and drop.
It _does_ seem like you can add a primary key later in mysql and postgres, but I don't see any way to accomplish that in sqlite.
Oh that's very interesting. I am actually using a UI called "DB Browser for SQLite" and checking its logs shows that when I add a PK, it actually creates a new temporary table, copies over all data from the old table, deletes the old table, and then renames the new table.
So you were correct originally, it can't just add a PK.
I would have swore I read in the docs that you cannot add one after creating a table, but I cannot find a reference for that. Sounds like I made a mistake! Thanks for catching it!
I'm really sorry as this may sound condescending. It isn't meant like that.
I'm just old.
As in, when I started my career I worked on an application that was written 15 years earlier. It taught me a lot.
As in around 1990. Guess what? It used database triggers to keep a record of every change ever made to any table in an "archive" table. When I joined the project I was able to see every single change any user made ever since the application was built.
And yes you very probably bought a product that was planned and administered through that application.
So to try and save this post: go learn and explore! I do implore you to try and look around and away from specifics like the technology you are using being SQLite. Look beyond. Look at the concepts. Figure out that things repeat in history. Every generation re-invents some wheels. Recognize them and try to recognize if there are slight differences and improvements in the re-inventions or if it's just more layers upon layers. Or in this case is it just that SQLite is gaining/having more and more features of "real databases" even though it's mostly touted as an "embedded database"?
Learning and exploring is what I was sharing in this blog post! I’ve thought of tinkering with sqlite for the last ten years, and I finally did and shared it with you all :)
I want to start by saying the author's right about wanting clarity in documentation and actually having documentation that's easy to navigate. golang, for example, has pretty good documentation, but whenever I visit the official docs I find it difficult to find my way to the information I'm looking for.
Having said that, it's worth asking if some of these asks are orthogonal to each other. For example:
>That page must contain (not link to) every method, and the descriptions of those methods, that can be called by that class, preferably including all inherited functions.
>That page must be as uncluttered as possible
"Including all inherited functions" is a pretty deep stack pretty quickly in a lot of languages. I'm entirely willing to acknowledge that maybe that means the page being "as uncluttered as possible" is to be read in the same vein as "the design should be as simple as possible, _and no simpler_".
>Seriously, cppreference straight up taking you to duckduckgo when using the search box is fucked.
In this case, we're seeing the tension between "The official docs should be great" and "I've mistaken a community project for the official docs" (cf. https://en.cppreference.com/w/Cppreference:FAQ the question "Who is behind this site?")
This sort of conversation naturally invites the more subtle conversations around who funds/maintains open/libre projects and whether those in the community who aren't actively working to improve the situation should follow ESR's wonderful advice, "Every good work of software starts by scratching a developer's personal itch."
> In this case, we're seeing the tension between "The official docs should be great" and "I've mistaken a community project for the official docs"
What official documentation? The standards? C and C++ are weird languages from a modern perspective, and that includes their cultures: They don't have a single blessed implementation, they have a standards body and a community. The standards body issues standards, the community does everything else. Both C and C++ come from a time when all "serious" languages worked like that. Yes, even BASIC. There's an ANSI standard for BASIC.
It would be great if the FSF and/or the LLVM people wrote documentation for C and C++ and it would be even better if they collaborated on it. But it would be no more "official" than cppreference is, because they don't write the standards.
I intend to sound like I'm agreeing with you here, not disagreeing.
The standard is what the committee publishes, yeah. For C++ it's https://www.iso.org/standard/79358.html ; I didn't look up the corresponding C one, but I have a friend (hi, Kate!) who maintains a C compiler who's pretty comfortable with the latest standard. The standard is the official documentation.
There's drawbacks having whitepaper standards that cost money, but this is what those languages have.
For what it's worth, it used to bug me that part of the standard is that there's intentionally undefined behaviour, but I went to BoostCon and heard some of the standard body talk and they impressed me as being thoughtful about leaving areas for implementers to innovate specific optimisations, so as not to restrict the potential of the community.
If I'm reading you right we agree that there's a difference between the standard and the implementation that's practical and real, but I'm not certain there's much to be done about that.
The C and C++ draft standards are publicly and freely available, and are generally better quality than the actual ISO standards. You can get the C standard here https://www9.open-std.org/JTC1/SC22/WG14/www/projects.html, and the C++ standard is also available in HTML form at https://eel.is/c++draft/ (having hyperlinks to individual sections is actually quite useful).
I miss the reward after the suffering of working through these problems with dense documentation, even as I enjoy the benefit of chatGPT getting me rapidly closer to my destination. The days of RTFM were good days; the days of solving problems quickly are good days, but different and not nostalgic for me.
As a useful comment for messh, it looks like you've committed the ssh_server binary file to git; you may want to add that to gitignore, as binary file handling isn't a traditional git strength. I _think_ it's better than it was a decade ago when I last investigated this, but I can see that Pro Git still recommends explicitly setting gitattributes to mark a file as binary https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...