The command line is a bicycle skills. Any programmer should learn it.
Maybe it's because the default black background makes it feel like we're throwing our commands into a "magical pit inside the computer", and waiting for the output, which will be an error unless the commands were perfect. That perspective is unpleasant.
Maybe it would be helpful to visualize a GUI while using the command line, where instead of clicking on a menu or button, you have to type its name.
(having said that, with unix you can be extremly productive and it is (more or less) designed to be easily understood once you grasp some concepts.)
It's very similar to many mainframe interfaces with non-intuitive commands. Many legacy IT departments have these. Questions like "How do I do X?" have answers from experts like "Type XKY= and then hit PF3". But that sequence of steps is nowhere on the current screen's list of commands, or in it's help documentation. You just need to know it.
This is in contrast to a GUI where every single thing you can do (aside from keyboard shortcuts) is visible. I can hit a random button and see what happens. In a CLI, there are too many possible alphanumeric strings to try, so I can't do the same thing.
(This is of course different if the prompt is not blank, and says "Type 'help' for help")
Recent shells have done good efforts to provides some kind of typing and deduction to reduce friction. It's always nice to have a listing of /etc/hosts or ssh known hosts in place. Browsers picked this since the coming of 'smart' url-bars.
I hope one day we would go all-alan-kay on this and simply have a meta-capable system that parse/cache relevant data straight from the source so you don't need to do any extra work to make the system understand a bit your additions.
Yes. Very yes. To the point where, when you say "some people", what you really mean is "most people".
I don't think the problem is "the command line" so much as it is "the Unix command line". You don't see a lot of people having difficulty with text-adventure command lines. You demonstrate HELP and GET LAMP and they're off to the races.
Whereas Unix commands are hard to discover unless you already know their names, have illogical names, have inconsistent behaviors, have poorly designed documentation (every command has 27 options and they're often documented in alphabetical order on man pages, with the obscure corner-case options given equal weight to the most useful ones), require combinatoric thinking (because many options can be used at one time), take invisible actions ("gzip foo" returns no output and modifies a file in your current directory; you need "ls" to see that it did anything), are context-dependent (you need to know what a "working directory" is or you won't get past square one), and often require a working knowledge of pipes and redirection to be useful (and pipes and redirection aren't intuitive skills).
You need to read a book. Nobody has time to read books. Reading books is a bicycle activity.
> get file.txt
YOU PICK UP THE FILE
> inventory
YOU ARE HOLDING:
file.txt
> gzip file.txt
FILE.TXT HAS BEEN COMPRESSED
> inventory
YOU ARE HOLDING:
file.txt (compressed)
> drop file.txt
YOU CAN'T PUT THAT HERE, THERE IS ALREADY A FILE.TXT HERE
> rename file.txt file.txt.gz
FILE.TXT HAS BEEN RENAMED
> drop file.txt.gz
YOU PUT DOWN FILE.TXT.GZ
OK: you can get file.txt; gzip file.txt; rename file.txt file.txt.gz; drop file.txt.gz. However, it requires a get and a drop to fiddle the inventory, which doesn't seem to do anything (you are still specifying all the filenames each time).
And I don't see a reason to generate a gzipped file of 'the same name' and then do a rename, it seems better for the new name to be an argument to the gzip operation.
All you really want is to send information from file.txt through gzip to file.txt.gz. As in "gzip < file.txt > file.txt.gz" or "cat file.txt | gzip > file.txt.gz".
But it feels like there should be cases where the clipboard/temporary holding area is much more useful than it is here, I just can't think of them?
MPW also allowed you to differentiate between target and command windows very easily, so you could keep your favorite commands handy and have the output funneled to other views.
Not Lighttable, but a lot more useful than man pages in 99% of cases and pretty darn nice.
It's tough.
Edit: I wanted to add a few more comments.
Someone mentioned scriptability, also composability, speed, "multitaskability".
For me personally, not just tasks I do when programming, but almost anything I do on a computer. The graphical display capabilities are merely a way of displaying content for me (PDFs, web-pages, etc.).
Obviously, if you're dealing with graphical content you want a GUI though.
For two different directories,
find all duplicate files that are
both less than 10 minutes old
I'm not accomplished with GUI tools, but I'd be interested to know how this would be done via a GUI.
You take this as evidence that it can be done from a GUI?
So, let's go back to your comment. You said:
I still haven't found a tool which
doesn't have an equivalent GUI.
Given two directories,
find all duplicate files that are
both less than 10 minutes old
$A/$f is less than 10 minutes old
$B/$f is less than 10 minutes old
$A/$f is identical to $B/$f