[copperx]

It's almost like typing commands isn't the friendliest human-computer interface. But because we have been utterly incapable of taking the Unix paradigm to the graphical world, we have settled for the error-prone, zero-discoverability atrocity of a command line.

Don't get me wrong, I love the command line because there isn't a more powerful interface, but I'm appalled to see that there aren't any attempts to make it better. 70 years isn't enough to come up with something better?

[bunderbunder]

It's a combination of the command line itself, and the actual command line apps.

For me, this is the single biggest use case for thefuck:

  $ git push
    fatal: The current branch my-branch-name has no upstream branch.
    To push the current branch and set the remote as upstream, use

      git push --set-upstream origin my-branch-name

  $ fuck
    git push --set-upstream origin my-branch-name [enter/↑/↓/ctrl+c]

  (enter)

I'm pretty unrepentant about that one - I _could_ waste brain cells on keeping track of whether my branch already exists upstream, and I _could_ waste keystrokes typing out the more verbose command myself. But I'm not gonna. Life's too short.

[tejasmanohar]

Same here, but then, I just ran the following and branches are now auto-created

    git config --global push.default current

[singingboyo]

Admittedly this isn't a concern for all repo setups, but what about the odd time you don't actually want to autocreate a branch?

Saying/typing fuck won't help you now! Basically, thefuck does give some friction and force you to think about things - not much, but maybe just enough.

[BonesJustice]

From the examples, it looks like you’re given an interactive list of ‘corrected’ commands to cycle through, and it won’t proceed until you hit <enter>.

So if you don’t want to do what it suggests, just bail out.

[vvilliam0]

Tab autocomplete works nicely when configured

[noobermin]

CLI is like speech. Therefore, I don't get for why people think it isn't a friendly human computer interface since it is so close to the original human-human interface. And just like with speech, things can be ambiguous and easily mistook. The way we've dealt with speaking is just learning to speak clearer, not by turning everything we say into a movie.

[copperx]

> CLI is like speech.

You must be kidding here. CLI is like speech only if imagine you are in a completely dark room full of people, and you can't talk to anyone unless you know their name and their job description, and although you can get a list of names, you need to figure out the job descriptions yourself.

On top of all that, everyone speaks a slightly different dialects, the adjectives and verbs are slightly out of order. And although that's not hard to memorize, you have to speak flawlessly in order to be understood.

[noobermin]

Hmm? Apart from the "dark room" bit, how is it not analogous? "Get the bag of chips." Who? Which bag of chips? What is the context?

If there is a special context say, there is only one person and one bag of chips, which is similar to there being one file and one program to open it with certain options say, and you do it often enough, an apt shell user would bake that into either an alias or a short shell script. It's rare that I use more than 4 options on a command before baking it into a script. That's very analogous to language: things like slang, contractions, and sayings that make sense in certain contexts form naturally between people or even in some situations, are decided explicitly.

Of course, come times of ambiguity, then you have to explain yourself, just like when a script you usually use as a shortcut doesn't match a certain need, and you crack open the original call, which man helps with, and may be you write another script if need be.

[loa-in-backup]

That's entirely not true, the shell remembers a lot for you, the current state and the execution of commands can depend in any measure on environment variables and set them, also current directory and time of day, calling script, current history, the name used to call the script (if it has many links), your current line of input (in autocompletion handler).

The shell can also indicate it's state however you want - synchronously, asynchronously, before every input (PS1, PS2, etc.)

[LiterallyDoge]

Mostly because when you forget to put a ./ in a conversation with me I don't burn your house down.

[noobermin]

Alright, so I want to be careful here, because what I'm going to say will come off as elitist, and it is in a way, but it's helpful because it demonstrates why some of us don't feel the way many of you do, and how you can feel more comfortable if not productive in the shell.

Many of us who work extensively in the shell simply use best practices and hacks in order to not worry or deal with the problems that many of the people in the replies to my comment are expressing. One is "too many options" another, like yours, is "foo" will write zeroes to my drive, if I don't properly include the path. Another is "humans are more understanding of ambiguity" which ignores the myriad times humans do not understand ambiguity. (that said, of course humans understand ambiguity more than computers).

For the too many options, learn to use alias or scripts. The reason for 90 options in commands is not for humans, who can't process more than 5 items simultaneously in the mind's working memory. It's for being able to craft scripts that you can use can use for cases that suit you. Of course, it helps to memorize a couple, but I don't think anyone expects any normal user to remember all of mplayer's options. That's what man is for.

For the ./ bit, there's a reason that . is not in your path. There's a reason there's a path in the first place and it's to avoid doing things you'd rather not. If you worry about being having scripts you write being mistaken based on the path, there is a very smart fix for that, don't name your scripts things like delete,rm,dd,unlink,mount, etc that can be mistaken for commands elsewhere. If you use scripts, best to append an ending to them (.py for python scripts, even .sh for shell scripts although I admit I don't do this) so you can distinguish them. That way, when you try to run doit.py, it won't accidentally doit, at worse, it will complain about not knowing what doit is.

A lot of these bits I learned just by using the terminal. May be there are classes out there, which is great too. Regardless, understand that CLI's have existed for decades and people are extremely proficient in them, and it has nothing to do with people being smarter or more elite than others, they just have practice. The same can be said for any profession, be it carpentering, repairing cars, or selling and presenting. Of course, CLIs can always be improved, but don't discount them completely. There is a reason they have persisted, it's not merely tradition and intertia.

[LiterallyDoge]

I love the command line for some things and would never trade it, but like anything, I believe it's about using the right tool for the job, and frequently, humans work well with shiny gadgets over memorizing spells.

[cpmsmith]

We've also dealt with it by being extremely flexible, error-tolerant, and context-aware on the parsing end.

[IanCal]

> I don't get for why people think it isn't a friendly human computer interface

Because the human is not friendly and has near 0 margin for error.

> The way we've dealt with speaking is just learning to speak clearer,

No, the way we've dealt with that is also to understand less clear speech.

Doo u undrstnd mi? None of those words were even actually correct yet I imagine most people had a good guess at what I said.

An unfriendly human interface that acts like many CLIs:

Hello I'd like a burger

NOT UNDERSTOOD I'D

Hello, can I have a burger?

NOT UNDERSTOOD CAN

Hello, burger?

ERROR ITEM BURGER NOT FOUND

Hello, cheese burger please

Good evening sir, thank you for placing your order.

[loa-in-backup]

How about

man 6 mcrestaurant

mcrestaurant offers... cheese burgers

[whateveruser]

Every time this point comes up, ultimate conclusion isn't the CLI is bad or can't be improved, but the VT220 and similar emulation that's holding things back. Any person who has developed a terminal emulator can attest to that. There have been and are attempts at a much better CLI, but until we drop the legacy baggage, we can't have nicer things, at least in a sane way. But if we do that, we don't really have enough incentive to use the newer tools. Its a catch 22 after all.

[xte]

Mh, did you ever tried modern shell like zsh or fish, with a reasonable config? Or even better, despite a bit steep learning curve, eshell (Emacs) if you already know Emacs and elisp a bit or xonsh if you are already familiar with Python.

As an Emacs (EXWM) user I agree that pure CLI is limited and pure text-based interfaces without terminal emulators limits are far superior but... Well, today outside Emacs we only have CLIs, the rest is so limited and limiting that can be used only for desktop end-user stuff. Even Microsoft Windows mandate CLI for serious system use/management...

[vokep]

Sounds like someone needs to just Do it.

[tenebrisalietum]

> zero-discoverability

Is your TAB key broken?

Do the letters `ls` and `grep` not work on your keyboard?

[ikfmpwdsoz]

To be fair, tab helps you discover commands about as well as a dictionary helps you discover words. I'm personally looking for something like apropos, but much more powerful.

[julvo]

Closest I could think of would be 'man -k', but a apropos would be cool

[another-cuppa]

Tab completion makes it significantly better. It's a bit like syntax highlighting. If it doesn't tab complete properly then something is probably wrong.

[noobermin]

It's funny but tab completion makes CLIs a completely different experience. That and (yes) insert mode. If you've ever dealt without either it becomes much more of an exercise in precision and patience.