3 ms·

It is a productivity thing. CLI tools have consistent interfaces and once you are familiar with the common tools and workflow, it is considerably faster to do w

It is a productivity thing. CLI tools have consistent interfaces and once you are familiar with the common tools and workflow, it is considerably faster to do what you are looking to do. One particular trait that has personally made my workflow a lot faster is being able to repeat a command from history (by pressing Ctrl-R) and then writing only part of the command to run it. It saves a lot of time and makes it less cumbersome to type in very long commands. Now to contrast this with GUIs, even the simplest things would require me to jump through menus, type some stuff, etc. Everything in the command line is precise and repetitive steps are easy to replicate. Piping is another aspect that the command line enables, which basically feeds to output of one command into another. One common example of this is to look at lines of a log file that contain a certain set of words: `cat log.txt | grep "[ERROR]"`. But perhaps the strongest selling point of working in the command line is consistency among tools. If you want to be productive as a developer, use of various tools for doing various tasks is common. Using the CLI for all these tools keep everything a few commands away, even interoperability is enabled seamlessly due to piping and consistency. So yes, there is a fairly steep learning curve, but in my opinion learning how to use CLI tools over GUI is well-worth the hassle.

shay_ker 7y ago
> But perhaps the strongest selling point of working in the command line is consistency among tools Isn't this.... not true? A lot of the *nix commands have strong consistency, yes, but there are many commands that are just designed poorly and you can't easily pipe them. And what about widely used tools like Google Docs? How could that have a consistent interface in a terminal?
- unknown2374 7y ago
  Google Docs is not for development, perhaps I should have been clearer about that. The vast majority of tools for development, devops, system/network administration are consistent, or at the very least consistent enough that it helps towards making the workflow more productive. Not all software is suited for the terminal, that should be obvious. Like you would not want to play a graphically intensive game on the terminal because... graphics. Since you brought it up, what use-case do you have with piping Google docs exactly?
  - shay_ker 7y ago
    I mainly brought up Google Docs because it's something that many of us use that breaks us from "living in the terminal". Someone who "lives in the terminal" would want all of Google Doc's functionality, but in a terminal. In theory, I should be able to grep & sed a Google Docs page for some things. > Not all software is suited for the terminal, that should be obvious Like wtfutil, the very thing that's linked here on HN???
    - unknown2374 7y ago
      What exactly is the alternative to the tool linked here? I am really curious to see because I have never come across an open source resource-lite customizable dashboard such as this. As someone who has his entire workflow on the terminal, this tool is of great interest to me. > I mainly brought up Google Docs because it's something that many of us use that breaks us from "living in the terminal". Someone who "lives in the terminal" would want all of Google Doc's functionality, but in a terminal. People who live in the terminal does not literally mean that they spend 100% of their time on the terminal fyi. I doubt anyone does in this day and age, I was under the impression that that fact was implied.
    - OJFord 7y ago
      > > Not all software is suited for the terminal, that should be obvious > Like wtfutil, the very thing that's linked here on HN??? IMO the only significance of it running in the terminal is that you can assume it's reasonably performant without digging into comments to see if people are saying 'Cool but Oh God, Electron?'. If I were creating it, I would be choosing between Electron and ncurses-wrapping library for whatever language I wanted to use. Then I'd choose the ncurses-wrapping library, because, well Oh God Electron. Sure, it could be a native GUI, but then I'd have to learn about that for every platform I wanted to release on. Sure, it could be Qt or GTK, but I've only used them once each briefly and in anger, and again, no desire to learn. Point is it doesn't need to be in the terminal because no you're not going to feed stuff in and redirect its output, but it certainly does it no harm, and the terminal's an easy development target.

shay_ker 7y ago

> But perhaps the strongest selling point of working in the command line is consistency among tools Isn't this.... not true? A lot of the *nix commands have strong consistency, yes, but there are many commands that are just designed poorly and you can't easily pipe them. And what about widely used tools like Google Docs? How could that have a consistent interface in a terminal?

unknown2374 7y ago
Google Docs is not for development, perhaps I should have been clearer about that. The vast majority of tools for development, devops, system/network administration are consistent, or at the very least consistent enough that it helps towards making the workflow more productive. Not all software is suited for the terminal, that should be obvious. Like you would not want to play a graphically intensive game on the terminal because... graphics. Since you brought it up, what use-case do you have with piping Google docs exactly?
- shay_ker 7y ago
  I mainly brought up Google Docs because it's something that many of us use that breaks us from "living in the terminal". Someone who "lives in the terminal" would want all of Google Doc's functionality, but in a terminal. In theory, I should be able to grep & sed a Google Docs page for some things. > Not all software is suited for the terminal, that should be obvious Like wtfutil, the very thing that's linked here on HN???
  - unknown2374 7y ago
    What exactly is the alternative to the tool linked here? I am really curious to see because I have never come across an open source resource-lite customizable dashboard such as this. As someone who has his entire workflow on the terminal, this tool is of great interest to me. > I mainly brought up Google Docs because it's something that many of us use that breaks us from "living in the terminal". Someone who "lives in the terminal" would want all of Google Doc's functionality, but in a terminal. People who live in the terminal does not literally mean that they spend 100% of their time on the terminal fyi. I doubt anyone does in this day and age, I was under the impression that that fact was implied.
  - OJFord 7y ago
    > > Not all software is suited for the terminal, that should be obvious > Like wtfutil, the very thing that's linked here on HN??? IMO the only significance of it running in the terminal is that you can assume it's reasonably performant without digging into comments to see if people are saying 'Cool but Oh God, Electron?'. If I were creating it, I would be choosing between Electron and ncurses-wrapping library for whatever language I wanted to use. Then I'd choose the ncurses-wrapping library, because, well Oh God Electron. Sure, it could be a native GUI, but then I'd have to learn about that for every platform I wanted to release on. Sure, it could be Qt or GTK, but I've only used them once each briefly and in anger, and again, no desire to learn. Point is it doesn't need to be in the terminal because no you're not going to feed stuff in and redirect its output, but it certainly does it no harm, and the terminal's an easy development target.