I've only been working professionally with linux for 5-ish years, but i'd say that i'm still at the "2 googles per command" number for bash.
Some of it stems from the fact that i just don't use it enough, but most of it from the fact that this shit just isn't intuitive. why is -b the flag for key length in ssh-keygen? Why is -v the flag for "don't include" in grep? I have those memorized now, but there is no way they are "intuitive".
Now that you've said that, i'll never forget it again (although what the hell does -t stand for then?)
But the point is that even though it's most likely "my fault" for not reading the manual correctly (i'm not saying you were implying that, but often i do feel that it's ultimately because of my laziness that i have these problems), they aren't "intuitive" in the sense that that you can just pick it up and go.
The one thing my "dream linux" system would borrow from powershell is the tab-completion for flags and sub-commands.
If i could type `git ` and hit tab and see a list of what is possible (with a quick one-sentence explanation of that sub-command) it would completely turn my experience around.
But even that takes "domain knowledge" that tab auto-completes... This stuff is hard!
> Now that you've said that, i'll never forget it again (although what the hell does -t stand for then?)
The "type" of key. :D
It would be nice to have a more fully featured auto-complete and it is feasible to do. I'd hope that it's the kind of thing that gnu-utils could get a standard for that other tools could just provide a completion script, rather than each shell having to do its own. Maybe someone's already working on it.
>The one thing my "dream linux" system would borrow from powershell is the tab-completion for flags and sub-commands
You might want to check out some alternative shells: The fish shell does this out of the box, it's really nice. For something more bash-like, I think zsh can too (but you might have to set it up in a config file)
As user yread said, it's for inVert (the sense of the pattern match, from "matches" to "does not match"). You're right, it is non-intuitive.
One of the issues is that when you use single letter options, a particular letter could potentially stand more than one expanded word, e.g. in the case of v, it is more commonly used for Verbose or Version. Even there, it varies. Some commands use -v for version, others use -V (e.g. python does), and some use --version.
GNU's long option format is a partial solution to that, but involves more typing. E.g. --verbose or --version or --invert. Also the command lines get longer then. No perfect solution as of now.
You're right, over the years, with more and more people creating commands, and with no well-defined standard in the earlier years at least, the whole scene of command line tool names and options has become something of a mess. Later one some sort of standards and conventions have been created or evolved, informally, but not many command creators necessarily follow them.
> Some of it stems from the fact that i just don't use it enough, but most of it from the fact that this shit just isn't intuitive.
I have exactly the same problem.
I use Linux since about 8 years but somehow I just don't use the commandline very often so I forget stuff all the time. Because of this I have half a dozen post-its glued to my monitor for all the grep/git/whatever tricks I just can't keep in my head. And for other stuff I use about once a year I have a long linux_tricks.txt on my desktop where I write down all the tricky and obscure command line stuff.
If you're interested in getting past this stage of learning the Linux/Bash environment, I'd recommend reading man pages.
I worked with someone who introduced me to this approach, and at first I was like "I'll just Google it again and get on with my life," but once I forced my way through a couple of them it's really opened my eyes and changed the way I use the tools available.
ls has enough options to spell most people's names (capitalization included), and a lot of grep pipelines can be replaced with options passed to grep. It turns out that we're almost always doing things the hard way or reinventing the wheel.
git # the executable
reset # the operation
--hard # the type of reset being done (hard reset)
HEAD # where to reset *to*. Defaults to HEAD if not specified.
You can just leave out HEAD since it is implied, but understanding a little bit about git, like what the head is supposed to be, would probably help you.
I don't see anything illogical in fg bg ls cd mkdir cp rm man ... Perhaps a little cryptic, but it's just mnemonics. Not to mention that short names are very convenient in a text-based shell.
