[HN Gopher] CLI user experience case study
___________________________________________________________________
CLI user experience case study
Author : Xophmeister
Score : 147 points
Date : 2024-01-12 11:01 UTC (11 hours ago)
(HTM) web link (www.tweag.io)
(TXT) w3m dump (www.tweag.io)
| hhthrowaway1230 wrote:
| I love CLIs, i try to find inspiration in the one simon willison
| makes. His CLIs extremely good on the DX side.
|
| Llm, sqlite-utils and datasette are all very thoughfully thought
| of tools/clis.
|
| So good that I have been thinking to mail him to see if he wanted
| to write a blog post about his way of thinking about it. Its top
| notch from naming the subcommands the plugin systems.
|
| I always try to think along the lines of: I've i'm going to use
| this CLI a 1000 times each day. How do i want to use it. And if i
| want to automate it, how can i script it.
|
| Also CLI commands are basically contracts, since people will
| program against it.
|
| Good CLIs are very interesting puzzles bringing human ux and
| scriptability together. Aws cli's also have an interesting
| approach to it.
| simonw wrote:
| Thanks for saying that!
|
| I did write a post with a few of the things I've learned about
| CLI design here: https://simonwillison.net/2023/Sep/30/cli-
| tools-python/
| indymike wrote:
| That's going into the required reading folder for new devs at
| my company. Thanks for writing that!
| hhthrowaway1230 wrote:
| Thank you! Weird that I missed it haha! Will do some reading
| and will start applying the lessons learned! And ill reach
| out if im missing anything!
| atoav wrote:
| As someone who teaches these things occasionally to non-tech
| people I think the hard thing about CLI tools are the following:
|
| 1. The terminal when you first open it is intimidating to most
| and doesn't offer any help to figure out how to use it. If people
| _think_ something is hard, they will have a harder time
| understanding it as well (same goes for thinking something will
| be boring, there have been studies on that)
|
| 2. Text editing in the terminal works different than literally
| anywhere else. You can't simply click and mark text, shortcuts
| are different, etc.
|
| 3. You have to _get_ that text has to be exact, you have to know
| syntax rules with where to put spaces, how to work with quotes,
| escape strings and all that. That is just not easy. For those of
| us who already speak any given shell, this may be aomething we
| forget. But it is like learning a language and a way to think.
| Once you are fluent, it is easy.
|
| But it is worth it in my opinion, especially if you want to work
| with niche special tools or if you want reliable tools that will
| just work for decades.
| 9dev wrote:
| So do you think a terminal that works more along the way of
| thinking of non-technical people, or maybe similar to other
| text-based applications, could provide an entry point to non-
| technical power users?
|
| I have been thinking a lot about providing a shell-like
| experience as a quick way to make advanced functionality
| available in an app, without having to build fully fledged GUIs
| for them, but I'm not sure whether that would work. Clearly,
| discoverability and text input are the key issues, but I don't
| know if alleviating those is sufficient to make the interface
| actually interesting and useful.
| jonfw wrote:
| VSCode's command palette is a great example of this- 1. fuzzy
| search through different options 2. Show lots of suggestions
| as soon as you focus in the text box 3. have a ? or other
| "learn more" option available
|
| I still think it leans very technical though, users would
| greatly prefer buttons. There's a good reason that powerpoint
| doesn't have one of these
| swozey wrote:
| When I make terminal apps I make both a TUI and CLI option if
| the app is big enough to benefit from it. Here's an example:
|
| https://i.imgur.com/dxXwRzD.gifv
|
| This allows the less familiar or technical staff to do things
| with the app and also allows for veterans or CLI afficiandos
| to alias/run what they want directly from the cli.
| bluetomcat wrote:
| The principal problem of any sufficiently advanced CLI tool is
| the combinatorial explosion of options. With more than a dozen
| options, you start having special cases like "it does foo when
| the bar option is used, baz otherwise". In a GUI, you generally
| express exclusivity or inclusivity with the use of the correct
| UI elements - a checkbox can become disabled when something
| else is selected.
| _kb wrote:
| That would be an interesting interaction to explore with a
| colourised terminal. Essential have contextual colouring on
| input so that mutually exclusive params are either shaded in
| the case of clear precedence or highlighted for conflict.
| It's not an area I've played with but wonder if that could be
| hacked into exisiting autocomplete mechanisms?
| oblio wrote:
| fish shell.
| JeffSnazz wrote:
| With all these command-line parser libs, I'm surprised there
| aren't more libraries that automatically generate a graphical
| interface for them. Would be super useful for e.g. ffmpeg,
| cc, curl, etc. Especially for people unfamiliar with the
| program....
| blackbear_ wrote:
| There is for Python: https://github.com/chriskiehl/Gooey
| indymike wrote:
| Early on (late 90s and early 00s) there were a lot of
| command line to gui kinds of tools (there were also a lot
| of tries at web-ifying, CLI tools also). I can't remember
| the name, but there was even a terminal emulator that tried
| to present commands as dialogs.
|
| * There is no enforced standard for commands other than
| using a file name to invoke them.
|
| * Different languages and frameworks have different and
| multiple ways of parsing command lines. For example Gooey
| (a python gui tool) works with scripts written with the
| argparse library but dodes not work with optparse.
|
| * The terminal is not the shell. That means that to present
| a gui, you'll have to launch something that runs outside of
| the terminal to present the gui.
|
| * It's common for developers to write command line tools
| with out understanding the shell and os's input and output
| system beyond reading and writing files. I routinely have
| to teach jr developers about stdio, stderr, pipes etc...
|
| That said, there's great potential to take advantage of
| shell autocomplete files to make better guis for commands:
| https://blog.deepjyoti30.dev/tab-autocomplet-cli-apps .
| Someone probably already has done this...
| JeffSnazz wrote:
| The idea is that you'd build it into whatever command-
| line parsing tool you use. Presumably this would be
| runtime-specific. And yes, the entire point is to escape
| the terminal and rely on native interface constraints
| (e.g. disabling/enabling) to reflect the usage of the
| tool.
| CubsFan1060 wrote:
| https://github.com/Textualize/trogon
| PurpleRamen wrote:
| It doesn't even need to be a full GUI, just having an
| interactive interface for weaving commandline-spells on the
| fly would already improve the access. But then again, this
| would demand a more complex interface than a commandline.
| I'm not sure how easy this is implementable with your
| average shell&terminal.
| mooreds wrote:
| There are some reasonably complex git tuis.
| https://github.com/extrawurst/gitui is one
| arccy wrote:
| a good shell completion function is like 80% of the way
| there, it can even include descriptions for flags, and the
| smart ones will know about exclusions and such
| bee_rider wrote:
| I know people write these kinds of programs and I write these
| kinds of programs, but the obvious solution to this
| predicament is that we should have more, simpler tools so
| that instead of a combinatorial mess of options, you get a
| collection of composable tools.
| dwaltrip wrote:
| People want to solve their problems in the simplest way
| possible.
|
| They will only use composition if there isn't a tool that
| solves the problem by itself.
| roenxi wrote:
| (1) is an important point, but I think it doesn't go far
| enough. The terminal offers no help at all to a casual user
| (the funniest case of this is watching a new user trying to
| quit vim [0]).
|
| There are a specific set of skills required to learn how to use
| the terminal - a combination of knowing when and how to read
| man pages, when to look up Stack Overflow, when to look up
| YouTube videos, and where to hang out to learn about more
| esoteric commands exist like `parallel`.
|
| Without those skills - and there is no recommended path on how
| to get them - the terminal is unusable. It isn't a case of
| people thinking it is hard, it is actually logically impossible
| to learn how to learn terminal commands without getting lucky
| at the start.
|
| Software has two phases - a learning phase and a using phase. A
| lot of great software ideas died quietly because there wasn't a
| sanctioned route to scale the learning curve.
|
| [0] Or this classic:
| https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...
| Phiwise_ wrote:
| To add on to (1), expeeienced hackers trying to educate new
| users really should first immerse themselves into
| descriptions of the "bad old days" of utility programming to
| help get back into the mindset of the novice they're trying
| to relate to. Your ed link is good, and I like the "Power
| Tools for Power Fools"/"Teeminal Insanity" chapter of The
| Unix-Haters Handbook for something slightly more modern:
| https://simson.net/ref/ugh.pdf#page=185
|
| Just like no one really uses ed anymore, the C shell is
| pretty much dead and many userspace programs have had their
| edges rounded over the years, but the experience of trying to
| imagine working around their foibles gives the perspective
| necessary to helpfully advise someone trying to learn an
| acceptable shell today (except that they'll have more use for
| their effort at some point) because they're pretty much the
| same kind of transition. Compare these highlights to that ed
| page:
|
| >Pipes are not the be-all and end-all of program
| communication. Our favor-ite Unix-loving book had this to say
| about the Macintosh, which doesn't have pipes: "The Macintosh
| model, on the other hand, is the exact opposite. The system
| doesn't deal with character streams. Data files are extremely
| high level, usually assuming that they are specific to an
| application. When was the last time you piped the output of
| one program to another on a Mac? (Good luck even finding the
| pipe symbol.) Pro-grams are monolithic, the better to
| completely understand what you are doing. You don't take
| MacFoo and MacBar and hook them together." Yeah, those poor
| Mac users. They've got it so rough. Because they can't pipe
| streams of bytes around how are they ever going to paste
| artwork from their drawing program into their latest memo and
| have text flow around it? How are they going to transfer a
| spreadsheet into their memo? And how could such users expect
| changes to be tracked automatically? They cer-tainly
| shouldn't expect to be able to electronically mail this
| patched-together memo across the country and have it
| seamlessly read and edited at the other end, and then
| returned to them unscathed. We can't imagine how they've been
| transparently using all these programs together for the last
| 10 years and having them all work, all without pipes.
|
| >This morning I read an article in the Journal of Human-
| Computer Interaction, "Expertise in a Computer Operating
| System," by Stephanie M. Doane and two others. Guess which
| operating system she studied? Doane studied the knowledge and
| performance of Unix novices, intermediates, and expert users.
| Here are few quotes: "Only experts could successfully produce
| composite commands that required use of the distinctive
| features of Unix (e.g. pipes and other redirection symbols)."
| In other words, every feature that is new in Unix (as opposed
| to being copied, albeit in a defective or degenerate form
| from another operat-ing system) is so arcane that it can be
| used only after years of arcane study and practice. "This
| finding is somewhat surprising, inasmuch as these are
| fundamental design features of Unix, and these features are
| taught in elementary classes."
|
| In both cases, we have someone moving from a relatively
| monolithic, high-level, restricted, commercialized system
| that focuses on uniformity, error-bar tolerance, and
| DWIM/intuitiveness of the intended or common use-case over
| giving every capability equal billing to one that focuses on
| completeness, atomicity, and implementation
| simplicity/efficiency. Learning this transition has two
| phases because the best way to keep going with the learner's
| current knowledge has two phases: Before making the
| transition they probably learned the old system through self-
| tutoring and exploration; the stakes were low enough and the
| environment painstakingly organized to be similar enough that
| a little curiosity and a little induction from past
| experience explained basically every level of the user-
| visible stack, and the slab of composed foundation functions
| that made the first-blush system run were either walled off
| fully or guarded to wave away novices. Pre grokking the new
| software, though, the user lacks the idioms that make it
| possible to write a more complete computing system out of
| less code, and so don't know when to apply what even if
| they've read up on most of the pieces they need already. It's
| like a transition from an upper-class aerospace engineer or
| hedge fund manager exploring _Animal Kingdom Park_ to making
| a trek through the indian jungle. Even if you 're carrying a
| reference tome on the region there are intangibles you're
| just missing, so you're far more likely to get lost and
| confused or hurt yourself if you don't walk right in the
| footsteps of someone expeeienced for a good long while. It's
| similar with the terminal: When you're successful, things are
| clearer and simpler than a jumbled heavyweight gui, but when
| you make the "mistakes" that come along with not almost
| entirely knowing what you're doing it can be unhelpful,
| mystifying, and rarely dangerous, because the experienced
| users happen to be the most-engaged target market. Not
| everyone has Apple money, after all.
|
| The phase change back to effective exploration, and actual
| use over learning through apeing, only comes after they've
| got both most of the terrain _and_ most of the problem-
| solving strategies in their head all at once to hit a self-
| sustaining critical mass. Something akin to the Khan(academy)
| flipped method is what I think is most important to remember
| when teaching: most experienced users think in terms of
| learning new skills through integrating new components, while
| beginners tend to know less about the implications of
| recombining the utilities they 're already aware of in the
| less common and simple ways than show up as line snippets in
| crash courses. New users can read a man page as well as you
| can recite it by heart, but what they really need tutoring in
| is how to know they're reading the right part of the right
| page and what your experience says to do with it.
|
| Just getting that all off my chest as someone who didn't have
| anyone to teach me and used to be spectacularly bad at
| teaching others, so someone might learn from my mistakes.
| swozey wrote:
| 1. You teach so your experience is probably very different from
| us SWE/SREs who only work with other technical staff for the
| most part.
|
| 2. You can add cursor and mouse control to your .nanorc. I'm
| not sure if bash, etc have that. With that said, I have cursor
| enabled in my .nanorc along with a bunch of other stuff. The
| cursor thing.. I'm kind of confused on how you use it, but I
| rarely use it. It's (to me) weird. I think I just havent used
| it enough to really know its capabilites.
|
| I think as a teacher it'd be super helpful to you to have a
| base set of dotfiles that your students just git clone when
| they start the class. Or even better, have them write their own
| and just provide them the settings you want them to enable.
| When I bring new SREs on board, without the base dotfiles for
| them to grab on day 1 it takes practically a week for someone
| to get setup and ready to work.
|
| Have each of them commit their dotfiles to their own repos,
| probably forked from yours. That will get them familiar with
| github. Then try to get them to actually build out a github
| portfolio. I spent 6 months interviewing for a few positions
| last year and I was really surprised how few people had githubs
| with anything on them. It's not my main criteria but it's nice
| when someone has put effort into their gh/gitlab/etc profile
| and projects.
|
| Also please teach them about filesystems. Most of the younger
| people (20s) I interviewed knew very little
| linux/containerization/filesystems.. I think the filesystem
| thing is from them growing up with MacOS and iPhones. They
| don't need to dig into anything beyond their "folders" if even
| that.
|
| 3. Absolutely one of my CLI annoyances here. I wrote another
| comment explaining why it frustrates me.
|
| Related to your last sentence- I'd say 99% of the CLI/TUI apps
| I write are things that give you an easy front end (TUI and
| simple commands/flags) to perform backend systems tasks. So I
| have a ton of them as an SRE. The main reason I like to put
| things in a TUI and not just CLI flags is that ANYONE can hop
| in and use it because the options are all displayed to you
| front and center. You just use arrows or numbers to navigate.
|
| I do TUI *AND* command line flags because some people want to
| do it quick and fast, or make aliases, etc for what they're
| doing. THen there's the TUI which opens if you don't run a
| flag, the TUI is so, so helpful to people new to the apps.
|
| This lets me democratize the various apps I've created and let
| anyone who isn't me use them. It's great.
|
| Here's one example of my TUI+CLI apps. This is super old it's
| much prettier now.
|
| https://i.imgur.com/dxXwRzD.gifv
| cfiggers wrote:
| > I do TUI _AND_ command line flags because some people want
| to do it quick and fast, or make aliases, etc for what they
| 're doing. THen there's the TUI which opens if you don't run
| a flag, the TUI is so, so helpful to people new to the apps.
|
| YES, this is the way to go! I've written a couple of internal
| tools that work this way and it's the best of both worlds
| IMO.
| swozey wrote:
| Yeah I love it. Makes the CLI only people happy and can let
| you spread the app around to people less familiar with what
| it does, etc.
|
| https://i.imgur.com/dxXwRzD.gifv
| bee_rider wrote:
| I've worked with helping beginner students set up their
| environments a bit. I'm skeptical of the idea of providing
| too much in the way of custom dotfiles or anything like that.
| Students will come with their own systems. Mac, or Windows,
| usually. So a professor or grad student who naturally uses
| Linux and isn't really a software deployment expert might
| have trouble getting a rock-solid portable collection of
| scripts. It might seem like an odd difficulty for smart and
| technical people to have, but administrating other people's
| systems is a totally different skill from research after all!
|
| More importantly, in a class of a couple hundred, somebody
| _will_ find a way to get off the happy path. No matter how
| well you design it. Hopefully they'll come to a teaching
| assistant or something, but there's a good chance they'll go
| to YouTube or something instead. In that case, it is best if
| their installation is as standard as possible.
|
| Also the filesystem problem is such a thing and you have
| dredged up some feelings, hahaha. In particular, I think
| operating systems and VSCode have gotten _way_ too good at
| hiding the fact that the file somebody is editing is, in
| fact, still in a zip archive. Until they go to save it or run
| it.
| nkrisc wrote:
| The biggest issue I've see , particularly regarding your first
| point, is simple discoverability of capabilities.
|
| It is very difficult, at least initially, to even begin to
| discover what's possible in a terminal environment.
|
| There are so many important things that a new user simply needs
| to be taught, or they will likely never discover basic
| functionality - such as how to even open, read, and navigate
| the manual.
|
| The UX barrier to entry is very high without hand-holding or
| extensive online searching and a strong willingness to
| persevere in the face of adversity.
|
| GUI applications (generally) solve the initial discoverability
| barrier by simply showing you what's possible.
|
| I remember being a kid looking at DOS and wondering "what do I
| even _do?_ " It was essentially a blank screen with very little
| indication of how to proceed. My dad had sticky notes on the
| monitor with the commands to enter to run games.
|
| I never really looked at a command line again after I started
| using the Windows desktop until I started really learning
| programming after college, and it was just as daunting at
| first.
| datastoat wrote:
| It'd be fun (and a bit scary) to use an LLM as a shell
| replacement. We'd give it the history of our commands as per
| the recent post [0], as well as their outputs, and it would
| turn natural-language commands into proper bash. The xkcd comic
| [1] would be solved instantly. "Tar these files, please."
| "Delete all the temporary files but please please please don't
| delete anything else." I'm sure people have implemented this,
| but my searching isn't good enough to find it.
|
| [0] https://news.ycombinator.com/item?id=38965003
|
| [1] https://xkcd.com/1168/
| floren wrote:
| I have briefly told ChatGPT 3.5 about the syntax of a CLI
| tool I wrote, then asked it to perform a few operations. It
| did a surprisingly good job, even when I said "and format the
| result as JSON with fields named Command and Description
| where the latter explains what the command does".
|
| If I was to actually use this in a real system, I'd
| definitely build a restricted shell to execute in, and
| probably run it inside a Docker container with just the
| essential files mapped in, because I don't trust an LLM not
| to _describe_ what it 's doing as "updating timestamps" or
| whatever but _actually_ the command is "rm -rf ~"
| mgdlbp wrote:
| btw xterm has a hack for editors without mouse support - turn
| clicks into the right number of movement key presses,
| uxterm -xrm '*VT100.translations: #override !<Btn1Down>: vi-
| button() readline-button()'
| yjftsjthsd-h wrote:
| > 2. Text editing in the terminal works different than
| literally anywhere else. You can't simply click and mark text,
| shortcuts are different, etc.
|
| One of the interesting things Plan 9 did differently is that
| its terminal is rather more like a standard graphical text
| editor that happens to have the ability to execute a line. As
| someone used to unix terminals this was super jarring, but I
| can see where it would be nice.
| diversion wrote:
| As all computer interfaces evolved in the past decades (from text
| to graphical interfaces, to touch screens and voice commands),
| the users' expectations have changed and the CLIs need to evolve
| as well. Today's users don't have time or willingness to learn
| something before they can use it. The number of tools in daily
| has grown as well, so they really don't have the mental capacity
| for that.
|
| We will always need CLIs for things that are to cumbersome or
| rare to add into GUIs; but they have to become easier to use, and
| provide immediate value.
|
| That's why we built an interactive CLI by default at Diversion.
| It's not a revolutionary tool (there are other similar CLIs), but
| it has shown to help our users get started with Diversion much
| faster - the feedbacks are overwhelmingly positive.
| BossingAround wrote:
| From my experience, interactive CLIs are the worst of both
| worlds.
|
| They are not as pretty and intuitive as GUIs, since the user
| has to learn terminal idiosyncrasies (e.g. unable to ctrl+c, or
| edit text in the middle of the sentence by mouse).
|
| And, at the same time, they tend to be pretty bad for
| automating things (in the worst case, even unsuitable for
| automation) since now, you have to map the interactive commands
| to the non-interactive ones.
| diversion wrote:
| You're right in that an interactive CLI's interface is not
| trivial to nail. We're spending a lot of dev time on that
| actually. And of course there always also has to be a non-
| interactive version for automations.
| Borg3 wrote:
| It depends on tool. If this is some generic utiliy that
| interacts streams, it most probably should not be
| interactive. But for example if this tool is some kind of
| control shell for subprocess (like Quagga vtysh or FW control
| CLI) it would be much easier to use in interactive fashion
| (autocompletion, interactive help and hints system).
| pr337h4m wrote:
| Discord has pretty much figured out how to give CLIs an actual UX
| with their bots and slash commands.
|
| Midjourney is the largest of the Discord apps that have achieved
| mainstream usage, despite being CLI-only.
| diggan wrote:
| Huh? The UX is pretty much the same as in the terminal; "Here
| is a command, a small snippet of help text and a bunch of
| options, figure it out", not sure what Discord improved upon
| here. Autocomplete?
| anthk wrote:
| Slash commands predate Discord by large.
| latexr wrote:
| Bots and slash commands have been a staple of chat for decades
| before Discord.
|
| https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_co...
|
| They're no different from other CLIs, UX-wise. But because they
| are intermingled with chat, you can ask for help from a human
| right there.
| esafak wrote:
| This is funny on multiple levels. For one, it is IRC that
| introduced these commands decades ago, as others have observed.
| The second is that the Discord "UX", especially for Midwinter,
| is atrocious. You couldn't pay me to use it.
| williamcotton wrote:
| ?? I need to recursively tar a directory
|
| https://githubnext.com/projects/copilot-cli/
| s1291 wrote:
| That webpage does not explain how to get it. Instead, I
| recommend using gorilla-cli [0].
|
| [0] https://github.com/gorilla-llm/gorilla-cli
| novagameco wrote:
| Powershell cmdlets make the CLI really nice to use; you declare
| the variables in your program parameters and then hitting tab
| will auto-suggest/auto-complete them for you, and you can
| generate help docs for each cmdlet as well
| jasode wrote:
| _> 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.
| alright2565 wrote:
| > 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.
| JeffSnazz wrote:
| > 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.
| sanitycheck wrote:
| 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.
| jonfw wrote:
| 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
| Zababa wrote:
| A few things that can help with memory:
|
| - 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.
| Sponge5 wrote:
| 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:
| alias | grep <original command>
| yjftsjthsd-h wrote:
| > 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.
|
| Why are you not implementing -h & --help?
| Borg3 wrote:
| Because he is lazy :)
|
| I use CLI a lot.. Im lazy too. But pretty much 90% of my
| tools implement --help because some tools are used not that
| often.
|
| If I ever try to use tool that does not have nice and clean
| --help output I curse :)
| DrBazza wrote:
| The consistency rule I follow in any CLI tools I write: options
| are optional, required are commands or arguments.
|
| Anything with `-` or `--` is an _optional_. Just like all the
| basic unix /linux tools. You don't have to `ls --thing` to list a
| folder, just `ls`. Or `cat --magic --args the_file` and so on.
|
| If I _require_ an 'option', it becomes a command or an
| _argument_ for the command, i.e. `tool --list-files` becomes
| `tool ls`. Copy for example: `cp src dest` works, `cp` on its
| own, doesn 't.
|
| I even tend to write extensible CLI tools, `tool-ls` will drop
| into the same folder as `tool` and running `tool` will detect
| `tool-ls` and present it in the list of commands. Just like git.
| swozey wrote:
| One of my huge frustrations is the inconsistency between
| various apps or even in the same app.
|
| Sometimes it's "executable -help" or "executable --help",
| sometimes it's executable -h, or --h.
|
| I also find it really annoying when running a bad/wrong/typoed
| command doesn't give you a "You wrote fkuc but did you mean
| ...." those are super helpful.
|
| IMO, if you use --help, you also should be using -help, and -h
| --h, unless you're using C and c to seperate two different
| commands. Which I don't like AT ALL. Don't make --help show
| help but --HELP show something different. Use a different
| word/letter.
|
| I write TUI apps ALL the time and it's not hard to do ANY of
| this. It's super easy in go and ruby. There are two big things
| I do - I add CLI flags that you can run directly - "executable
| --help" which does the same thing as opening the TUI app with a
| nice little TUI menu where anyone can use it and select their
| options and put a couple of inputs in to get what they want
| done. So, if you DON'T want the potentially slighty slower of
| uising the TUI vs a CLI command with a few flags you can just
| run the commands directly.
|
| Hell, if someone puts the wrong CLI --flag in instead of
| letting it just bomb with a *nix error have it echo the actual
| command flags. Don't make me have to dig around for commands.
|
| And don't send me to your manpage with --help. God I hate that.
| Manpages sometimes are absolutely awful. I want ONE command
| flag that you made some esoteric word for, I want a nice
| concise list of the flags. I do NOT want a 5 page manpage
| written so dry and cumbersome that it's such a pain to read
| that we have other cheatsheet apps.. I ONLY want the manpage if
| I ask for the manpage.
| TheCleric wrote:
| > IMO, if you use --help, you also should be using -help, and
| -h --h
|
| I tend to go by the paradigm of single dash for single
| character options, and double dash for full words (and common
| things like ---help should have aliases like -h).
| swozey wrote:
| That's interesting. Did you come up with that yourself or
| is that a common standard?
|
| I've always wondered why the style of command flags wasn't
| "more" standardized after 32 years of Linux being around
| (not that thats the first time flags were introduced, just
| an easy stop so I don't have to dig into that since it's
| not super relevant).
|
| So, maybe it is somewhat/completely standardized and I'm
| just not aware of where that information is?
|
| I think your style would still frustrate me. I'd first type
| "executable -help" thinking that was probably the - and --
| option, and get a command not found error. I wouldn't think
| that think we're using - and -- differently.
| tom_ wrote:
| The --long-option thing is a GNU thing: https://www.gnu.o
| rg/software/libc/manual/html_node/Argument-...
| swozey wrote:
| I've never even thought about this. I think this is kind
| of strange
|
| > An option and its argument may or may not appear as
| separate tokens. (In other words, the whitespace
| separating them is optional.) Thus, -o foo and -ofoo are
| equivalent.
|
| Thanks this is super helpful I never knew this was a GNU
| thing.
| yjftsjthsd-h wrote:
| Note that there's an opposite convention that I think
| originated with the BSDs, where -ofoo is equivalent to -o
| -f -o -o
| cb321 wrote:
| That only holds when 'o' and 'f' are both boolean "flags"
| taking no arguments. If 'f' is more like --file=x then it
| takes an argument.
|
| More specifically, getopt(3) in POSIX lets programmers
| very this by giving a format string. "o:f" would make
| your example parse as "-o" "foo" while "of:" would make
| it parse as "-o" "-f" "oo" and an "of" format would make
| it parse as you describe, "-o" "-f" "-o" "-o".
|
| ( darnir mentioned parts of this above:
| https://news.ycombinator.com/item?id=38968612 using the
| term "single character flags" to indicate no argument. )
|
| Also, while --long-option is GNU, gcc which is perhaps
| the aboriginal GNU command-line utility uses single dash
| as in, e.g. `gcc -pipe`, though it also accepts `gcc
| --help`. CL syntax remains quite varied in the wild.
| darnir wrote:
| That used to be a fairly common standard. You'll notice
| nearly all the old GNU / BSD tooling use this paradigm.
| It is even codified in GNU's coding principles. In fact,
| when you do that, you can even merge all the single
| character flags together. For example, I can type, `ls
| -lah` instead of `ls -l -a -h`. Pretty handy.
|
| My pet peeve is commands not supporting -h for help and
| making me write --help. This is especially worse when the
| command already supports single character arguments.
| TheCleric wrote:
| Definitely not my idea, but is encouraged by built-in
| tools like python's argparse [0] or node's util.parseArgs
| [1] which definitely guide you toward's this
| "short"/"long" style.
|
| [0]: https://docs.python.org/3/library/argparse.html
|
| [1]: https://nodejs.org/api/util.html#utilparseargsconfig
| strunz wrote:
| This only works with CLI that take a few arguments. If you're
| writing a CLI that requires 5+ arguments, then positional
| arguments are very hard to remember the order of. -- arguments
| make that easier.
| democracy wrote:
| As someone who started with speccy and cp/m I hate command line -
| and also nothing beats good commander like FAR Manager for simple
| stuff
| neatze wrote:
| seems like wrong case study, cli power (at least for me) is in
| comments and record keeping what has been done months if not
| years ago, and an "easy way" to script repetitive tasks, I just
| don't see how same thing can be achieved with GUI:
|
| record video and then comment it ?
|
| have detailed logs what button, and what fields where
| edits/pressed ?
|
| etc ...
| jvanderbot wrote:
| Minor point, but on a recent project I stepped around Clap,
| looking for something that was small, focused, and fewer silly
| edge cases. Argp works really well. Highly recommend.
| gumby wrote:
| I hate the "sub command" model and consider it user hostile.
| Among other things it makes the shell's ! commands harder to use.
|
| Instead of git add you should have git-add. Few bother to get
| this right.
| rocky_raccoon wrote:
| As a layman designing an app with subcommands, can you explain
| this a bit further? I'm only familiar with using !! to bring up
| the previous command.
| swozey wrote:
| They're saying that they don't want sub commands (executable
| --action actionsoption).
|
| They prefer (executable --actions-option) which is a command
| flag as opposed to chaining commands off one another.
|
| Example: https://i.imgur.com/dxXwRzD.gifv
| matheusmoreira wrote:
| I think it's very user friendly. As a user I can easily access
| functionality when the application's modules are organized as a
| little taxonomy of commands. Hierarchy is good.
|
| > Among other things it makes the shell's ! commands harder to
| use.
|
| How so?
| swozey wrote:
| I write a lot of tui/cli apps and I've never even considered
| doing sub commands. I always do --my-action-1 and --my-
| action-2.
|
| I can't think of any huge positives from using subcommands. I
| know for a fact that that will take longer to write and add
| some complexity to --args-* and I also feel like getting a
| quick --help option would be a lot more cumbersome.
|
| Maybe a good way there is to list commands then tabbed/dashed
| indented under the root command list its subcommands.
| gbalduzzi wrote:
| I like that sub-commands usually have a different --help
| output
|
| git --help
|
| git add --help
|
| The former returns general information about the whole git
| executable, while the latter returns specific details about
| the add command.
|
| It also gives an immediate intuition of entering a whole
| different flow that can not be composed with other flows,
| something that you don't have with --args There is a
| hierarchy between commands and options that is not
| expressed when both use the -- syntax
| olejorgenb wrote:
| I've never understood how people manage to use ! in a useful
| way. Primarily I think because if you get anything wrong,
| repeating the command does something completely different. But
| maybe I'm not fully familiar with all the functionality because
| I don't understand why sub commands would make a difference?
| olejorgenb wrote:
| I guess it's because !TEXT does a prefix search for TEXT in
| the history and TEXT can't contain spaces
| rocky_raccoon wrote:
| Would there be any usefulness in some sort of a "CLI standard"
| that defines certain behaviors and provides useful
| recommendations?
|
| e.g.,
|
| - Apps must always have a --help/-h argument
|
| - Apps that require subcommands or arguments must display "Usage"
| or "Help" when no subcommand or argument is specified
|
| - When an invalid subcommand or argument is inputted, apps must
| display "Usage" or "Help"
|
| - Arguments that require a file/resource as a parameter SHOULD
| use the --file/-f flag where possible (and other standardizing
| best practices)
|
| Most of this stuff is already built into clap etc. If nothing
| else, it could remove some of the initial cognitive load.
| thomasahle wrote:
| Always requiring "-f" for files is over the top. Think about
| commands like "mv", "cp" or even "less".
| Izkata wrote:
| Also that already means "force" for a lot of commands,
| including two of the ones you mentioned.
| floren wrote:
| Or the many cases where you want to specify an input file and
| an output file.
| CubsFan1060 wrote:
| https://github.com/Textualize/trogon
|
| > Ultimately we would like to formalize this schema and a
| protocol to extract or expose it from apps. This which would
| allow Trogon to build TUIs for any CLI app, regardless of how
| it was built. If you are familiar with Swagger, think Swagger
| for CLIs.
| jdxcode wrote:
| it's not complete, but I've been thinking about this problem
| for years and have been thinking about how to solve it.
|
| I am working on it here: https://github.com/jdx/usage
|
| It's mostly just a README right now, and I'm still iterating
| on it, talking to friends, but I think I'm getting close.
| It's definitely not yet written for the average developer to
| consume yet either. My hope is within the next month or two I
| might have a usable alpha release of it. I have a use-case
| for it now so I think it's finally ready to happen.
|
| If you have any thoughts on my design lmk.
| cb321 wrote:
| You probably already know, but _just in case_ you don 't,
| you might read about http://docopt.org/ It seems to me a
| lot of your usage ideas could be refinements of / tooling
| around docopt-style interfaces.
| jdxcode wrote:
| Yeah I investigated. I don't think it works well that
| direction. It is appealing and you can see some elements
| of it in my current design, though that's a particular
| part I'm still unsure of.
|
| It gets way too complicated real quick and a lot of
| things you _dont_ want to expose in documentation. It's
| better to generate docs from a spec than the other way
| around, I'm pretty sure of this now.
| cb321 wrote:
| There is also generating the whole thing from a function
| signature (e.g. https://github.com/c-blake/cligen ) since
| then CLauthors need not learn a new spec language, but
| then CLauthors must add back in helpful usage
| metadata/semantics and still need to learn a library API
| (but I like how those latter two things can be
| "gradual"). It's a hard space in which to find
| perfection, but I wish you luck in your attempt!
| jdxcode wrote:
| My goal is that one day framework authors will adopt this
| (they might do it quickly since it's a hell of a lot
| easier to dump a usage spec and generate completions than
| it is figuring out how to write completions for each
| shell).
|
| At that point it would make sense for them to also make
| scaffolding generators, meaning the cli author only has
| to write one spec and don't have to repeat the effort for
| their code so much.
| jdxcode wrote:
| I think there are 2 ways usage will be used, either as an
| under the hood format used by frameworks to make
| frameworks better, or directly by users to scaffold
| framework code
| akdor1154 wrote:
| Ah sweet, I have been wanting to do pretty much the same
| thing, have found one or two bits of prior art but nothing
| that has caught on. Very interested.
| eddd-ddde wrote:
| There's also: - Treating '-' as STDIN file - Allowing users to
| get more output using -v - Skipping certain "write" actions by
| using --dry-run
|
| Then there's dd...
| chusk3 wrote:
| Capturing these guidelines is one of the primary reasons that
| https://clig.dev/ exists.
| orliesaurus wrote:
| Ok there's a really good point here about when commands 'layout'
| shifted from:
|
| `command -function`
|
| To
|
| `command function -option`
|
| Example:
|
| Why is it:
|
| ssh -l bob myhost.com
|
| Vs
|
| ssh login bob myhost.com
| bluetomcat wrote:
| The "subcommand" approach is the one popularised by Git. It
| makes sense for complex tools that incorporate many different
| actions. Every action is essentially its own CLI tool. That
| approach isn't suited well to the traditional Unix mindset
| where a single tool is supposed to do one thing and do it well
| - "ls" is meant to list files and "tr" is meant to replace
| characters, and you should be able to pipe them together.
| cb321 wrote:
| Not to challenge anything you said, but rather expand upon
| it.. git just followed a grand tradition of software version
| control systems in general (sccs/cvs/svn/..):
| https://lobste.rs/s/dnazns/contextual_clis#c_b7rl9k
| seveibar wrote:
| Most projects design CLIs wrong, CLIs should be interactive by
| default to maximize discovery, everything from the command
| selection, to option selection, to specific parameter enum or
| even searchable resource ids. A -y flag should force it to be
| non-interactive. This is what I did with seam-cli and the usage
| of command line tools over eg postman for interacting with our
| API exploded- a good interactive CLI is all you need. It helps to
| use a well-defined schema, or for an API company an OpenAPI
| schema, to keep the CLI up to date and to maximize it's
| capabilities.
| latexr wrote:
| "Most" would be an awful experience. You wouldn't be able to
| pipe anything in a terminal or write a script without polluting
| everything with a bunch of `-y` all over the place.
| error9348 wrote:
| Terseness is the point. Man pages can be discoverable too if your
| shell supports autocomplete
| Workaccount2 wrote:
| Linux will be eternally doomed to <5% market share as long as
| it's developers harbor their masochistic fetishization of the
| linux terminal.
|
| You have ostensibly "user friendly" distros like Ubuntu, that
| still, in 2024, refuse to implement the standard ctrl+v for paste
| and add a modern cursor to their terminal.
|
| The OS is kept artificially difficult to use, just because it's
| maintainers get off on knowing it's cryptic interface language.
| Imagine an LLM better than GPT-4, but the devs only speak Klingon
| and refuse to implement English because Klingon is more efficient
| on paper. Then they constantly groan about low adoption and
| training data availability, while death gripping Klingon as the
| superior way of interfacing.
|
| Please, for the sake of humanity trapped in Microsoft's dungeon,
| please come down off your CLI high horse and make a user friendly
| OS.
| at_a_remove wrote:
| Around 1999, I said to someone, "You cannot be 'l33t' and also
| have the Year of the Linux Desktop."
|
| And some people really love that _l33t_ feel, right down to
| git. I 've had people here tell me that "reflog" is just as
| intuitively obvious as "undo." You can't reason with those
| people.
|
| I'm scratching an itch right now to make a wizard-driven
| application, but in the CLI. Right now I am noticing little
| subtle bits of friction driven by Arcanery, such as things
| which aren't easily possible in Windows being available in
| Linux, but locked behind a hoop or two. Even the input prompt
| itself in my chosen language is slightly sad.
| yjftsjthsd-h wrote:
| > You have ostensibly "user friendly" distros like Ubuntu, that
| still, in 2024, refuse to implement the standard ctrl+v for
| paste and add a modern cursor to their terminal.
|
| The user-friendly distros - _correctly_ - aim to solve this by
| making terminal use optional, not by taking on the nigh-
| impossible task of completely changing how input works in the
| terminal.
|
| > The OS is kept artificially difficult to use, just because
| it's maintainers get off on knowing it's cryptic interface
| language.
|
| Also, that's not the reason. It's not some superiority complex
| or fetish, it's that the existing terminal paradigm is really
| good for what it's good for and there's no point in sacrificing
| the existing user-base in order to try and appeal to a wider
| audience who will never use it anyways.
| Workaccount2 wrote:
| You are correct. If you use a computer to check your email
| from your grandkids because you somehow still don't have a
| smartphone - yes, the terminal is optional.
|
| But please, enlighten me how an average modern desktop
| computer user could install a free media codec pack on a user
| friendly distro without opening the terminal?
|
| Linux has this problem where if you want to do _anything_
| above the absolute most basic tasks, you have to start
| goolging and copy+pasting cryptic lines of text into the
| terminal and cross your fingers that it does what you hope it
| will. As soon as you break away from the tasks that 95% of
| users do, you 're in for punishment.
|
| Mind you, I have been using ubuntu for 18 months now. And
| have been using Linux on and off for 20 years. I do it
| because...Micorsoft, but holy shit am repeatedly stunned by
| how average-user hostile linux is. They just refuse to stop
| speaking Klingon except for the most absolute basic things.
| yjftsjthsd-h wrote:
| > But please, enlighten me how an average modern desktop
| computer user could install a free media codec pack on a
| user friendly distro without opening the terminal?
|
| Do you need to? I thought Ubuntu shipped codecs by default
| these days. But if it's an extra package, I was pretty sure
| Ubuntu shipped a GUI frontend to package management these
| days, and if that's not good enough you can use it to
| install synaptic and do whatever you need[0][1].
|
| > but holy shit am repeatedly stunned by how average-user
| hostile linux is. They just refuse to stop speaking Klingon
| except for the most absolute basic things.
|
| To marginally overextend the metaphor, you speak English
| (which is a terrible mess of a language[2], but it's
| familiar to you), immigrated into the Klingon Empire,
| appear to understand that Klingon is actually a more
| efficient language, and still want the Klingons to stop
| speaking Klingon and convert to using English, because you
| want it to be easier to flee the Terran Empire[3] if they
| did even though most people won't do so regardless.
|
| [0] https://itsfoss.com/synaptic-package-manager/
|
| [1] https://help.ubuntu.com/stable/ubuntu-help/addremove-
| install...
|
| [2] I say this as a native speaker: English is a horrible
| mess of a language, mostly because it _started_ as 3 other
| languages in a trench coat and never stopped tacking on
| bits and pieces of other languages.
|
| [3] Okay, the metaphor is way more than marginally
| overextended, but it's not like people would flee the
| Federation...
| esafak wrote:
| He is saying you need to meet people where they're at. At
| least give them the _option_.
| yjftsjthsd-h wrote:
| For the simple case, the option is there (Ubuntu and
| Fedora have their software centers and GUI control
| panels, SUSE has YAST), just most native users don't use
| them. For the complex case, it's not practical because
| that would mean overhauling the long tail of packages.
| wavemode wrote:
| I'm genuinely curious what you see as an ideal state here? Most
| end-user oriented Gnome and KDE-based desktop OS's (Ubuntu,
| Fedora, Mint etc.) are already mostly configurable from menus,
| for most features an end-user would need to care about. (If I'm
| mistaken - what feature did you have in mind which isn't?)
| Outside of that, just run the application you're trying to run.
|
| Why would the user need to worry about the ergonomics of the
| terminal? Is that something people worry about on Windows and
| MacOS?
| JohnMakin wrote:
| As someone that spends 99.99% of their working day in the
| terminal with CLI's, here are the things I want -
|
| - clear documentation, eg --help
|
| - order of parameters should not matter
|
| - clear, helpful error messages (git is great at this)
|
| - consistent outputs
|
| That's all I want. It can be as complicated as you want it to be,
| as long as you do this stuff I don't really care. One tool that
| comes to mind I use a lot that does not do this well is jq. It's
| very unintuitive, at least to me.
| protomikron wrote:
| An annoying thing is if CLI tools don't exit with non-zero if the
| tool is used incorrectly.
|
| It's pretty standard to print the usage string if the tool is
| invoked with invalid arguments. However the program should then
| also exit with non-zero, otherwise it can be inconvenient to use
| in scripting.
| 1vuio0pswjnm7 wrote:
| Why does the title omit the program beng studied. It easily fits
| within the 70 character limit.
|
| Correct title is:
|
| CLI User Experience Case Study: Topiary
___________________________________________________________________
(page generated 2024-01-12 23:00 UTC)