Whine: would be cool if stuff could have names that are descriptive of what they do, rather than have an entire aesthetic. pick is great, cuz it’s about picking stuff!
But this looks very nice. It feels like it really balances nice aesthetic results with not being filled with emoji everywhere. I’m going to see if I can integrate this into my workflows
It feels like it really balances nice aesthetic results with not being filled with emoji everywhere.
I second that! I was afraid that, inline with the recent trend of “emojification” that I’ve seen in many tools, this would have been full of those, but it seems I was wrong.
The only complaint I have about the aesthetic is that it’s a bit too padded… I don’t know how it will integrate visually with outputs of other tools and echo’s when integrated into scripts.
Hm cool, is there any way for such scripts to work in the browser?
Something I’ve always wanted is to unify web and CLI programs somehow, i.e. write a quick script and have it work in both places. The examples strongly remind me of HTML forms and checkboxes.
I guess that is more of a terminal thing, but there are some terminals with rich text, images, etc.
You could just use one of the Javascript based terminal packages like Hyper.js but ultimately it’s not clear to me what you’re trying to achieve here :)
The question is, once a shell script has this UX, can we find some glue to just stitch it into a web page? In the CGI model allow someone to load a shell script and walk through it? Once the interactivity looks like this…. why not? It would allow shell devs to easily let other people do the same things CLI people do easily
CGI scripts don’t expose ptys to end users, they take web requests as input and generate HTML and other content as output. They don’t magically enable interactive shell programs through your browser.
I mean generic HTTP request/response with dynamic sites generated outside the web server. So a web server knows “when hit with this endpoint, run this script and connect the pipes.”
Don’t really have an example off the top of my head. And it would need a wrapper to have live-enough interactivity…
I’ve been playing with Dear ImGui with a view to doing this. It has a load of different back ends, most of which pass the output to the GPU to render, but there are two other interesting ones (from the same person):
imgui-ws sends the compressed display lists over a web socket for rendering via WebGL in a browser.
Annoyingly, both of them depend on slightly (differently) modified forks of Dear ImGui, so you can’t easily build a program that dynamically switches between them. I’m hoping that the hooks that they both need will eventually be upstreamed so that I can write things that render in my local GUI, my terminal, or on the web using the same Dear ImGui interfaces.
Hm didn’t know about those libraries, looks pretty cool!
I also wonder if you can just run the whole UI in WASM, without a C++ server sending websocket data ? The funny thing is that WASM doesn’t really work well with the DOM, but maybe it would work better with terminal-based communication to JS and a virtual JS terminal. Or is that slower than WebGL?
I think there are two directions you can approach it from:
start with web -> fit in terminal
start with terminal -> fit in web
ImTui would be the latter, but I kind like proportional fonts, hyperlinks, and I think screen readers for accessibility are an issue.
So there is some value to the first for sure … But yeah it’s hard to do that without changing the terminal. And the problem is that most people use whatever terminal comes with their OS. You would need some kind of graceful degradation, and then that introduces all sorts of complexity.
I also wonder if you can just run the whole UI in WASM, without a C++ server sending websocket data ? The funny thing is that WASM doesn’t really work well with the DOM, but maybe it would work better with terminal-based communication to JS and a virtual JS terminal. Or is that slower than WebGL?
I think you could compile the C++ bit to WASM and replace the WebSocket interface to the front end with something simple. My interest in this is for control-plane tools. I’ve been playing with these things to try to see if I can build a nicer replacement for things like systat using a thin C++ wrapper around a mostly Lua codebase (using Sol2 for bridging). I’d like to be able to run a terminal application via ssh, a graphical application locally, or a web app either locally or remotely, so that I can connect to a remote machine and run graphical administration tools.
ImTui would be the latter, but I kind like proportional fonts, hyperlinks, and I think screen readers for accessibility are an issue.
You get proportional fonts with any of the other Dear ImGui back ends. Screen readers are not yet supported, but there are folks working on that. If they work with the display lists from Dear ImGui then it should also be possible to make console applications accessible, which would be fantastic.
So there is some value to the first for sure … But yeah it’s hard to do that without changing the terminal. And the problem is that most people use whatever terminal comes with their OS. You would need some kind of graceful degradation, and then that introduces all sorts of complexity.
That’s why I like the imgui-ws approach: you can jump straight into graphical mode by just having the terminal application give you a hyperlink that you click on and see the UI in your browser, or you can use ImTui to run it directly in the terminal.
Neat. I was expecting a go library. I know they have a couple of other standalone thing built off of other libs they’ve made.
I wonder what happens if every keyword of a shell is replaced. Do we end up in agnostic land or dependency hell? Bash scripts themselves are barely portable:
So, I use gum … but no one else does? Dependencies.
We replace every keyword of a shell and every binary with a modern replacement (choose, exa, duf). It’s still a list of dependents but I have a nicer UX.
I guess you could ship a docker image with what you need. And you could just use bubbles and lip gloss and then have a binary CLI that stands on its own. 💭
I personally think this is the way. Nix, Guix and similar tools offer a way to declare dependencies for shell scripts in a backwards-compatible way.
On a nix-enabled system, a nix-shell shebang uses dependencies (and optionally an interpreter) declared in the second line to re-execute the script. Its a noop on non-nix systems
In an ideal world, we could use a shared mapping from nixpkgs -> guix -> debian -> rhel like repology.org has, to translate those headers into apt and yum. This would have an extremely long tail of obscure errors, but could work out of the box in common, simple cases and provide a base to build upon in others.
Hot.
Yeah, this is a huge step up from
dialogand its friends likewhiptail.This feels like Rich but for shell scripts rather than Python :)
Whine: would be cool if stuff could have names that are descriptive of what they do, rather than have an entire aesthetic.
pickis great, cuz it’s about picking stuff!But this looks very nice. It feels like it really balances nice aesthetic results with not being filled with emoji everywhere. I’m going to see if I can integrate this into my workflows
I second that! I was afraid that, inline with the recent trend of “emojification” that I’ve seen in many tools, this would have been full of those, but it seems I was wrong.
The only complaint I have about the aesthetic is that it’s a bit too padded… I don’t know how it will integrate visually with outputs of other tools and
echo’s when integrated into scripts.Hm cool, is there any way for such scripts to work in the browser?
Something I’ve always wanted is to unify web and CLI programs somehow, i.e. write a quick script and have it work in both places. The examples strongly remind me of HTML forms and checkboxes.
I guess that is more of a terminal thing, but there are some terminals with rich text, images, etc.
For Python, Wooey should be something of interest : CLI exposed on the Web. Gooey transform CLI to Desktop GUI app also.
You could just use one of the Javascript based terminal packages like Hyper.js but ultimately it’s not clear to me what you’re trying to achieve here :)
The question is, once a shell script has this UX, can we find some glue to just stitch it into a web page? In the CGI model allow someone to load a shell script and walk through it? Once the interactivity looks like this…. why not? It would allow shell devs to easily let other people do the same things CLI people do easily
Respectfully, I’m not sure this makes sense.
CGI scripts don’t expose ptys to end users, they take web requests as input and generate HTML and other content as output. They don’t magically enable interactive shell programs through your browser.
CGI model, not the same tech.
Thanks I guess I’m only aware of the traditional CGI script.
Can you point me to an example of the kind of thing you’re thinking about?
If I got the thread right, an exemple wood be Vue.js (https://vuejs.org/).
Or React.
That’s what I’m struggling with.
I can’t find any reference anywhere for React or Vue fitting in with a “CGI model”.
I’m just not understanding where folks are going with this idea - UNLESS you mean the generic HTTP request/response cycle?
I mean generic HTTP request/response with dynamic sites generated outside the web server. So a web server knows “when hit with this endpoint, run this script and connect the pipes.”
Don’t really have an example off the top of my head. And it would need a wrapper to have live-enough interactivity…
I’ve been playing with Dear ImGui with a view to doing this. It has a load of different back ends, most of which pass the output to the GPU to render, but there are two other interesting ones (from the same person):
Annoyingly, both of them depend on slightly (differently) modified forks of Dear ImGui, so you can’t easily build a program that dynamically switches between them. I’m hoping that the hooks that they both need will eventually be upstreamed so that I can write things that render in my local GUI, my terminal, or on the web using the same Dear ImGui interfaces.
Hm didn’t know about those libraries, looks pretty cool!
I also wonder if you can just run the whole UI in WASM, without a C++ server sending websocket data ? The funny thing is that WASM doesn’t really work well with the DOM, but maybe it would work better with terminal-based communication to JS and a virtual JS terminal. Or is that slower than WebGL?
I think there are two directions you can approach it from:
ImTui would be the latter, but I kind like proportional fonts, hyperlinks, and I think screen readers for accessibility are an issue.
So there is some value to the first for sure … But yeah it’s hard to do that without changing the terminal. And the problem is that most people use whatever terminal comes with their OS. You would need some kind of graceful degradation, and then that introduces all sorts of complexity.
I think you could compile the C++ bit to WASM and replace the WebSocket interface to the front end with something simple. My interest in this is for control-plane tools. I’ve been playing with these things to try to see if I can build a nicer replacement for things like
systatusing a thin C++ wrapper around a mostly Lua codebase (using Sol2 for bridging). I’d like to be able to run a terminal application via ssh, a graphical application locally, or a web app either locally or remotely, so that I can connect to a remote machine and run graphical administration tools.You get proportional fonts with any of the other Dear ImGui back ends. Screen readers are not yet supported, but there are folks working on that. If they work with the display lists from Dear ImGui then it should also be possible to make console applications accessible, which would be fantastic.
That’s why I like the imgui-ws approach: you can jump straight into graphical mode by just having the terminal application give you a hyperlink that you click on and see the UI in your browser, or you can use ImTui to run it directly in the terminal.
Neat. I was expecting a go library. I know they have a couple of other standalone thing built off of other libs they’ve made.
I wonder what happens if every keyword of a shell is replaced. Do we end up in agnostic land or dependency hell? Bash scripts themselves are barely portable:
gum… but no one else does? Dependencies.choose,exa,duf). It’s still a list of dependents but I have a nicer UX.I guess you could ship a docker image with what you need. And you could just use
bubblesandlip glossand then have a binary CLI that stands on its own. 💭Or a script with a nix-shell shebang
I personally think this is the way. Nix, Guix and similar tools offer a way to declare dependencies for shell scripts in a backwards-compatible way. On a nix-enabled system, a nix-shell shebang uses dependencies (and optionally an interpreter) declared in the second line to re-execute the script. Its a noop on non-nix systems
In an ideal world, we could use a shared mapping from nixpkgs -> guix -> debian -> rhel like repology.org has, to translate those headers into apt and yum. This would have an extremely long tail of obscure errors, but could work out of the box in common, simple cases and provide a base to build upon in others.
Looks pretty. 4+ MiB seems excessive as the baseline for a pretty shell script though.