Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.
Or I could open up my GUI, click "work" from my side nav selections and navigate through 2015/08/24/important/ and click my file to open it. I can even open two directories and ^x^v into another directory. Or drag/drop to move. Rather than "mv file.txt ../../25/file.txt"
I think it's important to show the more "cool" stuff you can do from CLI. Once you have them interested, explain the building blocks for how they can get there.
Explaining the building blocks to someone who doesn't see the benefits of the CLI will have them thinking about trivial problems and wonder why anyone would ever choose to use the CLI when the GUI is so much faster/easier/less memorization. When I was taught pwd/ls/cp/mv all I could ask myself is "....why? GUI is faster/easier/less memorization/no typos wasting time".
[0] To be fair, I can autocomplete a lot of that command. GUI is still faster though. "cd/us[tab]/N[tab]/doc[tab]/wo[tab]/2015/08/24/i[tab]/fi[tab].txt"
To me the killer argument for cli is composability, combined with the cli history.
Most of us do a lot of things repeatedly, day in day out. For example I have to download one of the last files from an ftp server, open it, process it in some way, and possibly get some other files based on what's in the first file.
It's reasonable enough from the command line. But some of the operations are chainable with pipes, and all of them can be in a short shell script, so I only have to enter the one script name to get the whole thing done.
And it's in my cli history, so I only have to recall it, and change usually just one parameter.
I think I'd be hard pressed to do that from a gui. for one, I don't think there's a gui history. And how do you chain gui commands together? And then alter them with parameters?
"Write a $LANGUAGE script that you can double click on." Yes, but that's a higher barrier to entry, and it's in a completely different "language" than the gui language that you were working in when you discovered a series of tasks that you repeat. With a shell script you just pull together what you've already been doing, in the format that you've been doing it.
And then compose the shell script you wrote with other shell scripts that you wrote. Etc.
I double click on things too, and somethings it's merely a matter of whether I have my hand on the mouse or the keyboard. Not bashing gui's (pun intended).
Composability.
Composability.
Some automation tool like (osx) Keyboard Maestro is pretty good for these kinds of things. Just started playing with it the last couple of weeks but it is very powerful.
I use CLI automation as well quite a lot.
It's significantly faster (at least for me and most people I know) to type "cd ~/relevant-symlink" than it is to take my hands off the keyboard, switch to the mouse, and then go back to home row.
Seriously, if you have 'work' as a side nav, then you could have it as a symlink, which makes it about the same. But it's really the stuff like looping over operations, or rsync over ssh, etc that make reading & writing a bit more awesome than point & grunt.
As for symlinks, it's a fair point. But even typing the rest of that example it would be faster for me to use a GUI.
I agree on that point. CLI is much better for less trivial tasks - or making a trivial task possible. On Windows renaming files is bad, ending with an (n) structure. Where I want "file_1.txt, file_2.txt I get file (1).txt, file (2).txt. Or if I save a bunch of .jpf instead of .jpg I have to use the CLI to fix the extensions because it isn't possible in Windows otherwise.
But you won't convince a lot of people to use CLI if you're introducing them to pwd/ls/mv/cp instead of |'s, grep, scripting, etc.
I'm routinely tempted to alias `cd` to something that will open the file in $EDITOR, if I type `cd <a path to a file>`.
It's much simpler to move your mouse and click once than to use cd + ls. (Never-mind the fact that half the time I go to use ll and oops, this is a super-user so none of my aliases work.)
OTOH, if you're always moving files from /stage to /live or /db to /backup, CLI is more efficient, particularly once you write a script to capture what you need to do.
GUI also comes out on top for anything where the CLI ends up just being a mock-GUI. For example, on OS X, there's no reason to use top instead of Activity Monitor, since they do the same thing, and AM lets you click the column headers to re-order things. Also, I know people love vim/emacs, but those are both better as GUIs than as pure-terminal programs.
It just hadn't even occurred to me that this might be a possibility. I'm not even sure how folks get started in the hobby/skill without the CLI background.
I'd be interested in hearing more about the skills progression of these folks, and how they got to the expertise they have today.
It wasn't until I installed linux that I really started to play with any CLI. I honestly don't remember what got me into linux at the moment. I do remember one of the first things I did was learn to setup the system using a tutorial on howtoforge.com. I went through those tutorial many of times setting up my computer.
I was an avid gamer at the time, so I also had my desktop setup to dual boot Windows. After a while I got tired of switching between the two so I ended up taking an old Dell Optiplex 110 installing CentOS on it and trying to get Samba to work so I could mount my web directories on my Windows machine and still edit them, while having Apache serve them.
I did that for a while, then got a job and bought hosting with shell access.
While I've never been part of the Windows world myself, it has always seemed to me that the DOS command line plays a much smaller role there than the shell does in the Unix world. From '97 or so onward it has always been possible to buy a copy of Visual Studio and use it to build software without ever touching a command line, and I'm sure a great many people have done so.
Indeed. It was possible to meaningfully use the command line up through, say, Windows 98 SE or so, once Windows XP hit, it became a relic, stuck in the command.com era while the actual OS kernel moved away from the DOS-hybrid of the Windows 95 era with the shift to Windows NT-derived OSes.
Power Shell (or however that's branded... CamelCase? Alloneword? Hyphenated?) promises to make the Windows command line relevant again, but I honestly don't know if you can meaningfully use a Windows system from only the command line these days. You probably can't use a desktop Windows system that way, which means the command line is still effectively frozen out from the real world.
For some reason, I seems like it's a hard sell for a lot of .NET developers. A substantial number never leave Visual Studio and old habits are hard to break. I left that ecosystem many years ago, but still try to keep up with it.
1. The core concepts are beautiful.
Pipes are elegant. Simple programs that read and write text are one of the most enduring abstractions we've come up with.
I've used a single, surprisingly readable command that:
- dumps a database with mysqldump - zips it - sends it over to another server - unzips it - loads it into mysql
...in a single streaming operation, without creating any files! Making a lot of disparate programs, written decades apart, work together so seamlessly is simply impossible any other way. The shell is powerful.
2. The implementation is unnecessarily complex and fragmented
The standard commands all have cryptic names like `ls`, `cat`, and so on. They're second nature to us, but we've made the barrier unnecessarily high for new people who are just learning. Man pages suck (bro pages are much nicer). There are a lot of shells (bash, sh, zsh, etc). They're similar but subtly different. Standard commands like `ps` are incompatible between OSX and Linux, or even different flavors of Linux. Simple operations often require cryptic incantations. I type `tar -xzvf` at least once a week. The original Unix ideal is minimalist and beautiful, but the rest of the experience feels like it was crafted by neckbeards without regard for usability or learn-ability.
3. Shell scripts are terrible
A fresh, out of the box Ubuntu installation contains (very roughly) 100k lines of shell script, probably more.
For writing actual programs, `bash` is one of the worst programming languages that exist.
It makes languages like Perl or PHP look sane and principled.
Every time I use a solidly engineered system (say `buck` for building a large Java project) next to an equivalent shell-script-based system (say autogen + configure + make for a typical C++ project), I'm blown away at how much faster, cleaner, and more robust our software could be, and I feel sad that we've built so much on top of Rube Goldberg shell script contraptions.
---
I think there's room for a ground-up Unix, true to original principles. I would love to make a minimalist Linux distro that boots without executing a single line of shell script. Configuration would be via a small set of JSON files, not some Turing-complete hairball language. It would still have a shell, but it would be a minimal, sane shell. You'd be able to type `help` for a complete and concise listing of available commands, each with a one-line example.