Comment by Nadya | Hacker News Reader

Comment by Nadya | Hacker News Reader

Parent Full thread

I can often navigate to a file in a GUI faster than I can "cd users/Nadya/documents/work/2015/08/24/important/file.txt" [0]

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"

I don't think speed is the best argument pro the command line. If you're used to and proficient in a gui or cli, then it's going to feel like you're getting more done in your familiar environment.

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.

> 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?

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.

Your GUI often includes shortcuts (e.g. to your "work" folder) and that functionality is accessed from the command line via symlinks. Your comparison is not really fair.

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.

You can't 'cd' to a file :-)

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.

Arrgh, you caught me! ;) Replace cd with nano and I'll try to avoid the text editing via GUI vs text editing via CLI debate.

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.

> You can't 'cd' to a file :-)

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>`.

CLI is better for when you know where you want to go, but it sucks for exploration. It takes much more effort to learn how a file tree is laid out using the CLI than it does using a GUI.

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.

Why not create a series of (edit: autoupdating) symlinks like ~/today and ~/yesterday? Just a thought.

Reply on news.ycombinator.com