There was a post a while back with the inflammatory title “GUIs are Antisocial” and the thrust of it was that work at the CLI produces artifacts that can be shared. I spent some hours trying to make sense of some weird directory full of json with jq and when I figured out one file it was trivial to turn it into a script that handled everything.
So there’s a conflict. jq is indispensable. I work with it and I’m happy to put the resulting command in a script. rg is awesome. I put it in scripts that I’ll run myself. fd looks like something I’d love. My command line work loses that quality of producing a shareable artifact. I don’t know where I want to end up.
I see where you’re coming from. I was struggling with that, but recently made a decision that it’s time to move on. Unless I’m adding something to a build system for a very common package, or a similar scenario, it’s ok to request non-posix tools. I’ll write my own tools in nushell but will start doing that for the team/company more once nushell hits 1.0. But for scripts I send to people, jq, fd and others are fair game. They’re easy to install and half the people already have them anyway. Code for the environment you want to see in the world.
And yes, some of them don’t have a stable interface for the output. I’ll try to avoid those outside of my own toys.
The biggest conflict for me is the command cache, bkt. I find it indispensable to include in my scripts, but I also think it’s too niche to expect anyone to have it. Luckily, I can just add a snippet to the top of a script (stolen from the official docs) and everything works fine!
# Cache commands using bkt if installed
if command -v bkt >&/dev/null; then
bkt() { command bkt "$@"; }
else
bkt() {
while [[ "$1" == --* ]]; do shift; done
"$@"
}
fi
As they point out, I think a lot of this is driven by Go and more recently Rust being actually pretty easy and nice to write CLI’s in. Python and Ruby and such are also nice to write CLI’s in, but don’t end up getting used as much for rewriting foundational stuff: Command line parsing, terminal/color interaction, etc. Sometimes people rewrite these sorts of things in Python, yes, but more often their users just wrap C libraries, so you end up with functional but slightly lame libraries that mostly inherit their C API’s. Meanwhile C# and Java are kinda painful to write CLI’s in, ‘cause their tools are not really designed to make it easy. Go and Rust programmers being C-averse means they rewrite a lot of that stuff, then think of ways to improve it, and give us things like termui and clap. (I was thinking of termbox originally too but turns out it’s all C; I learned it from termbox-go.) Suddenly writing CLI applications becomes so much easier ‘cause you don’t have to figure out how the hell to make some kind of argparse-y API work this month.
Go and Rust programmers being C-averse means they rewrite a lot of that stuff, then think of ways to improve it, and give us things like termui and clap.
I’m the author of clap and just a funny historical anecdote is I didn’t write clap because I was C-averse. I wrote it purely as a way to learn Rust. The company I worked for at the time had lots of small internal tools, that were shared between people so they all relied heavily on argument parsing. I thought building an argument parser for Rust would be a good way to learn Rust while not being entirely throw-away. At the time getopt and docopt existed, but like I said I wanted to build something myself to help me learn.
It just turned out a lot of people liked the API I came up with, and by following lots (lots) of little rabbit holes around command line applications me and the contributors I gathered came up with something kinda cool and ergonomic.
I think the point you were making in your comment still absolutely stands though!
That’s absolutely hilarious. Thank you for the tale. <3 And thank you for rummaging around in the rabbit holes and coming up with something that ends up being, imo, a great leap forward in tech!
I’m curious just how many widely used Rust tools and libraries are of this same origin. My CommonMark library — a clap consumer in its CLI variant! — was also a “learn Rust” project that I thought might have some use. Accidentally 7 years later and it’s in use in a lot of places!
Let’s talk about the terminal (emulator) in the room. Cursor movement is supported since around 1975. In 1976, vi was released, using full screen interactivity. The shell still employs CLI, which (mostly) limits the interaction to a single line. It doesn’t make sense to me. That’s why I’m working on Next Generation Shell. It’s amazing to me that most other projects are just ignoring the issue completely.
Oh hey, I must have missed this being posted. Author here. This is my first ‘real’ article, and it took me way to long to write, so some sections might be a bit disjointed…
There was a post a while back with the inflammatory title “GUIs are Antisocial” and the thrust of it was that work at the CLI produces artifacts that can be shared. I spent some hours trying to make sense of some weird directory full of json with
jqand when I figured out one file it was trivial to turn it into a script that handled everything.So there’s a conflict.
jqis indispensable. I work with it and I’m happy to put the resulting command in a script.rgis awesome. I put it in scripts that I’ll run myself.fdlooks like something I’d love. My command line work loses that quality of producing a shareable artifact. I don’t know where I want to end up.I see where you’re coming from. I was struggling with that, but recently made a decision that it’s time to move on. Unless I’m adding something to a build system for a very common package, or a similar scenario, it’s ok to request non-posix tools. I’ll write my own tools in nushell but will start doing that for the team/company more once nushell hits 1.0. But for scripts I send to people, jq, fd and others are fair game. They’re easy to install and half the people already have them anyway. Code for the environment you want to see in the world.
And yes, some of them don’t have a stable interface for the output. I’ll try to avoid those outside of my own toys.
The biggest conflict for me is the command cache, bkt. I find it indispensable to include in my scripts, but I also think it’s too niche to expect anyone to have it. Luckily, I can just add a snippet to the top of a script (stolen from the official docs) and everything works fine!
As they point out, I think a lot of this is driven by Go and more recently Rust being actually pretty easy and nice to write CLI’s in. Python and Ruby and such are also nice to write CLI’s in, but don’t end up getting used as much for rewriting foundational stuff: Command line parsing, terminal/color interaction, etc. Sometimes people rewrite these sorts of things in Python, yes, but more often their users just wrap C libraries, so you end up with functional but slightly lame libraries that mostly inherit their C API’s. Meanwhile C# and Java are kinda painful to write CLI’s in, ‘cause their tools are not really designed to make it easy. Go and Rust programmers being C-averse means they rewrite a lot of that stuff, then think of ways to improve it, and give us things like
termuiandclap. (I was thinking oftermboxoriginally too but turns out it’s all C; I learned it fromtermbox-go.) Suddenly writing CLI applications becomes so much easier ‘cause you don’t have to figure out how the hell to make some kind ofargparse-y API work this month.I’m the author of clap and just a funny historical anecdote is I didn’t write clap because I was C-averse. I wrote it purely as a way to learn Rust. The company I worked for at the time had lots of small internal tools, that were shared between people so they all relied heavily on argument parsing. I thought building an argument parser for Rust would be a good way to learn Rust while not being entirely throw-away. At the time getopt and docopt existed, but like I said I wanted to build something myself to help me learn.
It just turned out a lot of people liked the API I came up with, and by following lots (lots) of little rabbit holes around command line applications me and the contributors I gathered came up with something kinda cool and ergonomic.
I think the point you were making in your comment still absolutely stands though!
That’s absolutely hilarious. Thank you for the tale. <3 And thank you for rummaging around in the rabbit holes and coming up with something that ends up being, imo, a great leap forward in tech!
I’m curious just how many widely used Rust tools and libraries are of this same origin. My CommonMark library — a clap consumer in its CLI variant! — was also a “learn Rust” project that I thought might have some use. Accidentally 7 years later and it’s in use in a lot of places!
My favourite is trash-d, the only fast drop-in
rmreplacement that worked with hiccups in my experience.Let’s talk about the terminal (emulator) in the room. Cursor movement is supported since around 1975. In 1976, vi was released, using full screen interactivity. The shell still employs CLI, which (mostly) limits the interaction to a single line. It doesn’t make sense to me. That’s why I’m working on Next Generation Shell. It’s amazing to me that most other projects are just ignoring the issue completely.
https://youtu.be/J4_DGkKGWIo
https://github.com/ngs-lang/ngs/wiki/UI-Design
Oh hey, I must have missed this being posted. Author here. This is my first ‘real’ article, and it took me way to long to write, so some sections might be a bit disjointed…