3 ms·

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 h

by gumby 3y ago

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 3y ago
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 3y ago
  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 https://i.imgur.com/dxXwRzD.gifv
  - gumby 3y ago
    I don’t care if you have `git add` as long as you also have git-add, which is more easily scriptable and simply easier to use. The `git add’ approach always reminds me of using a mouse and a menu (ugh): select the git option, drag down until you get to the “add” subotion and then…. Supposedly that’s more “discoverable” and maybe it is, but you don’t need discoverability for the things you use every day!
- gumby 3y ago
  There are a lot of super useful "!" commands documented in the bash manual in the section entitled 'History Expansion' !! which you know runs the previous command in your history. It's just short for !-1 !123 runs the 123th command in your history !gi runs the most recent command in your history that begins with letters g and i !* is the args to the most recent command !$ is the last argument to the most recent command !:0 is argv[0] of the most recent command (i.e. the program name) These can be combined: !g:$ is the last argument to the most recent command that began with g They are also really handy in backquotes since you can do things like grep foo `!find | egrep .cc` because your find command was almost right Sometimes you can get away with a ^ substitution: git add foo.cc bar.cc oops ^add^reset There are a lot of such commands that let you use the basename of the argument etc. After a short while they are so automatic they are easier to type than the actual command name ("I just want to do that thing again but with this filename"). These have actually become so deeply wired that I had to think to write them down because I use them “without thinking”. So this is handy with normal commands: git-add foo.cc <do some stuff> !g:0 bar.h git-add foo.cc bar.cc <do some stuff... oh wait, I didn't mean to do this> git-reset !g:* But with subcommands, you end up matching against all the git operations; !* matches all the arguments to the `git` command including the subcommand so you can't conveniently say "yes, that last git command but I want to change the subcommand"
matheusmoreira 3y ago
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 3y ago
  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 3y ago
    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
- gumby 3y ago
  I answered a similar question above; here’s the link to my comment, with examples: https://news.ycombinator.com/item?id=38975420 https://news.ycombinator.com/item?id=38975420
olejorgenb 3y ago
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 3y ago
  I guess it's because !TEXT does a prefix search for TEXT in the history and TEXT can't contain spaces
- gumby 3y ago
  I answered a similar question above; here’s the link to my comment, with examples: https://news.ycombinator.com/item?id=38975420 https://news.ycombinator.com/item?id=38975420

by gumby 3y ago

rocky_raccoon 3y ago

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 3y ago
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 https://i.imgur.com/dxXwRzD.gifv
- gumby 3y ago
  I don’t care if you have `git add` as long as you also have git-add, which is more easily scriptable and simply easier to use. The `git add’ approach always reminds me of using a mouse and a menu (ugh): select the git option, drag down until you get to the “add” subotion and then…. Supposedly that’s more “discoverable” and maybe it is, but you don’t need discoverability for the things you use every day!
gumby 3y ago
There are a lot of super useful "!" commands documented in the bash manual in the section entitled 'History Expansion' !! which you know runs the previous command in your history. It's just short for !-1 !123 runs the 123th command in your history !gi runs the most recent command in your history that begins with letters g and i !* is the args to the most recent command !$ is the last argument to the most recent command !:0 is argv[0] of the most recent command (i.e. the program name) These can be combined: !g:$ is the last argument to the most recent command that began with g They are also really handy in backquotes since you can do things like grep foo `!find | egrep .cc` because your find command was almost right Sometimes you can get away with a ^ substitution: git add foo.cc bar.cc oops ^add^reset There are a lot of such commands that let you use the basename of the argument etc. After a short while they are so automatic they are easier to type than the actual command name ("I just want to do that thing again but with this filename"). These have actually become so deeply wired that I had to think to write them down because I use them “without thinking”. So this is handy with normal commands: git-add foo.cc <do some stuff> !g:0 bar.h git-add foo.cc bar.cc <do some stuff... oh wait, I didn't mean to do this> git-reset !g:* But with subcommands, you end up matching against all the git operations; !* matches all the arguments to the `git` command including the subcommand so you can't conveniently say "yes, that last git command but I want to change the subcommand"

matheusmoreira 3y ago

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 3y ago
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 3y ago
  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
gumby 3y ago
I answered a similar question above; here’s the link to my comment, with examples: https://news.ycombinator.com/item?id=38975420 https://news.ycombinator.com/item?id=38975420

olejorgenb 3y ago

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 3y ago
I guess it's because !TEXT does a prefix search for TEXT in the history and TEXT can't contain spaces
gumby 3y ago
I answered a similar question above; here’s the link to my comment, with examples: https://news.ycombinator.com/item?id=38975420 https://news.ycombinator.com/item?id=38975420