>Discoverability: Reminding ourselves how to perform what we know (or assume) can be done isn’t the same as guiding us towards the full gamut of what’s possible.
I started with text mode CLIs on old 40-column computers like IBM PC DOS and Commodore 64 so I fully understand the techie's bias towards TUI command lines over GUIs. Lightweight, embed commands in scripts, command history, etc.
However, the tension between CLI power vs GUI ease-of-use really hit me when I'm the user of personal utilities I wrote. Coding a console utility that uses command line arguments is always faster and easier than a GUI app. So, being lazy, 99% of my utilities are CLI.
But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc.
That said, I still like CLI tools. E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. I really don't want to click around the bank's website or use a smartphone app.
It's funny, I started in the C64 era and have probably used a CLI for something roughly every day since then. But for me, using a CLI is still just a necessary evil - give me a GUI (or TUI) instead and I'll always take it.
The reason is that my memory sucks, and has always sucked. If I'm not typing a command every day, I'll forget it very quickly. If I am typing a command every day it's probably an alias or a script I've written to save myself some time so the "real" command is already forgotten. So in reality if it's not cd, ls, less, sudo or grep the chances are that I've forgotten it.
Where the CLI really shines is automation. Software I can control with a CLI in a script is amazing. So what I really want is for everything to have both a GUI and a CLI. I realise I'm asking a lot.
- spaced repetition for stuff that you use sporadically. I use Anki, it's great. For how to use it, this article is great: https://borretti.me/article/effective-spaced-repetition. I've found a positive feedback loop where the more I know how to do things without looking anything up, the more I use the CLI, the easier I remember things, the more things I discover, etc. I read once that when learning a new language, you should aim for content where you know 80%/90% already. It seems to be true for learning the CLI, and especially for integrating that learning into my day to day job.
- sd (https://github.com/ianthehenry/sd) for lowering the cost of creating a "documented alias". Before that I made aliases with either alias, or bash functions, all starting with "," to quickly see all which are "mine" (I read that trick in an article that I can't find), now the more complex stuff is in sd with some documentation.
w.r.t. forgetting CLI commands- I'd consider increasing the size of your shell history and setting up a way to fuzzy search through that history. I've been using FZF for this but am considering moving to atuin
It's great to be able to find the weird JQ filters or kubectl patch commands I ran last year when I need them
> But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc.
A better question is why OP isn't using a library that will do it for them!
Python's argparse is pretty good in this respect. Even if you don't supply help text and good metavar names, it'll at least give you --help output showing which options are supported, and adding help text and helpful metavar names is not much additional effort.
argparse has inspired a number of knockoffs in other languages, and the ones I've used are pretty good at --help output too. (Or you can write your own! If you've done this not only long enough to not only forget the syntax of command line tools you've written, but also often enough to have recognised this as a repeated trend, the effort involved could be worth it.)
It takes like 2 seconds in almost any language to do it too, just do it when you start your code, youll thank yourself later.
I even have a sort of template for shell scripts, if any arg will be on the commandline, it gets implemented.
For python (using argparse obviously), in my current project i built a toml file that handles the args. It allowed me to do more, like generating code blocks for js for the web frontend, documentation for both the cli and remote api, etc. Actually, now that I think about it, i might chunk that out to its own library.
> E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions.
Really, it'd be nice if they offered any upgrade from the 80s beyond a smartphone app. How does the rest of the world have better peer-to-peer payments than we do? How can I still not fully deny all transactions to a bank account? Why can't this banking app ask my permission before letting charges go through? Why is over-drafting a debit card possible at all? Why can I not ensure that a PIN is necessary to use my debit card in all situations and not just at a physical point-of-sale or ATM? Why do they all use SMS for 2FA—which has already bitten my twice?
I hate that Venmo and cashapp basically leech off the incompetence of our banking industry. Banking is a joke of an industry in dire need of regulation.
> But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is.
I try to avoid this in two ways:
1. I use the history in my terminal to search for previous invocations of the command, which tends to give me a good set of examples of how it should be used.
2. For anything but the quickest and dirtiest CLI tools, I like to use a declarative parameter parser like docopt or argparse. This forces me to spend a couple extra minutes writing some docs and makes the --help useful.
If there's a combination of options that I use for a command and catch myself forgetting it, I either make a script or an alias that I name appropriately.
All the scripts are in the same folder, so I can look through them if I forget which one. Same goes for aliases by using:
I started with text mode CLIs on old 40-column computers like IBM PC DOS and Commodore 64 so I fully understand the techie's bias towards TUI command lines over GUIs. Lightweight, embed commands in scripts, command history, etc.
However, the tension between CLI power vs GUI ease-of-use really hit me when I'm the user of personal utilities I wrote. Coding a console utility that uses command line arguments is always faster and easier than a GUI app. So, being lazy, 99% of my utilities are CLI.
But I also annoy myself as a user when I can't remember what the syntax options are for the CLI that I coded so I end up having to open the source code and re-examine the argc and argv sections to see what the spelling or ordering is. If this happens often enough, I give in and expend the extra effort rewrite the utility as a GUI app with radio buttons, checkboxes, etc.
That said, I still like CLI tools. E.g. I wish banks and credit cards had a pseudo SSH terminal that I could run text commands to list transactions. I really don't want to click around the bank's website or use a smartphone app.