It thought it would come naturally over time, but it never does. It seems needlessly cryptic and verbose in so many ways. I've started using LinqPad for stuff I would normally do in cmd now.
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".
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.
I need to reset my git repo to match origin, is it git reset hard --HEAD or git reset HEAD --hard?
I'm like 90% sure they switch it with every update.
Edit: To be more specific:
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.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.
Because the length is given in "bits". I get your point, but that's a terrible example! :-)
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!
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)
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.
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.
http://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_...
Also, they are pretty detailed, so it is somewhat time-consuming and complex to implement those guidelines in full.
We use powershell a lot at work for developer setup stuff and other common tasks we do on a daily basis and at this point I've considered just writing my own language to do it or find something else.
I wanted to learn Ruby a while back but didn't have a web project to work on so I started writing a load of scripts in Ruby instead. It worked out fine.
Don't know much Ruby or Python to be honest so I'm not sure how could I apply them but I'll dig around sometime soon.
That isn't much comforting. And frankly, MS always pushed Power Shell as a better way to do things than the ancient options for command line, thus color me disappointed that it couldn't be better than the "default choice" Bash.