5 ms·

Lately I've been butting heads with some seriously anti-command line people. I'm not sure if this is a growing sentiment, or I'm just advocating CLI usage more

by izolate 11y ago

Lately I've been butting heads with some seriously anti-command line people. I'm not sure if this is a growing sentiment, or I'm just advocating CLI usage more as time goes on. Anyway, glad to see this. I'll be sure to recommend it to whomever I'm preaching.

Nadya 11y ago
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"
- na85 11y ago
  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.
- phaemon 11y ago
  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.
  - Nadya 11y ago
    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.
  - deathanatos 11y ago
    > 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>`.
- a3n 11y ago
  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.
  - wingerlang 11y ago
    > 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.
- earthboundkid 11y ago
  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.
- nekkoru 11y ago
  Why not create a series of (edit: autoupdating) symlinks like ~/today and ~/yesterday? Just a thought.
  - deleted 11y ago
    [deleted]
rconti 11y ago
I'm actually shocked to see such a massive number of coders on HN (a skill that still somewhat eludes me) can't use the command line, which I consider a Step #0 type prerequisite. 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.
- marssaxman 11y ago
  The classic Mac OS did not even have a command line interface, so people who began their programming careers in the Apple world between 1984 and 2001-2002 would only have had reason to learn how to use one out of curiosity, or if they happened to be doing cross-platform work with a Unix system. I had a wee bit of Apple II experience prior to the Macintosh, and I suppose you could call the various BBS interfaces I used a form of "command line", but for the most part I never touched a command line as we know it today until the late '90s when I started messing around with Linux and with shell accounts on the Internet. 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.
  - cbd1984 11y ago
    > 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. 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.
a3n 11y ago
I don't advocate anymore, unless there's some slight interest to begin with. I'm that weird old guy whose terminal is always running.
dcposch 11y ago
I use the shell every day, and I have mixed feelings. 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.

by izolate 11y ago

Nadya 11y ago

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"

na85 11y ago
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.
phaemon 11y ago
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.
- Nadya 11y ago
  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.
- deathanatos 11y ago
  > 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>`.
a3n 11y ago
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.
- wingerlang 11y ago
  > 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.
earthboundkid 11y ago
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.
nekkoru 11y ago
Why not create a series of (edit: autoupdating) symlinks like ~/today and ~/yesterday? Just a thought.
- deleted 11y ago
  [deleted]

rconti 11y ago

I'm actually shocked to see such a massive number of coders on HN (a skill that still somewhat eludes me) can't use the command line, which I consider a Step #0 type prerequisite. 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.

marssaxman 11y ago
The classic Mac OS did not even have a command line interface, so people who began their programming careers in the Apple world between 1984 and 2001-2002 would only have had reason to learn how to use one out of curiosity, or if they happened to be doing cross-platform work with a Unix system. I had a wee bit of Apple II experience prior to the Macintosh, and I suppose you could call the various BBS interfaces I used a form of "command line", but for the most part I never touched a command line as we know it today until the late '90s when I started messing around with Linux and with shell accounts on the Internet. 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.
- cbd1984 11y ago
  > 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. 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.

a3n 11y ago

I don't advocate anymore, unless there's some slight interest to begin with. I'm that weird old guy whose terminal is always running.

dcposch 11y ago

I use the shell every day, and I have mixed feelings. 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.