10 ms·

The Modern CLI Renaissance

130 points by theshrike79 2y ago

godelski 2y ago
I'm loving how coreutils is getting improved and with how TUIs are exploding. It's just been a breath of fresh air. I hate to reach for my mouse. Side note: in vim you can press K to see the help page for a specific function. The default is the man page but some plugins will fix this though I'm not aware of one that's let me get away from documents and help files completely (I'd love to pick up docs of the codebase I'm working on. Anyone know of something that will?) But one thing I want to stress, the defaults of these tools should be the same as the originals as much as possible. This makes them more effective and adoption seamless. To give two examples fd and ripgrep default to respecting your .gitignore file. If you're not expecting this you can easily land yourself in trouble. Sure, it's in the readme but people are installing through their package managers so it doesn't matter. I'm glad the option exists, but don't make it the fucking default! We have aliases for that stuff. It's always better to error in the direction of too much output than too little. Output can be parsed and searched, but you can't when it's not there. Btw, here's what pacman says extra/fd 10.2.0-1 Simple, fast and user - friendly alternative to find extra/ripgrep 14.1.0-1 A search tool that combines the usability of ag with the raw speed of grep So I'm surprised people are surprised that people think you can just alias find or grep, since they are advertised as such and this is also what's said through word of mouth. (Yes, people should open man pages and visit the GitHub, but let's be real about our expectations)
- kstrauser 2y ago
  I strongly disagree. Neither of those tools claim to be drop-in replacements. They’re more like a reinvention of the older tools given what we’ve learned in the many decades since the originals came out, and tailored for the common use cases today. It’s rare that I want to grep, say, the node_modules directory in a JS project. The default of showing the results that git says are my own code is very useful. And as you say, there are aliases if you want to get off the beaten path.
  - godelski 2y ago
    Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.
    - poincaredisk 2y ago
      >Grep, sure, it is rare that I want to grep a binary file. Case in your point - I grep binary files all the time (mainly to look for strings in complied executables).
      - godelski 2y ago
        A hacker on hacker news‽ But yeah this is why I'm arguing for no filtering by default and why I believe the best designs are the most flexible ones. Because any time I think "nobody would need that" I find a world of people I didn't know about. You can't ever predict the usage, so flexibility and defaults aren't about what fits most people's use cases but what can be easily modified to use cases of any group. I'm definitely too dumb to figure out what everyone actually needs lol
    - setopt 2y ago
      Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied)?
- burntsushi 2y ago
  > I'm glad the option exists, but don't make it the fucking default! I very intentionally made it the default. It is one of ripgrep's (along with other tools like ack and ag) most important innovations. What you say is absolutely a cost. But it's a cost worth paying because it improves the user experience so much for tons of folks. Other than perf, the defaults are by far the most critical difference between ripgrep and typical POSIX grep programs. So if the defaults were the same as grep, it would be removing the most visible innovation! This default is half the reason of ripgrep's being in the first place. The docs are very clear and upfront about this. It's not reasonable for me to change the tool just because some users won't understand what they're installing. That's absurd. And of course, changing how it works now would be a massive breaking change that would confuse and piss off way more users. So guess what. It is never ever never going to happen.
  - Y_Y 2y ago
    I happily use ripgrep, but naively believed it was just naively looking at whatever files it was pointed at, like grep does. I get it, and it's probably more often than not the desired behavior, but it certainly violated the Principle of Least Surprise for me. Finally, being confused and pissed off is the default state for users. No config will ever be sane enough to avoid rancour.
    - burntsushi 2y ago
      When I use `grep` in a code repository and it turns up pointless results in my `.git` directory, that also violates the "Principle of Least Surprise." There's a reason why I don't follow the "Principle of Least Surprise" in any rigorous way, because everyone can be surprised by just about anything. I essentially never use that phrase in my writing or thinking because it's so vague and literally anyone can disagree with it about anything. As I've already acknowledged, the default skipping behavior is a cost. And this is precisely why this behavior is mentioned extremely prominently in all of my materials about ripgrep. The GitHub description: > ripgrep recursively searches directories for a regex pattern while respecting your gitignore The first two sentences of the README: > ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of `rg -h` and `rg --help`: > ripgrep (rg) recursively searches the current directory for lines matching a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of the description in the man page: > ripgrep (rg) recursively searches the current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files. Near the top of every release of ripgrep: > In case you haven't heard of it before, ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. Like, I've gone out of my way to make is superbly clear what it's doing by default. I can't control how other people write about ripgrep or talk about it, and just because I can't control that doesn't mean I should just give up that default behavior entirely. I'm not surprised if users miss this. I understand it. This is why I've acknowledged it as a cost. But I think the benefits outweigh the costs. I cannot tell you how many times folks are delightfully surprised (there's that principle again, but in the opposite direction, demonstrating again just how useless of a metric it is) when ripgrep automatically ignores all the junk they don't care about without them needing to think about it at all. ripgrep is an object lesson in the idea that defaults matter. This doesn't mean it's an unmitigated win from every possible perspective. And this is why ripgrep also makes it extremely easy to disable the automatic filtering: `rg -uuu`.
- JNRowe 2y ago
  When vim plugins change the effect of K, all they're likely doing is setting keywordprg¹. You can do the same yourself, fex to display info on the commit under cursor you'd use "setl kp=git\ show". You can write little script wrappers to fetch whatever custom resources you want, or you can up your game by writing vim commands so that you can use a count prefix to influence behaviour of the fetch too. ¹ https://vimdoc.sourceforge.net/htmldoc/options.html#'keywordprg' https://vimdoc.sourceforge.net/htmldoc/options.html#'keyword...
  - setopt 2y ago
    It’s worth noting that Vim has a lot of these *prg settings you can customize per file type: makeprg, formatprg, equalprg, etc.
  - godelski 2y ago
    I've actually found this before but found it hard to parse and little third party information on the subject. I've been able to get K to show things like standard Python docs but not modules and not docs from the active working project. I'm sure there has to be a way considering ctags and jumps exist but I think I need a full weekend you at least unravel all the moving parts without third party explanation.
- camgunz 2y ago
  This kind of thing isn't without precedent; ls famously ignores files/folders that start with a dot. ripgrep in no way tries to be a drop-in replacement for grep. Not only is it super explicit about it in all the docs, a major raison d'etre for it is its UX, which differs substantially from grep's. Also, it's fine if people make mistakes, flounder, or get stuck. When I installed RedHat 5.0 for the first time it took forever to figure out out how to run programs (gotta use ./), then it took forever to figure out how to use emacs, then it took forever to figure out how to save a file and exit emacs. Along the way I learned a ton about man and info pages, how to page up and page down, the names of the keys... skills and knowledge that have served me literally for decades (OK, maybe not how to use info pages). Not everything needs to be optimized for like, minimal number of clicks to purchase.
  - godelski 2y ago
    > ls famously ignores files/folders that start with a dot. This isn't related. There's a specific system standard. It's been that way for decades and is now expected. Last I checked, git isn't part of the unix system, isn't ubiquitous in file systems, and gitignores don't exclusively specify files that are junk or binary (I always exclude build artifacts, like most people, but build artifacts are useful to look at. And I do ML, so I'm never gonna include my checkpoints because git isn't for binaries, but I still want to search for them). > Also, it's fine if people make mistakes, Sure! And we should learn from the mistakes. I'm not arguing fd or rg should change. Momentum is a bitch. But if you're going to build a new tool, don't make this mistake. We've talked about principle of least surprises but let's also talk about the way you have to handle this issue. In my dotfiles, along with thousands of other people, I have alias fd="fd --no-ignore" But now we have an issue. What happens when I want to add back the ignore? Sure, with this example I just do `\fd` but doesn't if I add any of the other likely flags to my alias. So now you have to complexity your argument parser to handle precedence. Which dominates? Ignore or no ignore? Does order matter?[0] You now have to make choices to handle things you wouldn't have had to if you did it from the other way. This design choice requires more complexity overall to meet user demands. Given that aliases are the norm for these kinds of situations, it is not a hard ask to ask users to alias if they want this as the default. But let's talk about that generalization more, because I see this error in software all the time. People think Defaults should be what most people will use This is wrong, for multiple reasons. First, your tools will always take on a life beyond what you expect and you will always be bad at predicting what people need or want (therefore use flexibility). Second, while you should strive for this, there are many conditions that take higher priority. For example the principle of least surprise. Good design should strive for users not requiring a manual. It's almost always impossible to actually achieve, but you still do your best. One key aspect to this is understanding natural feedback. In our example of too much or too little we can see that there's natural feedback so the user can understand. And yes, the feedback will cause the user to likely reach for the manual, but it won't let them think something is right when something is actually wrong! Even if you know 90% of your users would be happy with a specific default this does not override the importance of natural feedback signals. It's why people will still push on a door labeled pull, because the design is telling them the instructions not the label. Labels are just a patch to fix what was just a bad design. Look, lots of design is ambiguous and there's almost never optimal solutions. But our specific example is a software version of a Norman door [0] for our specific example with fd it's probably safe to let the ignore flag strictly dominate but I'm sure you can understand examples where this won't be as obvious and that the conversation at hand actually generalizes far beyond even unix tools and is a general design principle.
apitman 2y ago
As far as I know, TUI is the only way to build a statically linked app that can be controlled with a mouse. If you're running in a terminal that supports sixel, that covers a huge class of apps. And you get lots of bonuses like excellent cross platform support and running over a network. It's honestly a compelling platform even without the nostalgia factor.
- actionfromafar 2y ago
  Interesting... never thought of that angle. Mouse control is pretty important.
- kragen 2y ago
  i think you are probably going to be a sad panda if you are running sixel apps over a network. vnc is passable, xpra is excellent inspired by your implicit challenge, i just compiled a statically linked app that can be controlled with a mouse on amd64 debian, which is at http://canonical.org/~kragen/tmp/static-μpaint http://canonical.org/~kragen/tmp/static-μpaint (2.3 megabytes, but remember that this is just code some random stranger on the internet linked for you to download and run, much like a random npm module). it was a little harder than i expected, but not really very hard. with respect to its staticness, i did get these warnings: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking but those are from functions buried deep in xlib that i may not actually be using. if you do dare to run my executable on your system, i'm interested to hear whether it works and what version of glibc you're using (i'm on 2.36-9+deb12u7) the program is my example paint program, source code in https://gitlab.com/kragen/bubbleos/blob/master/yeso/%CE%BCpaint.c https://gitlab.com/kragen/bubbleos/blob/master/yeso/%CE%BCpa..., explained line by line in https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.md#extended-example-%CE%BCpaint https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.m... the compilation command line was cc -static -Wall -Wno-cpp -g -Os -I. -std=gnu99 μpaint.o \ -L. -lyeso-xlib -lX11 -lXext -lpng -ljpeg -lm -lbsd -lz \ -lxcb -lX11 -lXau -lXdmcp -o μpaint which i was later able to reduce to cc -static -Wall -Wno-cpp -g -Os -I. -std=gnu99 μpaint.c \ -L. -lyeso-xlib -lXext -lX11 -lxcb -lXau -lXdmcp \ -lpng -ljpeg -lm -lbsd -lz -o μpaint and you should be able to build it from source if you clone my bubbleos repo and run `make` in the yeso directory. `make` will build a dynamically linked version, but the compilation command line above will build a static one instead this is using my minimal gui library `yeso` but i'm pretty sure the same approach would work for things like fltk which are designed for static linking. maybe it would work with more expansive libraries like gtk too
terminaltrove 2y ago
Excellent article of what is going on in the terminal space, agree on the TUI section where we are seeing lots of terminal tools being built in Rust and Go and libraries such as Ratatui [1] and Bubble Tea [2] becoming new modern alternatives to ncurses for building TUIs. Python has Textualize which is also very popular for building terminal user interfaces [3] And we've noticed this renaissance as well of new CLI and TUI tools that we list on Terminal Trove [4]. [1] https://ratatui.rs/ https://ratatui.rs/ [2] https://github.com/charmbracelet/bubbletea https://github.com/charmbracelet/bubbletea [3] https://textual.textualize.io/ https://textual.textualize.io/ [4] https://terminaltrove.com/ https://terminaltrove.com/
- euroderf 2y ago
  Ratatui is a great name. The landing page needs a rat!
- quotemstr 2y ago
  It's been disappointing me lately that we've all given up on terminfo --- or at least forgotten what it was for. Most of these new libraries just hardcode escape sequences. It'd be more future-proof and customizable for users to consult a terminal database like programs used to do, yes? Maybe it doesn't matter: the world has mostly converged on xterm-based control sequences. But what about newer capabilities? Without either a central terminfo database or some kind of standard way to query feature availability, we end up with an explosion of ad-hoc and opaque logic.
  - kragen 2y ago
    i don't think so. for future-proofness all you need is a standard; it doesn't matter very much whether that standard is vt100 escape sequences or terminfo names. i think vt100 escape sequences are a little better, and certainly programs written using them are easier to debug as for customizability, terminfo never provided real customizability, nor does it help with newer capabilities
sandreas 2y ago
Great article, especially the awesome tools collection at the bottom. I'm barely missing any of my daily drivers: # dra - automatically download release assets from github # example: dra download -a "dundee/gdu" -I "gdu" --output "$HOME/bin" devmatteini/dra # gdu - disk usage analyzer similar to ncdu but faster dundee/gdu # glow - terminal markdown reader charmbracelet/glow # jless - json viewer PaulJuliusMartinez/jless # lazydocker - terminal docker management ui jesseduffield/lazydocker # lazygit - terminal git management ui jesseduffield/lazygit # rga - ripgrep-all, grep for PDF phiresky/ripgrep-all
cyberax 2y ago
The stale field of terminals is also getting new developments. My particular favorite is Kitty input protocol that allows terminals to use such 21-st century functionality as accurate key press reporting: https://sw.kovidgoyal.net/kitty/keyboard-protocol/ https://sw.kovidgoyal.net/kitty/keyboard-protocol/
- sweeter 2y ago
  Kitty has done great work in this regard. The Keyboard Protocol and the Image Protocol is top notch. Accurate keys was a much needed change. The image protocol blows sixel and ascii out of the water. The thing that baffles me is that so many people are resistant to these two things because they don't like the lead dev.
  - wiseowise 2y ago
    > The thing that baffles me is that so many people are resistant to these two things because they don't like the lead dev. Who’s the developer of kitty… oh. It’s the guy who said he’ll single-handedly going to keep Python 2 alive?
    - dustypotato 2y ago
      I mean he's also the chief dev of calibre so that's a gold star
    - tasuki 2y ago
      > It’s the guy who said he’ll single-handedly going to keep Python 2 alive? I don't know about that, but he's extremely competent, so I wouldn't be too surprised.
    - aumerle 2y ago
      And that's just what he did until someone showed up to do the grunt work of porting to Python 3, at which point he co-operated with that person and helped make the port happen, just as he said he would. I suggest a more facts based narrative in the future. List of all python3 PRs merged by the developer in minutes to hours: https://github.com/kovidgoyal/calibre/pulls?q=is%3Apr+py3 https://github.com/kovidgoyal/calibre/pulls?q=is%3Apr+py3
JimDabell 2y ago
I would be very happy to see shells shed the idea that everything needs to be done in the context of emulating a terminal from the 70s. But even though new shells exist, I always end up writing shell scripts in ancient Bourne because I want them to run out of the box instead of requiring a third-party shell to be installed. Is there no appetite for a new default shell that could be adopted by Linux, macOS, and BSDs?
- hiAndrewQuinn 2y ago
  You could be the first! Fork Ubuntu, leave everything else the same, but have it run `fish` as the default shell with `bash` as a fallback. Alternatively, you could install default Ubuntu and run https://github.com/hiAndrewQuinn/shell-bling-ubuntu https://github.com/hiAndrewQuinn/shell-bling-ubuntu to switch your terminal to fish, kitty, and get a whole slew of other niceties in there by default. I found myself doing this a lot at my last job in VMs, which is why I have this set of shell scripts lying around and easy to audit.
  - dotancohen 2y ago
    You've really modernized the CLI there. I've been resisting doing that because I SSH into other machines often enough, but with your script I might just start. Thank you, nice work! As another big rg and tree (and ncdu, do you know of this) user, I highly suggest rotating one monitor 90 degrees. These tools with long output really benefit, as does web browsing, coding, and even the ability to see an entire page of a PDF without scrolling or making it tiny.
- sakjur 2y ago
  Having been recently exposed to PowerShell, I’m quite impressed by the balance they’ve struck in developing a new shell. I wouldn’t want to switch out Bash for PowerShell, but that’s mostly based on the same reasoning as you have (I can’t be bothered to install new shells everywhere). Though in a sense I think the most viable solution would be almost the opposite for UNIX: a reduced (and strict) shell syntax intended to be the target of crosscompilation rather than manual use. If it’d be possible to make that a subset of the standardized sh, there’d be automatic compatibility from the start and adoption wouldn’t need to happen on the consumer side. Still, we have binaries already. Binaries are much more capable than what I’m suggesting, though they are platform dependent. A variant of WASM, maybe?
throwaway984393 2y ago
CLI renaissance, or new dark age? The advent of the Web as the modern application platform of choice destroyed the advancement of graphical user interfaces. We now live in a bizarre world of CLIs when we should be using GUIs. Before the Web, and during its rise, there was a vast array of productivity tools designed to allow users to do more work, faster, and better, through graphical interfaces. It would have been ridiculous to release a program to users with only a command line interface. We left the dark ages of terminals behind, and pushed into new territory, advancing what users could do with computers. But once the Web began to develop the capabilities of browsers further, Web programming began to teach young programmers that the web was the only place that needed a graphical interface, because the web was a "universal" graphical application interface (lol, if you don't count the browser wars) This delighted programmers, as they never really liked making graphical interfaces. Logic and functions were more fun to write than user interfaces (which only made the users - not developers - happier). This was then hammered home when Markdown was widely adopted for its simplicity, inspiring a sort of text-based Stockholm-syndrome. People started to claim bizarre things, like that the command line and Markdown were preferable (or even superior) to GUIs and WYSIWYGs in almost all cases. More languages were adopted that had no inherent graphics capabilities, and the devs moved ever further towards text. So the web has unintentionally set back computer science and user productivity by decades. Until browsers lose the spotlight, this will probably continue, and non-web GUIs will continue to be that ugly thing you only write if you have to. Users will continue to languish in these half baked solutions, slaves to the solutions that are presented to them. And devs will continue to create text interfaces that only they enjoy. Rather than rethinking old ideas and creating new ones, we are simply doubling down on the past.
- Timwi 2y ago
  Thank you, this really needed saying. I was wondering if I was the only one who saw it.
- bool3max 2y ago
  This was all bound to happen anyway if not due to the "Web" then due to some other platform that would've evolved the same capabilities eventually.
- 2y ago
llm_trw 2y ago
To summarize: The people who ruined native GUIs moved to HTML pages. After ruining HTML pages they are now moving to terminals. In this very thread we're seeing people say "Well sure, but why not add ...". The reason why the CLI is good is because it _can't_ do most things people want it to do. Which means you have to think when making an application. Please, if you're one of the people 'modernizing' the terminal stop and think why the terminal is valuable. Don't make it into another of the long line of UIs which have been destroyed by modern developers.
- kvark 2y ago
  Having a standard CLI is definitely helpful. But does it have to be so hard to use? At what point would we acknowledge that we are being hostage by some random ideas put into ancient software, which just happened to survive? I don't think calling for a stop of experimentation is the way. Nobody is going to take away your vi and bash any time soon.
  - immibis 2y ago
    We shouldn't be held hostage, but the evolution of interactive CLIs is GUIs and the evolution of batch CLIs is scripting languages, and we don't need to render the CLI concept meaningless by integrating both. I've seen a terminal emulator that supported pixel graphics - what's the point! Just make a GUI using your favorite framebuffer library! A TUI is not a CLI, either.
- wiseowise 2y ago
  > The reason why the CLI is good is because it _can't_ do most things people want it to do. -1. You’ve lost me here. The reason why CLI is good because it solves problems that even modern GUIs can’t, not because of some artificial limitations or lack of convenient defaults. > Which means you have to think when making an application. “Think” and “remember obscure syntax that greyheads keep on a paper under their mattress” are two different things. I agree with the author that sensible defaults are severely lacking from some of the tools.
  - 2y ago
bradgessler 2y ago
I’ve been working on https://terminalwire.com https://terminalwire.com to scratch my own itch making it easier to add command-line interfaces into my own web apps. If I pull this off, building out a CLI that’s as high quality as GitHub & Stripe’s should be trivial since it won’t require building out a web API and it can be dropped into existing web frameworks. It won’t be as fast as a CLI that runs locally, but that’s kinda not the point of terminal apps that primarily interact with web services. I have a private beta for folks working on commercial SaaS products that want to deploy a CLI, but don’t want to deal with building out an API.
- edem 2y ago
  Why ruby?
solatic 2y ago
One interesting idea, in the Platform Engineering space (inside companies), is using TUIs to take advantage of credentials that may already be available on the developer's laptop. If you serve an internal app as a webapp, then you either need for the webapp to have a service user (icky audit logs) or waste lots of time setting up OAuth-style login flows so the webapp can authenticate as the user (and maybe IT doesn't like the idea anyway). Or, you write something that runs on the dev's laptop, and make use of the credentials that are already available locally, easy-peasy. Auth is simple, use the audit mechanisms that are already in place, easy.
- maccard 2y ago
  > waste lots of time setting up OAuth-style login flows so the webapp can authenticate as the user Being real - if you can’t manage an oauth library in 2024, you probably shouldn’t be deploying these kinds of apps, it’s about 30 lines of code in go, JavaScript or c# , and they’re just the languages I’ve implemented it in.
  - solatic 2y ago
    You realize adding the library is like maybe 10% of the work? * Talk to IT and get your library added to SSO. Make sure both staging and prod. * Ensure user deprovisioning works when IT initiates. Prove to IT that the underlying cached tokens no longer work when the user is deprovisioned, even if it's really the upstream system's responsibility * Convince InfoSec that the particular OAuth library you chose is legit and doesn't pose a security risk If you think 90% of implementation isn't getting approvals internally then you clearly don't work for a big company.
anthk 2y ago
Meh. If any, for Make, clone this and read the files: git clone git://bitreich.org/english_knight On the rest, nvi/vim and vis (vis is nice to cool with Sam-like extructural regexen) are more than enough. Nvi as the uberfast vi clone with Unicode support, and vim for Common Lisp with Slimv. On TUI tools, there's mc, ncdu... those are useful. A lot of them aren't. Finch vs an IRC client and Bitlbee, for instance, swirc + bitlbee it's far more usable, with FInch I always had to do voodoo with the panes.
surfingdino 2y ago
The reason why cli commands are written in C is the fact that the OS is written in C. There is a lot of inertia, because it is more efficient to have the operating system and the tools for it written in the same language. We may be entering a transitional phase with new tools written, old tools rewritten in Rust. Some of the innovation or simplification highlighted in the article remind me of the chaos of the Unix wars which led to POSIX. I wouldn't chuck out the tools we have though. Modernise them, but keep their functionality. What many critics of CLI tools do not realise is that there is a lot of power hiding in that complexity. Familiarise yourself with xargs or parallel commands to see that quite often learning them given you results faster than reimplementing them.
yonisto 2y ago
In my case I found it 20x times easier to hack a CLI tool that I can easily move around the organization that has mixture of Windows, Macs and Linux. Installation is just .zst file away.
camgunz 2y ago
I understand where TFA is coming from here. A lot of these tools are built to handle complex tasks and thus while powerful are complex themselves. It's also true that computing has changed a lot, and we've learned a lot since someone defined how `find` would work; maybe we'd do it the same or maybe we wouldn't, but it's definitely true that things are a lot different now. But I think we should be careful before dismissing the existing CLI/TUI landscape. It's a huge achievement that it's possible for code written in over a dozen scripting languages will just run across different architectures and platforms. A #!/bin/sh script running on a Raspberry PI, a WiFi router, a $20k server, a $300 Chromebook, or a $200 Pinephone will run exactly the same. That's because the standards and technologies that script relies on are ubiquitous. They don't cater to the top 1% of computer users, and they don't change every 5 years when average screen resolution increases. Which is to say, be careful what you wish for. It's pretty easy to modify your CLI or your semantics when you're not installed on millions of routers across the world [0]. With success comes backwards compatibility concerns, and it's not too long before people start writing blog posts about how your tool needs to "shed historical baggage". CLI tools are typically respectful of your resources, resources like: - network bandwidth - screen size - attention - CPU/RAM/disk We should keep this in mind when we're talking about what defaults make sense. Does enabling LSPs by default mean you have to download a bunch of LSPs you won't use? Does it mean you've gotta maintain a database of LSPs you use/installed? Does it mean I can't use it on a Pinebook Pro without taking 10% off my battery life? Is this core computing infrastructure like grep, find and xargs or something a little more niche like ripgrep or fzf? Does making this interface colorful respect a user's color configuration on their machine (colorblind users, users avoiding blue light, users who setup a desktop theme, etc.)? If this tool generates an error, will it dump 1 error line in my logs or 13? If it generates 100,000 errors because I was processing 100,000 things, will it dump 100,000 error lines in my logs or 1.3 million? I'm not saying there are clear answers here. My point is that while TFA argues there are clear answers, I'm saying there aren't. You have to target a use case. Andrew Gallant (ripgrep author, among other bonkers things) says he deliberately skipped .gitignore files by default because that's the use case he was targeting. That's great, and I can totally understand where he's coming from. I could also understand a different tool not doing it for different reasons. Neither is correct or incorrect (aside: as engineers, I think we could be taken more seriously if we stopped trying to argue our aesthetic preferences are correct or optimal or whatever--it's OK to just prefer things). Pick a use case. Pick an aesthetic. Pick a mental model. So, yeah write Helix, write new CLI and TUI tools. But don't do it because existing tools are old and busted or fundamentally incorrect (according to you). Do it because you have a different aesthetic preference (you like colors, you like emoji, you like autocomplete, you like WASD as cursor movement). You don't need the backing of righteous engineering gods before you build something you like. Let me have Vim and I'll let you have PyCharm. Let me have Gleam and I'll let you have Go. There's room enough on this disk for both of us. [0]: https://daniel.haxx.se/blog/2020/04/15/curl-is-not-removing-ftp/ https://daniel.haxx.se/blog/2020/04/15/curl-is-not-removing-...
kazinator 2y ago
My Bash prompt is now just $, and I have status line at the bottom that is protected from scrolling. https://www.kylheku.com/cgit/basta/about/ https://www.kylheku.com/cgit/basta/about/ Something called cdlog for directory navigation: https://www.kylheku.com/cgit/cdlog/about/ https://www.kylheku.com/cgit/cdlog/about/ Both of the above things are new [2024].

130 points by theshrike79 2y ago

I'm loving how coreutils is getting improved and with how TUIs are exploding. It's just been a breath of fresh air. I hate to reach for my mouse. Side note: in vim you can press K to see the help page for a specific function. The default is the man page but some plugins will fix this though I'm not aware of one that's let me get away from documents and help files completely (I'd love to pick up docs of the codebase I'm working on. Anyone know of something that will?) But one thing I want to stress, the defaults of these tools should be the same as the originals as much as possible. This makes them more effective and adoption seamless. To give two examples fd and ripgrep default to respecting your .gitignore file. If you're not expecting this you can easily land yourself in trouble. Sure, it's in the readme but people are installing through their package managers so it doesn't matter. I'm glad the option exists, but don't make it the fucking default! We have aliases for that stuff. It's always better to error in the direction of too much output than too little. Output can be parsed and searched, but you can't when it's not there. Btw, here's what pacman says extra/fd 10.2.0-1 Simple, fast and user - friendly alternative to find extra/ripgrep 14.1.0-1 A search tool that combines the usability of ag with the raw speed of grep So I'm surprised people are surprised that people think you can just alias find or grep, since they are advertised as such and this is also what's said through word of mouth. (Yes, people should open man pages and visit the GitHub, but let's be real about our expectations)

kstrauser 2y ago
I strongly disagree. Neither of those tools claim to be drop-in replacements. They’re more like a reinvention of the older tools given what we’ve learned in the many decades since the originals came out, and tailored for the common use cases today. It’s rare that I want to grep, say, the node_modules directory in a JS project. The default of showing the results that git says are my own code is very useful. And as you say, there are aliases if you want to get off the beaten path.
- godelski 2y ago
  Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.
  - poincaredisk 2y ago
    >Grep, sure, it is rare that I want to grep a binary file. Case in your point - I grep binary files all the time (mainly to look for strings in complied executables).
    - godelski 2y ago
      A hacker on hacker news‽ But yeah this is why I'm arguing for no filtering by default and why I believe the best designs are the most flexible ones. Because any time I think "nobody would need that" I find a world of people I didn't know about. You can't ever predict the usage, so flexibility and defaults aren't about what fits most people's use cases but what can be easily modified to use cases of any group. I'm definitely too dumb to figure out what everyone actually needs lol
  - setopt 2y ago
    Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied)?
burntsushi 2y ago
> I'm glad the option exists, but don't make it the fucking default! I very intentionally made it the default. It is one of ripgrep's (along with other tools like ack and ag) most important innovations. What you say is absolutely a cost. But it's a cost worth paying because it improves the user experience so much for tons of folks. Other than perf, the defaults are by far the most critical difference between ripgrep and typical POSIX grep programs. So if the defaults were the same as grep, it would be removing the most visible innovation! This default is half the reason of ripgrep's being in the first place. The docs are very clear and upfront about this. It's not reasonable for me to change the tool just because some users won't understand what they're installing. That's absurd. And of course, changing how it works now would be a massive breaking change that would confuse and piss off way more users. So guess what. It is never ever never going to happen.
- Y_Y 2y ago
  I happily use ripgrep, but naively believed it was just naively looking at whatever files it was pointed at, like grep does. I get it, and it's probably more often than not the desired behavior, but it certainly violated the Principle of Least Surprise for me. Finally, being confused and pissed off is the default state for users. No config will ever be sane enough to avoid rancour.
  - burntsushi 2y ago
    When I use `grep` in a code repository and it turns up pointless results in my `.git` directory, that also violates the "Principle of Least Surprise." There's a reason why I don't follow the "Principle of Least Surprise" in any rigorous way, because everyone can be surprised by just about anything. I essentially never use that phrase in my writing or thinking because it's so vague and literally anyone can disagree with it about anything. As I've already acknowledged, the default skipping behavior is a cost. And this is precisely why this behavior is mentioned extremely prominently in all of my materials about ripgrep. The GitHub description: > ripgrep recursively searches directories for a regex pattern while respecting your gitignore The first two sentences of the README: > ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of `rg -h` and `rg --help`: > ripgrep (rg) recursively searches the current directory for lines matching a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of the description in the man page: > ripgrep (rg) recursively searches the current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files. Near the top of every release of ripgrep: > In case you haven't heard of it before, ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. Like, I've gone out of my way to make is superbly clear what it's doing by default. I can't control how other people write about ripgrep or talk about it, and just because I can't control that doesn't mean I should just give up that default behavior entirely. I'm not surprised if users miss this. I understand it. This is why I've acknowledged it as a cost. But I think the benefits outweigh the costs. I cannot tell you how many times folks are delightfully surprised (there's that principle again, but in the opposite direction, demonstrating again just how useless of a metric it is) when ripgrep automatically ignores all the junk they don't care about without them needing to think about it at all. ripgrep is an object lesson in the idea that defaults matter. This doesn't mean it's an unmitigated win from every possible perspective. And this is why ripgrep also makes it extremely easy to disable the automatic filtering: `rg -uuu`.
JNRowe 2y ago
When vim plugins change the effect of K, all they're likely doing is setting keywordprg¹. You can do the same yourself, fex to display info on the commit under cursor you'd use "setl kp=git\ show". You can write little script wrappers to fetch whatever custom resources you want, or you can up your game by writing vim commands so that you can use a count prefix to influence behaviour of the fetch too. ¹ https://vimdoc.sourceforge.net/htmldoc/options.html#'keywordprg' https://vimdoc.sourceforge.net/htmldoc/options.html#'keyword...
- setopt 2y ago
  It’s worth noting that Vim has a lot of these *prg settings you can customize per file type: makeprg, formatprg, equalprg, etc.
- godelski 2y ago
  I've actually found this before but found it hard to parse and little third party information on the subject. I've been able to get K to show things like standard Python docs but not modules and not docs from the active working project. I'm sure there has to be a way considering ctags and jumps exist but I think I need a full weekend you at least unravel all the moving parts without third party explanation.
camgunz 2y ago
This kind of thing isn't without precedent; ls famously ignores files/folders that start with a dot. ripgrep in no way tries to be a drop-in replacement for grep. Not only is it super explicit about it in all the docs, a major raison d'etre for it is its UX, which differs substantially from grep's. Also, it's fine if people make mistakes, flounder, or get stuck. When I installed RedHat 5.0 for the first time it took forever to figure out out how to run programs (gotta use ./), then it took forever to figure out how to use emacs, then it took forever to figure out how to save a file and exit emacs. Along the way I learned a ton about man and info pages, how to page up and page down, the names of the keys... skills and knowledge that have served me literally for decades (OK, maybe not how to use info pages). Not everything needs to be optimized for like, minimal number of clicks to purchase.
- godelski 2y ago
  > ls famously ignores files/folders that start with a dot. This isn't related. There's a specific system standard. It's been that way for decades and is now expected. Last I checked, git isn't part of the unix system, isn't ubiquitous in file systems, and gitignores don't exclusively specify files that are junk or binary (I always exclude build artifacts, like most people, but build artifacts are useful to look at. And I do ML, so I'm never gonna include my checkpoints because git isn't for binaries, but I still want to search for them). > Also, it's fine if people make mistakes, Sure! And we should learn from the mistakes. I'm not arguing fd or rg should change. Momentum is a bitch. But if you're going to build a new tool, don't make this mistake. We've talked about principle of least surprises but let's also talk about the way you have to handle this issue. In my dotfiles, along with thousands of other people, I have alias fd="fd --no-ignore" But now we have an issue. What happens when I want to add back the ignore? Sure, with this example I just do `\fd` but doesn't if I add any of the other likely flags to my alias. So now you have to complexity your argument parser to handle precedence. Which dominates? Ignore or no ignore? Does order matter?[0] You now have to make choices to handle things you wouldn't have had to if you did it from the other way. This design choice requires more complexity overall to meet user demands. Given that aliases are the norm for these kinds of situations, it is not a hard ask to ask users to alias if they want this as the default. But let's talk about that generalization more, because I see this error in software all the time. People think Defaults should be what most people will use This is wrong, for multiple reasons. First, your tools will always take on a life beyond what you expect and you will always be bad at predicting what people need or want (therefore use flexibility). Second, while you should strive for this, there are many conditions that take higher priority. For example the principle of least surprise. Good design should strive for users not requiring a manual. It's almost always impossible to actually achieve, but you still do your best. One key aspect to this is understanding natural feedback. In our example of too much or too little we can see that there's natural feedback so the user can understand. And yes, the feedback will cause the user to likely reach for the manual, but it won't let them think something is right when something is actually wrong! Even if you know 90% of your users would be happy with a specific default this does not override the importance of natural feedback signals. It's why people will still push on a door labeled pull, because the design is telling them the instructions not the label. Labels are just a patch to fix what was just a bad design. Look, lots of design is ambiguous and there's almost never optimal solutions. But our specific example is a software version of a Norman door [0] for our specific example with fd it's probably safe to let the ignore flag strictly dominate but I'm sure you can understand examples where this won't be as obvious and that the conversation at hand actually generalizes far beyond even unix tools and is a general design principle.

apitman 2y ago

As far as I know, TUI is the only way to build a statically linked app that can be controlled with a mouse. If you're running in a terminal that supports sixel, that covers a huge class of apps. And you get lots of bonuses like excellent cross platform support and running over a network. It's honestly a compelling platform even without the nostalgia factor.

actionfromafar 2y ago
Interesting... never thought of that angle. Mouse control is pretty important.
kragen 2y ago
i think you are probably going to be a sad panda if you are running sixel apps over a network. vnc is passable, xpra is excellent inspired by your implicit challenge, i just compiled a statically linked app that can be controlled with a mouse on amd64 debian, which is at http://canonical.org/~kragen/tmp/static-μpaint http://canonical.org/~kragen/tmp/static-μpaint (2.3 megabytes, but remember that this is just code some random stranger on the internet linked for you to download and run, much like a random npm module). it was a little harder than i expected, but not really very hard. with respect to its staticness, i did get these warnings: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking but those are from functions buried deep in xlib that i may not actually be using. if you do dare to run my executable on your system, i'm interested to hear whether it works and what version of glibc you're using (i'm on 2.36-9+deb12u7) the program is my example paint program, source code in https://gitlab.com/kragen/bubbleos/blob/master/yeso/%CE%BCpaint.c https://gitlab.com/kragen/bubbleos/blob/master/yeso/%CE%BCpa..., explained line by line in https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.md#extended-example-%CE%BCpaint https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.m... the compilation command line was cc -static -Wall -Wno-cpp -g -Os -I. -std=gnu99 μpaint.o \ -L. -lyeso-xlib -lX11 -lXext -lpng -ljpeg -lm -lbsd -lz \ -lxcb -lX11 -lXau -lXdmcp -o μpaint which i was later able to reduce to cc -static -Wall -Wno-cpp -g -Os -I. -std=gnu99 μpaint.c \ -L. -lyeso-xlib -lXext -lX11 -lxcb -lXau -lXdmcp \ -lpng -ljpeg -lm -lbsd -lz -o μpaint and you should be able to build it from source if you clone my bubbleos repo and run `make` in the yeso directory. `make` will build a dynamically linked version, but the compilation command line above will build a static one instead this is using my minimal gui library `yeso` but i'm pretty sure the same approach would work for things like fltk which are designed for static linking. maybe it would work with more expansive libraries like gtk too

terminaltrove 2y ago

Excellent article of what is going on in the terminal space, agree on the TUI section where we are seeing lots of terminal tools being built in Rust and Go and libraries such as Ratatui [1] and Bubble Tea [2] becoming new modern alternatives to ncurses for building TUIs. Python has Textualize which is also very popular for building terminal user interfaces [3] And we've noticed this renaissance as well of new CLI and TUI tools that we list on Terminal Trove [4]. [1] https://ratatui.rs/ https://ratatui.rs/ [2] https://github.com/charmbracelet/bubbletea https://github.com/charmbracelet/bubbletea [3] https://textual.textualize.io/ https://textual.textualize.io/ [4] https://terminaltrove.com/ https://terminaltrove.com/

euroderf 2y ago
Ratatui is a great name. The landing page needs a rat!
quotemstr 2y ago
It's been disappointing me lately that we've all given up on terminfo --- or at least forgotten what it was for. Most of these new libraries just hardcode escape sequences. It'd be more future-proof and customizable for users to consult a terminal database like programs used to do, yes? Maybe it doesn't matter: the world has mostly converged on xterm-based control sequences. But what about newer capabilities? Without either a central terminfo database or some kind of standard way to query feature availability, we end up with an explosion of ad-hoc and opaque logic.
- kragen 2y ago
  i don't think so. for future-proofness all you need is a standard; it doesn't matter very much whether that standard is vt100 escape sequences or terminfo names. i think vt100 escape sequences are a little better, and certainly programs written using them are easier to debug as for customizability, terminfo never provided real customizability, nor does it help with newer capabilities

sandreas 2y ago

Great article, especially the awesome tools collection at the bottom. I'm barely missing any of my daily drivers: # dra - automatically download release assets from github # example: dra download -a "dundee/gdu" -I "gdu" --output "$HOME/bin" devmatteini/dra # gdu - disk usage analyzer similar to ncdu but faster dundee/gdu # glow - terminal markdown reader charmbracelet/glow # jless - json viewer PaulJuliusMartinez/jless # lazydocker - terminal docker management ui jesseduffield/lazydocker # lazygit - terminal git management ui jesseduffield/lazygit # rga - ripgrep-all, grep for PDF phiresky/ripgrep-all

cyberax 2y ago

The stale field of terminals is also getting new developments. My particular favorite is Kitty input protocol that allows terminals to use such 21-st century functionality as accurate key press reporting: https://sw.kovidgoyal.net/kitty/keyboard-protocol/ https://sw.kovidgoyal.net/kitty/keyboard-protocol/

sweeter 2y ago
Kitty has done great work in this regard. The Keyboard Protocol and the Image Protocol is top notch. Accurate keys was a much needed change. The image protocol blows sixel and ascii out of the water. The thing that baffles me is that so many people are resistant to these two things because they don't like the lead dev.
- wiseowise 2y ago
  > The thing that baffles me is that so many people are resistant to these two things because they don't like the lead dev. Who’s the developer of kitty… oh. It’s the guy who said he’ll single-handedly going to keep Python 2 alive?
  - dustypotato 2y ago
    I mean he's also the chief dev of calibre so that's a gold star
  - tasuki 2y ago
    > It’s the guy who said he’ll single-handedly going to keep Python 2 alive? I don't know about that, but he's extremely competent, so I wouldn't be too surprised.
  - aumerle 2y ago
    And that's just what he did until someone showed up to do the grunt work of porting to Python 3, at which point he co-operated with that person and helped make the port happen, just as he said he would. I suggest a more facts based narrative in the future. List of all python3 PRs merged by the developer in minutes to hours: https://github.com/kovidgoyal/calibre/pulls?q=is%3Apr+py3 https://github.com/kovidgoyal/calibre/pulls?q=is%3Apr+py3

JimDabell 2y ago

I would be very happy to see shells shed the idea that everything needs to be done in the context of emulating a terminal from the 70s. But even though new shells exist, I always end up writing shell scripts in ancient Bourne because I want them to run out of the box instead of requiring a third-party shell to be installed. Is there no appetite for a new default shell that could be adopted by Linux, macOS, and BSDs?

hiAndrewQuinn 2y ago
You could be the first! Fork Ubuntu, leave everything else the same, but have it run `fish` as the default shell with `bash` as a fallback. Alternatively, you could install default Ubuntu and run https://github.com/hiAndrewQuinn/shell-bling-ubuntu https://github.com/hiAndrewQuinn/shell-bling-ubuntu to switch your terminal to fish, kitty, and get a whole slew of other niceties in there by default. I found myself doing this a lot at my last job in VMs, which is why I have this set of shell scripts lying around and easy to audit.
- dotancohen 2y ago
  You've really modernized the CLI there. I've been resisting doing that because I SSH into other machines often enough, but with your script I might just start. Thank you, nice work! As another big rg and tree (and ncdu, do you know of this) user, I highly suggest rotating one monitor 90 degrees. These tools with long output really benefit, as does web browsing, coding, and even the ability to see an entire page of a PDF without scrolling or making it tiny.
sakjur 2y ago
Having been recently exposed to PowerShell, I’m quite impressed by the balance they’ve struck in developing a new shell. I wouldn’t want to switch out Bash for PowerShell, but that’s mostly based on the same reasoning as you have (I can’t be bothered to install new shells everywhere). Though in a sense I think the most viable solution would be almost the opposite for UNIX: a reduced (and strict) shell syntax intended to be the target of crosscompilation rather than manual use. If it’d be possible to make that a subset of the standardized sh, there’d be automatic compatibility from the start and adoption wouldn’t need to happen on the consumer side. Still, we have binaries already. Binaries are much more capable than what I’m suggesting, though they are platform dependent. A variant of WASM, maybe?

throwaway984393 2y ago

CLI renaissance, or new dark age? The advent of the Web as the modern application platform of choice destroyed the advancement of graphical user interfaces. We now live in a bizarre world of CLIs when we should be using GUIs. Before the Web, and during its rise, there was a vast array of productivity tools designed to allow users to do more work, faster, and better, through graphical interfaces. It would have been ridiculous to release a program to users with only a command line interface. We left the dark ages of terminals behind, and pushed into new territory, advancing what users could do with computers. But once the Web began to develop the capabilities of browsers further, Web programming began to teach young programmers that the web was the only place that needed a graphical interface, because the web was a "universal" graphical application interface (lol, if you don't count the browser wars) This delighted programmers, as they never really liked making graphical interfaces. Logic and functions were more fun to write than user interfaces (which only made the users - not developers - happier). This was then hammered home when Markdown was widely adopted for its simplicity, inspiring a sort of text-based Stockholm-syndrome. People started to claim bizarre things, like that the command line and Markdown were preferable (or even superior) to GUIs and WYSIWYGs in almost all cases. More languages were adopted that had no inherent graphics capabilities, and the devs moved ever further towards text. So the web has unintentionally set back computer science and user productivity by decades. Until browsers lose the spotlight, this will probably continue, and non-web GUIs will continue to be that ugly thing you only write if you have to. Users will continue to languish in these half baked solutions, slaves to the solutions that are presented to them. And devs will continue to create text interfaces that only they enjoy. Rather than rethinking old ideas and creating new ones, we are simply doubling down on the past.

Timwi 2y ago
Thank you, this really needed saying. I was wondering if I was the only one who saw it.
bool3max 2y ago
This was all bound to happen anyway if not due to the "Web" then due to some other platform that would've evolved the same capabilities eventually.
2y ago

llm_trw 2y ago

To summarize: The people who ruined native GUIs moved to HTML pages. After ruining HTML pages they are now moving to terminals. In this very thread we're seeing people say "Well sure, but why not add ...". The reason why the CLI is good is because it _can't_ do most things people want it to do. Which means you have to think when making an application. Please, if you're one of the people 'modernizing' the terminal stop and think why the terminal is valuable. Don't make it into another of the long line of UIs which have been destroyed by modern developers.

kvark 2y ago
Having a standard CLI is definitely helpful. But does it have to be so hard to use? At what point would we acknowledge that we are being hostage by some random ideas put into ancient software, which just happened to survive? I don't think calling for a stop of experimentation is the way. Nobody is going to take away your vi and bash any time soon.
- immibis 2y ago
  We shouldn't be held hostage, but the evolution of interactive CLIs is GUIs and the evolution of batch CLIs is scripting languages, and we don't need to render the CLI concept meaningless by integrating both. I've seen a terminal emulator that supported pixel graphics - what's the point! Just make a GUI using your favorite framebuffer library! A TUI is not a CLI, either.
wiseowise 2y ago
> The reason why the CLI is good is because it _can't_ do most things people want it to do. -1. You’ve lost me here. The reason why CLI is good because it solves problems that even modern GUIs can’t, not because of some artificial limitations or lack of convenient defaults. > Which means you have to think when making an application. “Think” and “remember obscure syntax that greyheads keep on a paper under their mattress” are two different things. I agree with the author that sensible defaults are severely lacking from some of the tools.
- 2y ago

bradgessler 2y ago

I’ve been working on https://terminalwire.com https://terminalwire.com to scratch my own itch making it easier to add command-line interfaces into my own web apps. If I pull this off, building out a CLI that’s as high quality as GitHub & Stripe’s should be trivial since it won’t require building out a web API and it can be dropped into existing web frameworks. It won’t be as fast as a CLI that runs locally, but that’s kinda not the point of terminal apps that primarily interact with web services. I have a private beta for folks working on commercial SaaS products that want to deploy a CLI, but don’t want to deal with building out an API.

edem 2y ago
Why ruby?

solatic 2y ago

One interesting idea, in the Platform Engineering space (inside companies), is using TUIs to take advantage of credentials that may already be available on the developer's laptop. If you serve an internal app as a webapp, then you either need for the webapp to have a service user (icky audit logs) or waste lots of time setting up OAuth-style login flows so the webapp can authenticate as the user (and maybe IT doesn't like the idea anyway). Or, you write something that runs on the dev's laptop, and make use of the credentials that are already available locally, easy-peasy. Auth is simple, use the audit mechanisms that are already in place, easy.

maccard 2y ago
> waste lots of time setting up OAuth-style login flows so the webapp can authenticate as the user Being real - if you can’t manage an oauth library in 2024, you probably shouldn’t be deploying these kinds of apps, it’s about 30 lines of code in go, JavaScript or c# , and they’re just the languages I’ve implemented it in.
- solatic 2y ago
  You realize adding the library is like maybe 10% of the work? * Talk to IT and get your library added to SSO. Make sure both staging and prod. * Ensure user deprovisioning works when IT initiates. Prove to IT that the underlying cached tokens no longer work when the user is deprovisioned, even if it's really the upstream system's responsibility * Convince InfoSec that the particular OAuth library you chose is legit and doesn't pose a security risk If you think 90% of implementation isn't getting approvals internally then you clearly don't work for a big company.

anthk 2y ago

Meh. If any, for Make, clone this and read the files: git clone git://bitreich.org/english_knight On the rest, nvi/vim and vis (vis is nice to cool with Sam-like extructural regexen) are more than enough. Nvi as the uberfast vi clone with Unicode support, and vim for Common Lisp with Slimv. On TUI tools, there's mc, ncdu... those are useful. A lot of them aren't. Finch vs an IRC client and Bitlbee, for instance, swirc + bitlbee it's far more usable, with FInch I always had to do voodoo with the panes.

surfingdino 2y ago

The reason why cli commands are written in C is the fact that the OS is written in C. There is a lot of inertia, because it is more efficient to have the operating system and the tools for it written in the same language. We may be entering a transitional phase with new tools written, old tools rewritten in Rust. Some of the innovation or simplification highlighted in the article remind me of the chaos of the Unix wars which led to POSIX. I wouldn't chuck out the tools we have though. Modernise them, but keep their functionality. What many critics of CLI tools do not realise is that there is a lot of power hiding in that complexity. Familiarise yourself with xargs or parallel commands to see that quite often learning them given you results faster than reimplementing them.

yonisto 2y ago

In my case I found it 20x times easier to hack a CLI tool that I can easily move around the organization that has mixture of Windows, Macs and Linux. Installation is just .zst file away.

camgunz 2y ago

I understand where TFA is coming from here. A lot of these tools are built to handle complex tasks and thus while powerful are complex themselves. It's also true that computing has changed a lot, and we've learned a lot since someone defined how `find` would work; maybe we'd do it the same or maybe we wouldn't, but it's definitely true that things are a lot different now. But I think we should be careful before dismissing the existing CLI/TUI landscape. It's a huge achievement that it's possible for code written in over a dozen scripting languages will just run across different architectures and platforms. A #!/bin/sh script running on a Raspberry PI, a WiFi router, a $20k server, a $300 Chromebook, or a $200 Pinephone will run exactly the same. That's because the standards and technologies that script relies on are ubiquitous. They don't cater to the top 1% of computer users, and they don't change every 5 years when average screen resolution increases. Which is to say, be careful what you wish for. It's pretty easy to modify your CLI or your semantics when you're not installed on millions of routers across the world [0]. With success comes backwards compatibility concerns, and it's not too long before people start writing blog posts about how your tool needs to "shed historical baggage". CLI tools are typically respectful of your resources, resources like: - network bandwidth - screen size - attention - CPU/RAM/disk We should keep this in mind when we're talking about what defaults make sense. Does enabling LSPs by default mean you have to download a bunch of LSPs you won't use? Does it mean you've gotta maintain a database of LSPs you use/installed? Does it mean I can't use it on a Pinebook Pro without taking 10% off my battery life? Is this core computing infrastructure like grep, find and xargs or something a little more niche like ripgrep or fzf? Does making this interface colorful respect a user's color configuration on their machine (colorblind users, users avoiding blue light, users who setup a desktop theme, etc.)? If this tool generates an error, will it dump 1 error line in my logs or 13? If it generates 100,000 errors because I was processing 100,000 things, will it dump 100,000 error lines in my logs or 1.3 million? I'm not saying there are clear answers here. My point is that while TFA argues there are clear answers, I'm saying there aren't. You have to target a use case. Andrew Gallant (ripgrep author, among other bonkers things) says he deliberately skipped .gitignore files by default because that's the use case he was targeting. That's great, and I can totally understand where he's coming from. I could also understand a different tool not doing it for different reasons. Neither is correct or incorrect (aside: as engineers, I think we could be taken more seriously if we stopped trying to argue our aesthetic preferences are correct or optimal or whatever--it's OK to just prefer things). Pick a use case. Pick an aesthetic. Pick a mental model. So, yeah write Helix, write new CLI and TUI tools. But don't do it because existing tools are old and busted or fundamentally incorrect (according to you). Do it because you have a different aesthetic preference (you like colors, you like emoji, you like autocomplete, you like WASD as cursor movement). You don't need the backing of righteous engineering gods before you build something you like. Let me have Vim and I'll let you have PyCharm. Let me have Gleam and I'll let you have Go. There's room enough on this disk for both of us. [0]: https://daniel.haxx.se/blog/2020/04/15/curl-is-not-removing-ftp/ https://daniel.haxx.se/blog/2020/04/15/curl-is-not-removing-...

kazinator 2y ago

My Bash prompt is now just $, and I have status line at the bottom that is protected from scrolling. https://www.kylheku.com/cgit/basta/about/ https://www.kylheku.com/cgit/basta/about/ Something called cdlog for directory navigation: https://www.kylheku.com/cgit/cdlog/about/ https://www.kylheku.com/cgit/cdlog/about/ Both of the above things are new [2024].