7 ms·

Problem is it doesn't scale well for people. Imagine if everything you did in slack was via CLI - there are dozens, hundreds of commands to learn? Imagine if ev

by sxates 8y ago

Problem is it doesn't scale well for people. Imagine if everything you did in slack was via CLI - there are dozens, hundreds of commands to learn? Imagine if every app had dozens of commands you had to learn and memorize. Sure you could do it and be blazing fast, but that's a really steep learning curve a lot of users wouldn't adopt.

sjmulder 8y ago
What you need then is a compact overview of what is available, like `man intro`, and something like `apropos`.
chris_mc 8y ago
Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote <tab>`, a listing shows all of the possible commands, such as `add` or whatever. Just make the console smarter, _with good algorithms that aren't slow_, and people would use it a lot more.
- seanmcdirmid 8y ago
  Isn’t that just apropos?
- westoncb 8y ago
  I've been wondering this for years. It seems like the most obvious way to greatly improve CLIs, yet no one seems to talk about it...
  - sorahn 8y ago
    Check out Fish Shell.
    - eikenberry 8y ago
      Zsh can also do this.
      - NegativeLatency 8y ago
        But it needs plugins, fish has it builtin. Nothing to configure
        sorahn 8y ago
        Yup this. If I wanted to carry around a bag of plugins all day, I'd just use bash.
        meowface 8y ago
        On the plus side, by picking and choosing what you want, you can get the precise performance and usability ratio that fits you best. Fish is a great shell but nothing beats the zsh plugin ecosystem.
        NegativeLatency 8y ago
        Or in my case: spend a bunch of time messing with and tweaking my shell config. Sometimes the tyranny of default options is helpful to getting things done.
        rtisdale 8y ago
        I’ve tried fish shell a few times and ended up preferring ZSH. To my understanding Fish shell doesn’t have complete BASH compatibility and it breaks many scripts. It also doesn’t seem to have nearly as wide of an adoption as ZSH so less overall community support in genera. Sure you can just specify the interpreter with hash bang but it’s something worth noting before considering a switch.
        tomaskafka 8y ago
  - gumby 8y ago
    Gosh TOPS-20 had this back in the early 1980s (and this is why bash has readline...)
    - DonHopkins 8y ago
      Yet there's no standard way for system and user programs to expose their parameters and help to the command line, like most TOPS-20 programs did. So bash's completion and help facilities pale in comparison.
      - gumby 8y ago
        Indeed Don, why don't you extend gnu getopt to generate a special ELF section with an argument grammar and then modify bash to load this section? Shouldn't take too long and then this feature would become automatic!
        DonHopkins 8y ago
        Accessibility demands Tourette Syndrome Compatible noise word support.
        gumby 8y ago
        I am sure that can be controlled by $LOCALE
      - jodrellblank 8y ago
        PowerShell has this; all cmdlet parameters are parsed by the PowerShell environment, so you don't have to write argument parsing code over and over; parameters to cmdlets are a standard form with many using the same common names where it makes sense. Because of that design they are long and readable words but tab completable, and ctrl-space will bring up a menu of available matches starting with what you've typed so far.
  - deleted 8y ago
    [deleted]
- erikbye 8y ago
  I've been working this way in my shell for a couple of decades.
- int0x80 8y ago
  bash has this too.
- DonHopkins 8y ago
  TENEX and TOPS-20 (TWENEX) had a command line with built-in escape recognition, noise words and help, which most system and user programs supported. http://tenex.opost.com/hbook.html http://tenex.opost.com/hbook.html User-oriented Design Philosophy A piece of system design "philosophy" had emerged at BBN and among some of the ARPA research sites that was to have a large impact on the overall feel of TENEX and, ultimately, TOPS-20. At the time, we called this "human engineering" -- we wanted the system to be easy to learn and easy to use, and we wanted the system to take care of as many grungy details as possible so that the programmer or user did not have to deal with them. Beyond that, we were willing to spend real machine cycles and real (or at least virtual) memory to make this happen. This philosophy led initially to the human interface features of the EXEC, including "escape recognition", the question-mark help facility, optional subcommands, and "noise" words. Few people now argue against the need to provide effective human interfaces, but at that time there were many detractors who felt that it was a waste of cycles to do such things as command recognition. These kinds of things, they said, would "slow the system down" and prevent "useful work" from getting done. Other contemporary systems used short, often one-letter, commands and command arguments, provided no on-line help, and did not give any response to the user other than the "answer" (if any) to the command that had been entered. [...] Escape Recognition, Noise Words, Help One of the most favored features among TOPS-20 users, and one most identified with TOPS-20 itself, is "escape recognition". With this, the user can often get the system to, in effect, type most of a command or symbolic name. The feature is more easily used than described; nonetheless, a brief description follows to aid in understanding the development of it. A Brief Description of Recognition and Help Typing the escape key says to the system, "if you know what I mean from what I've typed up to this point, type whatever comes next just as if I had typed it". What is displayed on the screen or typescript looks just as if the user typed it, but of course, the system types it much faster. For example, if the user types DIR and escape, the system will continue the line to make it read DIRECTORY. [...] Question-mark Help Finally, if the user still isn't sure what input comes next in a command, he types question-mark, and the system will provide a list of choices that are legal at that point. The list includes specific keywords (e.g. FILE, DIRECTORY) and generic descriptions (e.g. "input file") Most importantly, the question-mark request does not destroy the previous command input. After the list of alternatives is displayed, the partial command is redisplayed, and input continues from the point just before where the user typed question mark. As a result of this feature: Users never have to go grab a manual and search around trying to find the name of a forgotten reserved word (command or parameter). This eliminates the "I know a word, can you guess it" aspect of many computer interfaces. The user can often figure out from the choice of parameters what an unfamiliar command or option will do. This further eliminates laborious searching of manuals. Because the context of the current command is not lost when help is requested, the user can go step-by-step through a command, figuring out each field in turn. In systems where getting help is a command itself, the user may have to write down a long unfamiliar command on a piece of paper in order to be able to enter it completely. As menu-oriented interfaces have become more widely used, the advantage of having all choices visible to the user has become obvious. The question-mark help feature can, in retrospect, be seen as a "menu on demand" kind of approach, and it was one that worked even on terminals too slow to support full menu-based interfaces. Origin of Recognition The Berkeley Timesharing system for the SDS-940 had an earlier form of recognition. It didn't use escape however. On that system, recognition was automatic; whenever the user had typed enough to unambigiously identify a command or symbolic name, the system would spring to life and type the rest of it. This made for the minimum keystrokes in the ideal case, but had one major, and ultimately fatal, problem: if the user typed too much in one field, i.e. more than the amount necessary for the system to recognize that field, the input would go into the next field where it wasn't intended. For example, the system would recognize COP as sufficient for COPY and supply the "Y". But if you typed the whole verb, you would get: * COPY Y | |- typed by the computer Then, you would at least have to erase the extra "Y". If you didn't notice what happened and continued to type the remainder of the command, what you had intended as: * COPY OLDFIL NEWFIL would come out as * COPY Y OLDFIL NEWFIL This would at least produce an error, and in pathological cases could do major damage. [In the foregoing example, note that the old file name winds up in the new file parameter field.] [...]
- b0rsuk 8y ago
  You achieve this by putting the following 4 lines in your $HOME/.inputrc file: "\e[A": history-search-backward "\e[B": history-search-forward set show-all-if-ambiguous on set completion-ignore-case on From now on, when you type part of a command, uparrow and downarrow provide you with incremental search based on your command history.
0x445442 8y ago
Actually natural language scales quite well. Aza Raskin and his father Jeff did a lot of good work in this area. The discoverability of commands in a system like Emacs is much more powerful than a menu based system. In fact, I bet most people navigate the web now days by typing part of the URL in the omni bar and letting the browser fuzzy match versus mainting large bookmark lists.
- ssorallen 8y ago
  I’m accustomed to typing “s” for StackOverflow, “g” for GitHub, “gm” for Gmail, and probably several others I don’t even realize. This sort of “smart” / reachable interface seems like an improvement over having to type entire words over and over. Is there a terminal with similar ability?
  - akx 8y ago
    Fish's abbr feature does this. They're aliases that expand in place. For example I have gph abbr'd to "git push origin HEAD", and I can continue editing the command after expansion.
    - pbhjpbhj 8y ago
      Is there a way to expand special commands (and optionally aliases) in BASH without executing them. Like if I put `ll !$` it would show, say, `ls -al /home/user/downloads` on a new line. I'd love tab style completion that offered explicit history as well as standard completions. So if I `find` and then press the completion key-combo I get a list of the last 10 unique find commands (and I can choose one and edit before running).
      - 0x445442 8y ago
        This may be possible with fzf but I'm not sure of all the features it's capable of. This type of behavior would be a great addition to the terminal or popular shells. Instead of having the command prompt always display at the end of output, have it stay in the same place at the top or bottom. Something like you get with the Emacs mini-buffer with tools like helm but for the terminal.
weinzierl 8y ago
I agree about the learning curve but not about your point that it doesn't scale. I, and many people I know from my generation that basically live in a command line environment (including often vim) know thousands of commands and their options by heart. It's like another language. At some point you are fluent and coming up with the right commands and options is effortless. The challenge becomes being efficient and elegant. Even then you learn about knew tools or options regularly and it's not a problem. It's much like with a natural language, there is no point were you stop learning new words.

by sxates 8y ago

sjmulder 8y ago

What you need then is a compact overview of what is available, like `man intro`, and something like `apropos`.

chris_mc 8y ago

Look at the VSCODE command bar. You start to type what you want to do, and the search function is incredible, helping you find any command you want. Why couldn't something simple like that be applied to the command line interface for a shell maybe? Heck, with `zsh` I have a lot of autocomplete commands available, including several sub-commands and sub-sub commands. For example, when I type `git remote <tab>`, a listing shows all of the possible commands, such as `add` or whatever. Just make the console smarter, _with good algorithms that aren't slow_, and people would use it a lot more.

seanmcdirmid 8y ago
Isn’t that just apropos?
westoncb 8y ago
I've been wondering this for years. It seems like the most obvious way to greatly improve CLIs, yet no one seems to talk about it...
- sorahn 8y ago
  Check out Fish Shell.
  - eikenberry 8y ago
    Zsh can also do this.
    - NegativeLatency 8y ago
      But it needs plugins, fish has it builtin. Nothing to configure
      - sorahn 8y ago
        Yup this. If I wanted to carry around a bag of plugins all day, I'd just use bash.
        meowface 8y ago
        On the plus side, by picking and choosing what you want, you can get the precise performance and usability ratio that fits you best. Fish is a great shell but nothing beats the zsh plugin ecosystem.
        NegativeLatency 8y ago
        Or in my case: spend a bunch of time messing with and tweaking my shell config. Sometimes the tyranny of default options is helpful to getting things done.
      - rtisdale 8y ago
        I’ve tried fish shell a few times and ended up preferring ZSH. To my understanding Fish shell doesn’t have complete BASH compatibility and it breaks many scripts. It also doesn’t seem to have nearly as wide of an adoption as ZSH so less overall community support in genera. Sure you can just specify the interpreter with hash bang but it’s something worth noting before considering a switch.
        tomaskafka 8y ago
- gumby 8y ago
  Gosh TOPS-20 had this back in the early 1980s (and this is why bash has readline...)
  - DonHopkins 8y ago
    Yet there's no standard way for system and user programs to expose their parameters and help to the command line, like most TOPS-20 programs did. So bash's completion and help facilities pale in comparison.
    - gumby 8y ago
      Indeed Don, why don't you extend gnu getopt to generate a special ELF section with an argument grammar and then modify bash to load this section? Shouldn't take too long and then this feature would become automatic!
      - DonHopkins 8y ago
        Accessibility demands Tourette Syndrome Compatible noise word support.
        gumby 8y ago
        I am sure that can be controlled by $LOCALE
    - jodrellblank 8y ago
      PowerShell has this; all cmdlet parameters are parsed by the PowerShell environment, so you don't have to write argument parsing code over and over; parameters to cmdlets are a standard form with many using the same common names where it makes sense. Because of that design they are long and readable words but tab completable, and ctrl-space will bring up a menu of available matches starting with what you've typed so far.
- deleted 8y ago
  [deleted]
erikbye 8y ago
I've been working this way in my shell for a couple of decades.
int0x80 8y ago
bash has this too.
DonHopkins 8y ago
TENEX and TOPS-20 (TWENEX) had a command line with built-in escape recognition, noise words and help, which most system and user programs supported. http://tenex.opost.com/hbook.html http://tenex.opost.com/hbook.html User-oriented Design Philosophy A piece of system design "philosophy" had emerged at BBN and among some of the ARPA research sites that was to have a large impact on the overall feel of TENEX and, ultimately, TOPS-20. At the time, we called this "human engineering" -- we wanted the system to be easy to learn and easy to use, and we wanted the system to take care of as many grungy details as possible so that the programmer or user did not have to deal with them. Beyond that, we were willing to spend real machine cycles and real (or at least virtual) memory to make this happen. This philosophy led initially to the human interface features of the EXEC, including "escape recognition", the question-mark help facility, optional subcommands, and "noise" words. Few people now argue against the need to provide effective human interfaces, but at that time there were many detractors who felt that it was a waste of cycles to do such things as command recognition. These kinds of things, they said, would "slow the system down" and prevent "useful work" from getting done. Other contemporary systems used short, often one-letter, commands and command arguments, provided no on-line help, and did not give any response to the user other than the "answer" (if any) to the command that had been entered. [...] Escape Recognition, Noise Words, Help One of the most favored features among TOPS-20 users, and one most identified with TOPS-20 itself, is "escape recognition". With this, the user can often get the system to, in effect, type most of a command or symbolic name. The feature is more easily used than described; nonetheless, a brief description follows to aid in understanding the development of it. A Brief Description of Recognition and Help Typing the escape key says to the system, "if you know what I mean from what I've typed up to this point, type whatever comes next just as if I had typed it". What is displayed on the screen or typescript looks just as if the user typed it, but of course, the system types it much faster. For example, if the user types DIR and escape, the system will continue the line to make it read DIRECTORY. [...] Question-mark Help Finally, if the user still isn't sure what input comes next in a command, he types question-mark, and the system will provide a list of choices that are legal at that point. The list includes specific keywords (e.g. FILE, DIRECTORY) and generic descriptions (e.g. "input file") Most importantly, the question-mark request does not destroy the previous command input. After the list of alternatives is displayed, the partial command is redisplayed, and input continues from the point just before where the user typed question mark. As a result of this feature: Users never have to go grab a manual and search around trying to find the name of a forgotten reserved word (command or parameter). This eliminates the "I know a word, can you guess it" aspect of many computer interfaces. The user can often figure out from the choice of parameters what an unfamiliar command or option will do. This further eliminates laborious searching of manuals. Because the context of the current command is not lost when help is requested, the user can go step-by-step through a command, figuring out each field in turn. In systems where getting help is a command itself, the user may have to write down a long unfamiliar command on a piece of paper in order to be able to enter it completely. As menu-oriented interfaces have become more widely used, the advantage of having all choices visible to the user has become obvious. The question-mark help feature can, in retrospect, be seen as a "menu on demand" kind of approach, and it was one that worked even on terminals too slow to support full menu-based interfaces. Origin of Recognition The Berkeley Timesharing system for the SDS-940 had an earlier form of recognition. It didn't use escape however. On that system, recognition was automatic; whenever the user had typed enough to unambigiously identify a command or symbolic name, the system would spring to life and type the rest of it. This made for the minimum keystrokes in the ideal case, but had one major, and ultimately fatal, problem: if the user typed too much in one field, i.e. more than the amount necessary for the system to recognize that field, the input would go into the next field where it wasn't intended. For example, the system would recognize COP as sufficient for COPY and supply the "Y". But if you typed the whole verb, you would get: * COPY Y | |- typed by the computer Then, you would at least have to erase the extra "Y". If you didn't notice what happened and continued to type the remainder of the command, what you had intended as: * COPY OLDFIL NEWFIL would come out as * COPY Y OLDFIL NEWFIL This would at least produce an error, and in pathological cases could do major damage. [In the foregoing example, note that the old file name winds up in the new file parameter field.] [...]
b0rsuk 8y ago
You achieve this by putting the following 4 lines in your $HOME/.inputrc file: "\e[A": history-search-backward "\e[B": history-search-forward set show-all-if-ambiguous on set completion-ignore-case on From now on, when you type part of a command, uparrow and downarrow provide you with incremental search based on your command history.

0x445442 8y ago

Actually natural language scales quite well. Aza Raskin and his father Jeff did a lot of good work in this area. The discoverability of commands in a system like Emacs is much more powerful than a menu based system. In fact, I bet most people navigate the web now days by typing part of the URL in the omni bar and letting the browser fuzzy match versus mainting large bookmark lists.

ssorallen 8y ago
I’m accustomed to typing “s” for StackOverflow, “g” for GitHub, “gm” for Gmail, and probably several others I don’t even realize. This sort of “smart” / reachable interface seems like an improvement over having to type entire words over and over. Is there a terminal with similar ability?
- akx 8y ago
  Fish's abbr feature does this. They're aliases that expand in place. For example I have gph abbr'd to "git push origin HEAD", and I can continue editing the command after expansion.
  - pbhjpbhj 8y ago
    Is there a way to expand special commands (and optionally aliases) in BASH without executing them. Like if I put `ll !$` it would show, say, `ls -al /home/user/downloads` on a new line. I'd love tab style completion that offered explicit history as well as standard completions. So if I `find` and then press the completion key-combo I get a list of the last 10 unique find commands (and I can choose one and edit before running).
    - 0x445442 8y ago
      This may be possible with fzf but I'm not sure of all the features it's capable of. This type of behavior would be a great addition to the terminal or popular shells. Instead of having the command prompt always display at the end of output, have it stay in the same place at the top or bottom. Something like you get with the Emacs mini-buffer with tools like helm but for the terminal.

weinzierl 8y ago

I agree about the learning curve but not about your point that it doesn't scale. I, and many people I know from my generation that basically live in a command line environment (including often vim) know thousands of commands and their options by heart. It's like another language. At some point you are fluent and coming up with the right commands and options is effortless. The challenge becomes being efficient and elegant. Even then you learn about knew tools or options regularly and it's not a problem. It's much like with a natural language, there is no point were you stop learning new words.