The usual solution is to read the manual. The CLI is not an esoteric language. Software does complex things and you can either go with the GUI-fiction which...does things. Or have every options available to do what the software can do. Take find where the first line is the manual is: find - search for files in a directory hierarchy. Think however you want to find files inside a specific directory and find can do it for you and more. Most users will only have a few use cases for finding and that's what most GUI file explorers offer, but when you need that extra power, it's available to you.

The solution for your problem is to not do stuff you don't understand. And for the above use case, there's usually a GUI for it. The CLI stuff heavily assume that you know what you're doing.

the cli is just as much of a fiction, just fiction with a different focus

i agree that reading the manual is helpful, but doing stuff you don't understand is necessary to come to understand it, so i don't think it's good advice to avoid it. using the cli for simple things builds the skills you can use for more complex things. the same is true of a gui

(of course there are clis and guis incapable of doing complex things, and those are kind of a dead end)

> but doing stuff you don't understand is necessary to come to understand it

Only if you're doing an experiment and can constrain accidents. Any other type of activities would require to read the manual first. They're terse because they're supposed to be a reference, but you can usually find books that ease the way in. And then there's the domain expertise that is required. You need networking knowledge to interact with software like ip, operating system knowledge to understand what top is showing to you, etc. You can't get around that.

The GUI is a fixed canvas already painted by someone else, the CLI let you write your own poetry.

as i said in my other comment at https://news.ycombinator.com/item?id=40912296, text really helps a lot with constraining accidents

obtaining networking and operating systems knowledge includes as an essential part using software like ip and top (though try htop instead). it's not a strict sequencing but a back-and-forth interplay, synergistic with factors like study and mentorship

as for poetry, there are plenty of clis that aren't very expressive—rt-11, cp/m, grub, ms-dos, and mpv come to mind—and plenty of guis that are very expressive, such as godot, blender, inkscape, labview, solidworks, freecad, and sieuferd. you can write your own poetry as easily in godot as in bash

what would be ideal from my point of view for check boxes, dropdowns, and labels would be if they were a simultaneous alternative view of a command line, or rather a configuration line. an additional simultaneous view would provide a live preview of the result of that line. but you could still type and copy and paste the text

interestingly this is not too far from my usual experience with the command line. i want to compile a target, so i type `make ` and hit tab twice. i see a list of targets and pick one by typing a letter or three and tab, and hit enter. the compiler errors out right away with a c99 construct, so i add `-k` to the command line (^p spc - k ret) to see how widespread the carnage is. it's everywhere, so i add a compiler flag to the options and try again. and in 30 seconds i have a working build. or maybe i need to use a different compiler, or something, but it's easy to return to the fresh unpacked tarball or git checkout

this is close to the opposite extreme from what you describe in

> You just changed something. Didn't fix the problem. But the change still happened. Can you undo it? Probably not without way more digging.

i very rarely do anything in text mode that is in any way hard to undo. shell commands are mostly purely ephemeral: their only effect is some text on your screen, an entry in your history file, and maybe an output file. if i want to change one, i hit ^p and change it before hitting enter. as for configuration changes, i would say that change management is actually the major strength of the text approach: you can copy configuration lines into your notes, comment out old versions in case you want to go back to them, check the whole configuration into git, diff it to see what all has changed, etc. everything can be undone in exactly the same way. everything is a controlled experiment, with the computer itself recording the configuration of each trial automatically and implicitly

admittedly there are occasional exceptions, like when you're reconfiguring the firewall or upgrading debian to a new release. though current configuration-as-code systems like docker and ansible go a long way to making all that stuff just as recoverable. the server went catatonic? too bad, revert the firewall rule change and reinstall it, and 45 seconds later the problem is fixed

by contrast, it's almost never obvious how to undo clicking on a command button or a menu item. even a dropdown selection is hard to undo: you have to remember what was previously selected

but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it

Trust me man, I know a few Concorde pilots and they sit in that cockpit and flip switches and the spin the controls such that the plane will glide like butter through a hurricane - while myself here is practically crash landing at every stop.

There is the chronic issue with skilled linux users where they keep flexing how good the terminal is (and lets be honest: flexing their fluidity and dexterity with it too) while completely missing the forest for the trees. The terminal sucks because it is difficult to use with an arduous learning curve.

There is a reason why Android, the most successful linux "distro" to the point at the summation of others is a rounding error, has no user terminal and a robust GUI. People don't even know it's linux. Thats what we need; an opensource linux distro that people don't even know is linux.

let's consider the possibility that people might disagree with you for reasons other than being dishonest. for example, i disagree with you because you're completely wrong on the facts, as i explained in my grandparent comment. unlike you, i'm not going to accuse you of dishonesty; possibly you are just ignorant (and aggressive) rather than mendacious

worse, though, you're using your ignorance to promote a vile ideology: the ideology of disempowering users in the name of ease of use. what you're advocating here is the strawman that people sometimes use to criticize guis: not powerful guis like excel, blender, solidworks, godot, photoshop, and autocad which empower users in ways that transcend the limitations of character-cell terminals, but glorified menu systems like mainstream android apps, which reduce users to passive consumers or machine operators

being a machine operator, manually telling a machine what to do over and over again, can be enjoyable and rewarding, as in riding a bicycle, driving a sports car, or your example of piloting a concorde (although you don't actually know any concorde pilots or you'd be aware there haven't been any concorde pilots in 20 years; interpreting you with extreme charity, perhaps you only meant this as a metaphorical explanation of what text-mode uis look like to you). but it must be voluntary, because it's an economically low-productivity activity; when you condemn people to be machine operators, you are condemning them to material poverty. bicycle messengers and taxi drivers do not have easy lives

computers permit people to automate machine operation, which enormously increases economic productivity. that's what we need. things like bash facilitate that, and things like android actively prevent it. good guis like godot's are in the first category, not the second

> but yeah having to read the manual and slowly piece together a working command or configuration file is definitely worse than having every option documented in the place where you choose it

That's where domain knowledge comes in. If you don't know anything about networking other than selecting the WiFi network and entering the password, you're going to have a hard time interacting with ip. If you don't know anything about codecs, ffmpeg will seem esoteric.

More often than not, in MacOS and the like, the GUI is reliable and there will be apps for not so common stuff. In Linux, the software (however complex) has already been written in CLI mode and works fine. Someone could do XLD or iTunes, but they're already happy with their ffmpeg scripts, and their MPD setups.

And the key to get there is to usually get a book about Linux at first, then learn about the software you are using.