6 ms·

Do you think that this is because they don't really need to anymore with all the nice GUI/tools around? Is there an advantage to bring able to do something on a

Do you think that this is because they don't really need to anymore with all the nice GUI/tools around? Is there an advantage to bring able to do something on a command line vs other ways? Asking because I'm at a bit of a crossroads - I have a good handle on about 5% of the command line knowledge which gets me through 80% of the stuff I need to do. I'm wondering if learning to use more commands is worth the effort when I can already get the task done without using the command line?

deleted 4y ago
[deleted]
somrand0 4y ago
depends on how close you wanna get to the servers, and then the hardware? I suppose it's a super rare occurrence now, but back when I was starting on this, I would mess up my X server and was forced to fix it from the command line.
dinkumthinkum 4y ago
I think a lot of very junior developers now really just don’t know very much about computers and electronics beyond social media.
gofreddygo 4y ago
more commands are a side effect of more capability. If you get a sense of things you can do with (|, & , >) and a dozen or so commands like sort | uniq | cut | paste | join | head | tail | sed | awk | wc | tr | fmt | col | nl | pr | find | grep | tar | export The value you get in return is intense for the effort invested. Plus, in the 10 years i've been maintaining code, bash scripts are the minority that still work as they used to with almost no change needed. That single handedly is worth my money.
- foobarian 4y ago
  These days I would include jq in that list as well, near the front in fact
  - deathanatos 4y ago
    And xsv, if you're doing anything with CSV. A lot of cut invocations I see are on CSV files, and are all bugs out of the gate. (But use JSON, if you can. It's a step up, and easier to work with, particularly with jq.)
Nihilartikel 4y ago
It's tough to quantify the knowledge levels, but, I'd say that a practical understanding of bash loops, piping, grepping, and 'cut' ing text. Is a good start for basic dev work. I've seen hours wasted writing jankey one off c++ utils, for lack of knowing that grep/awk exist. Being able to tail a dev log and filter it for errors is also a part of seasoned developer competence too, I'd say.
- randomluck040 4y ago
  I wouldn’t call myself seasoned developer but tail (and grep) saved so much time during my masters thesis, I don’t even know how I’d checked for new entries in my log files other than using cat. When working with anything posting a log, I’m very grateful to know about tail.
amalgamated_inc 4y ago
I think that you probably have 80% of the gross capability, but you will gain a huge level of refinement. I'm about 10-15 years into the command line (depending on how you count, lol) and I keep finding more stuff that just wouldn't stick 5 years ago, because I simply didn't have those problems yet. E.g. there was a time in my life when I didn't get what `xargs` even did, I literally couldn't grok it. Now, I can't imagine life without `-0`! The composability of UNIX commands is just so amazing. Every command builds on every other command. I haven't seen that with any other tools or program.
- tester457 4y ago
  What is the most helpful thing you do with xargs and -0?
  - dredmorbius 4y ago
    Easily handling arguments with whitespace is the obvious answer. e.g.: find . -type f -print | xargs wc -l vs. find . -type f -print0 | xargs -0 wc -l If you have filenames with whitespace, the first will skip a bunch of files. If you're doing processing on other inputs which may include whitespace, you'll be able to handle those using xargs without worrying about additional delimiting. And for those not aware, '-print0 / -0' arguments to find(1) and xargs(1) respectively tells the first to output ASCII NUL delimited arguments, and for the latter to expect the same. As ASCII NUL should not normally occur within any argument, it's the ultimate delimiter. I've used xargs and/or bash loops to do some fairly heavy-duty web scraping given an input list of arguments. Using xargs allows multiple simultaneous parallel queries such that any one request stalling out doesn't hold up all process.
    - dredmorbius 4y ago
      And to clarify, by "skip a bunch of files", what I of course mean is that if your document is named "Your Document.md", what the first find(1) command will do is attempt to run "wc -l" on "Your" and "Document.md", neither of which it can find, a fact about which it will complain bitterly, creating much noise in your shell session. It will fail to run "wc -l" on the file "Your Document.md", which the second example will do correctly (and not on the name-fragments). "wc -l" gives a line count for a file. That's ... not especially advanced, but is a trivial example of an xargs command which you should be able to try without causing any problems on your own system.
type-r 4y ago
When contemplating a future investment into learning something, I like to consider the long-term benefits. Do we believe that command lines will become more or less important in the following years? My bet is that they will continue to fade over time, as they have been for years (decades?). I don't think there's much sense to invest more than the minimum unless there's a specific use case in mind.
- chasil 4y ago
  The Bourne shell was a relative latecomer to UNIX, released in 1979, replacing the [Ken] Thompson shell. It lacks many things provided by a POSIX shell (nearly all of which are present in the later Korn shell). There are many entire operating systems that survived only a fraction of this time. I think that it will remain relevant for decades. https://en.wikipedia.org/wiki/Bourne_shell https://en.wikipedia.org/wiki/Bourne_shell
_dain_ 4y ago
Consider each program as a node in a graph, with the edges as the possibility of interop -- output of program A working as input of program B. With UNIXy command line programs this is pretty close to a fully-connected graph. So, per Metcalfe's Law, the value scales with the square of the number of programs you know how to tape together. Command line programs compose like this, GUIs don't.
zzo38computer 4y ago
Pipes, redirection, scripts, etc are some of the most important reasons why command-line is better in many ways than GUI. In some cases GUI is helpful, but often, command-line is much better in many ways. For this and other reasons, I will often write programs as command-line using standard I/O for most data. For example, a music playing program which reads the music file from stdin and writes the audio data to stdout which is taken by aplay to play the audio on the speaker. (In this way, you can also add other thing in between such as special effects, if desired.) (It is also useful for other programs (interactive or GUI or whatever) to have the opportunity to open pipes with other user-specified programs; Meirloom-mailx is one interactive command-line program does it (I often use that feature to display pictures attached to messages), and Free Hero Mesh (which has GUI) also exclusively uses such pipes to import/export levels and pictures and move lists.)
dredmorbius 4y ago
The book is freely downloadable as a PDF, and the introduction gives a brief answer to that question. The rest of the book offers a somewhat longer-form answer. Another reference I'd strongly recommend is the O'Reilly UNIX Power Tools book, which though it turns 30 as of the new year remains one of the best "what are some really useful recipes" books about and for Unix / Linux. That is freely available here (3rd edition): <https://mathcs.duq.edu/~juola/UnixBooksPDF/unixpowertools.pdf https://mathcs.duq.edu/~juola/UnixBooksPDF/unixpowertools.pd...> (PDF)

deleted 4y ago

[deleted]

somrand0 4y ago

depends on how close you wanna get to the servers, and then the hardware? I suppose it's a super rare occurrence now, but back when I was starting on this, I would mess up my X server and was forced to fix it from the command line.

dinkumthinkum 4y ago

I think a lot of very junior developers now really just don’t know very much about computers and electronics beyond social media.

gofreddygo 4y ago

more commands are a side effect of more capability. If you get a sense of things you can do with (|, & , >) and a dozen or so commands like sort | uniq | cut | paste | join | head | tail | sed | awk | wc | tr | fmt | col | nl | pr | find | grep | tar | export The value you get in return is intense for the effort invested. Plus, in the 10 years i've been maintaining code, bash scripts are the minority that still work as they used to with almost no change needed. That single handedly is worth my money.

foobarian 4y ago
These days I would include jq in that list as well, near the front in fact
- deathanatos 4y ago
  And xsv, if you're doing anything with CSV. A lot of cut invocations I see are on CSV files, and are all bugs out of the gate. (But use JSON, if you can. It's a step up, and easier to work with, particularly with jq.)

Nihilartikel 4y ago

It's tough to quantify the knowledge levels, but, I'd say that a practical understanding of bash loops, piping, grepping, and 'cut' ing text. Is a good start for basic dev work. I've seen hours wasted writing jankey one off c++ utils, for lack of knowing that grep/awk exist. Being able to tail a dev log and filter it for errors is also a part of seasoned developer competence too, I'd say.

randomluck040 4y ago
I wouldn’t call myself seasoned developer but tail (and grep) saved so much time during my masters thesis, I don’t even know how I’d checked for new entries in my log files other than using cat. When working with anything posting a log, I’m very grateful to know about tail.

amalgamated_inc 4y ago

I think that you probably have 80% of the gross capability, but you will gain a huge level of refinement. I'm about 10-15 years into the command line (depending on how you count, lol) and I keep finding more stuff that just wouldn't stick 5 years ago, because I simply didn't have those problems yet. E.g. there was a time in my life when I didn't get what `xargs` even did, I literally couldn't grok it. Now, I can't imagine life without `-0`! The composability of UNIX commands is just so amazing. Every command builds on every other command. I haven't seen that with any other tools or program.

tester457 4y ago
What is the most helpful thing you do with xargs and -0?
- dredmorbius 4y ago
  Easily handling arguments with whitespace is the obvious answer. e.g.: find . -type f -print | xargs wc -l vs. find . -type f -print0 | xargs -0 wc -l If you have filenames with whitespace, the first will skip a bunch of files. If you're doing processing on other inputs which may include whitespace, you'll be able to handle those using xargs without worrying about additional delimiting. And for those not aware, '-print0 / -0' arguments to find(1) and xargs(1) respectively tells the first to output ASCII NUL delimited arguments, and for the latter to expect the same. As ASCII NUL should not normally occur within any argument, it's the ultimate delimiter. I've used xargs and/or bash loops to do some fairly heavy-duty web scraping given an input list of arguments. Using xargs allows multiple simultaneous parallel queries such that any one request stalling out doesn't hold up all process.
  - dredmorbius 4y ago
    And to clarify, by "skip a bunch of files", what I of course mean is that if your document is named "Your Document.md", what the first find(1) command will do is attempt to run "wc -l" on "Your" and "Document.md", neither of which it can find, a fact about which it will complain bitterly, creating much noise in your shell session. It will fail to run "wc -l" on the file "Your Document.md", which the second example will do correctly (and not on the name-fragments). "wc -l" gives a line count for a file. That's ... not especially advanced, but is a trivial example of an xargs command which you should be able to try without causing any problems on your own system.

type-r 4y ago

When contemplating a future investment into learning something, I like to consider the long-term benefits. Do we believe that command lines will become more or less important in the following years? My bet is that they will continue to fade over time, as they have been for years (decades?). I don't think there's much sense to invest more than the minimum unless there's a specific use case in mind.

chasil 4y ago
The Bourne shell was a relative latecomer to UNIX, released in 1979, replacing the [Ken] Thompson shell. It lacks many things provided by a POSIX shell (nearly all of which are present in the later Korn shell). There are many entire operating systems that survived only a fraction of this time. I think that it will remain relevant for decades. https://en.wikipedia.org/wiki/Bourne_shell https://en.wikipedia.org/wiki/Bourne_shell

_dain_ 4y ago

Consider each program as a node in a graph, with the edges as the possibility of interop -- output of program A working as input of program B. With UNIXy command line programs this is pretty close to a fully-connected graph. So, per Metcalfe's Law, the value scales with the square of the number of programs you know how to tape together. Command line programs compose like this, GUIs don't.

zzo38computer 4y ago

Pipes, redirection, scripts, etc are some of the most important reasons why command-line is better in many ways than GUI. In some cases GUI is helpful, but often, command-line is much better in many ways. For this and other reasons, I will often write programs as command-line using standard I/O for most data. For example, a music playing program which reads the music file from stdin and writes the audio data to stdout which is taken by aplay to play the audio on the speaker. (In this way, you can also add other thing in between such as special effects, if desired.) (It is also useful for other programs (interactive or GUI or whatever) to have the opportunity to open pipes with other user-specified programs; Meirloom-mailx is one interactive command-line program does it (I often use that feature to display pictures attached to messages), and Free Hero Mesh (which has GUI) also exclusively uses such pipes to import/export levels and pictures and move lists.)

dredmorbius 4y ago

The book is freely downloadable as a PDF, and the introduction gives a brief answer to that question. The rest of the book offers a somewhat longer-form answer. Another reference I'd strongly recommend is the O'Reilly UNIX Power Tools book, which though it turns 30 as of the new year remains one of the best "what are some really useful recipes" books about and for Unix / Linux. That is freely available here (3rd edition): <https://mathcs.duq.edu/~juola/UnixBooksPDF/unixpowertools.pdf https://mathcs.duq.edu/~juola/UnixBooksPDF/unixpowertools.pd...> (PDF)