8 ms·

I consider this book pretty much required reading for junior devs and others in engineering who don't have a decent handle on basic Unix skills for whatever rea

I consider this book pretty much required reading for junior devs and others in engineering who don't have a decent handle on basic Unix skills for whatever reason--which seems to be a more common occurrence these days than earlier in my career.

xcambar 4y ago
Because developer tools are increasingly polished and easily accessible without in-depth knowledge of the arcanes of the command line. And that's great to welcome more people in our field. The downside is that once they're welcome, the climb of the learning curve is barely started.
- mkesper 4y ago
  I was astonished last week again how bad GUIs for git are. Take VSCode: It encourages you to enter just the title of the commit message. That's the boring part for people used to describe WHY that change was made in the long message.
  - tweetle_beetle 4y ago
    It arguably follows the underlying git design more closely than many git clients. Git has no concept of commit titles and commit descriptions - it's all just a message, so in VS Code you write it all in the same box with newlines [1]. It's definitely not obvious if you're used to having separate fields, but it's a bit unfair to complain about all GUI clients because an opinionated text input box is missing from a single feature from one of them surely? [1] https://stackoverflow.com/a/51316392 https://stackoverflow.com/a/51316392
- kevin_thibedeau 4y ago
  Those polished tools hide a lot of the underpinnings so that nothing is understood. We get header-only C libraries (not C++) because people don't understand build tooling and want something that works on easy mode.
  - xcambar 4y ago
    What's so wrong about easy mode? For me, it's hard to make good software today because the bar is actually higher, in the sense that it must be usable by a much wider audience and I can't be lazy about usability or even worse, let it unnecessarily complicated because "people should know about it or learn".
    - kevin_thibedeau 4y ago
      Need to migrate your IDE project to a CI system? How do you do that if you only know how to click through a wizard? Everything has to be spoon fed and if it isn't they are paralyzed.
      - xcambar 4y ago
        > Everything has to be spoon fed and if it isn't they are paralyzed. Fixed it for you: [...] and WHEN it isn't they LEARN.
  - sweezyjeezy 4y ago
    I'd say that's a bit orthogonal - command line tools are also hiding underpinnings from you. The issue is about the UX, not the functionality. Seemingly every command line tool has built it's own language of incantations on how to use it. I've been using grep, tar, curl, find, xargs etc. at least a few times per week for over a decade now now. I shouldn't have to look at the man pages this regularly just to remember the letters I need to type on something I've done 30 times before. I don't have this problem with the equivalent libraries in the programming languages I use, give me 'easy mode'. We need new binaries with a modern UX, or a better IDE for using the command line.
    - genericacct 4y ago
      GPT and other similar technology will be the new IDE soon. Command line gpt tools are already out there and they will write bash scripts in seconds.
    - 4y ago
velavar 4y ago
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
chasil 4y ago
It is a very kind gesture to make this book freely-available. It does have a small problem in the number of "bashisms" that it quietly promotes. The entire Debian/Ubuntu family has chosen the Almquist shell because of speed and standards compliance, and many things in this book will not work there. It would be helpful to have a book that is clear that the POSIX.2 shell is not Bash.
- BossingAround 4y ago
  > The entire Debian/Ubuntu family has chosen the Almquist shell because of speed and standards compliance, and many things in this book will not work there. So Debian/Ubuntu ship completely without Bash? According to [1], it's Bash, but it might be outdated. [1] https://wiki.debian.org/Bash https://wiki.debian.org/Bash
  - chasil 4y ago
    Bash is shipped in Debian/Ubuntu, but as /bin/bash, not as /bin/sh. What is shipped as /bin/sh is described here: http://gondor.apana.org.au/~herbert/dash/ http://gondor.apana.org.au/~herbert/dash/ From the EPEL RPM: "DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks."
    - John23832 4y ago
      Hm but the default shell is still bash. It would make sense that "bashisms" don't work on "sh". You should use bash or bash derivatives (zsh) for bashisms. I think the bigger stumbling block is that people often can't differentiate bashisms from basic shell scripting.
      - gdavisson 4y ago
        bash is the default interactive shell for users, but dash is the default shell for scripts with a #!/bin/sh shebang (or no shebang, unless they're run from bash), system() calls, etc. This means bashisms will work sometimes, which can be worse than not working at all. I agree about the importance of differentiating bashisms from basic scripting, but I think the root cause of that is documentation (including this book) that don't make the distinction.
jalino23 4y ago
this true. getting started in the industry has a lot of assumptions about command line knowledge, every other tutorial or book kinda assumes it. it wasn't until 3 years later that I realized that I should have learned it sooner.
heresie-dabord 4y ago
The GNU and/or GNU-Linux terminal is the killer app. * M-Windows WSL2 * Cygwin * Mac OS X * ChromeOS Crostini (Debian Linux VM) * Linux (of course)

xcambar 4y ago

Because developer tools are increasingly polished and easily accessible without in-depth knowledge of the arcanes of the command line. And that's great to welcome more people in our field. The downside is that once they're welcome, the climb of the learning curve is barely started.

mkesper 4y ago
I was astonished last week again how bad GUIs for git are. Take VSCode: It encourages you to enter just the title of the commit message. That's the boring part for people used to describe WHY that change was made in the long message.
- tweetle_beetle 4y ago
  It arguably follows the underlying git design more closely than many git clients. Git has no concept of commit titles and commit descriptions - it's all just a message, so in VS Code you write it all in the same box with newlines [1]. It's definitely not obvious if you're used to having separate fields, but it's a bit unfair to complain about all GUI clients because an opinionated text input box is missing from a single feature from one of them surely? [1] https://stackoverflow.com/a/51316392 https://stackoverflow.com/a/51316392
kevin_thibedeau 4y ago
Those polished tools hide a lot of the underpinnings so that nothing is understood. We get header-only C libraries (not C++) because people don't understand build tooling and want something that works on easy mode.
- xcambar 4y ago
  What's so wrong about easy mode? For me, it's hard to make good software today because the bar is actually higher, in the sense that it must be usable by a much wider audience and I can't be lazy about usability or even worse, let it unnecessarily complicated because "people should know about it or learn".
  - kevin_thibedeau 4y ago
    Need to migrate your IDE project to a CI system? How do you do that if you only know how to click through a wizard? Everything has to be spoon fed and if it isn't they are paralyzed.
    - xcambar 4y ago
      > Everything has to be spoon fed and if it isn't they are paralyzed. Fixed it for you: [...] and WHEN it isn't they LEARN.
- sweezyjeezy 4y ago
  I'd say that's a bit orthogonal - command line tools are also hiding underpinnings from you. The issue is about the UX, not the functionality. Seemingly every command line tool has built it's own language of incantations on how to use it. I've been using grep, tar, curl, find, xargs etc. at least a few times per week for over a decade now now. I shouldn't have to look at the man pages this regularly just to remember the letters I need to type on something I've done 30 times before. I don't have this problem with the equivalent libraries in the programming languages I use, give me 'easy mode'. We need new binaries with a modern UX, or a better IDE for using the command line.
  - genericacct 4y ago
    GPT and other similar technology will be the new IDE soon. Command line gpt tools are already out there and they will write bash scripts in seconds.
  - 4y ago

velavar 4y ago

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

chasil 4y ago

It is a very kind gesture to make this book freely-available. It does have a small problem in the number of "bashisms" that it quietly promotes. The entire Debian/Ubuntu family has chosen the Almquist shell because of speed and standards compliance, and many things in this book will not work there. It would be helpful to have a book that is clear that the POSIX.2 shell is not Bash.

BossingAround 4y ago
> The entire Debian/Ubuntu family has chosen the Almquist shell because of speed and standards compliance, and many things in this book will not work there. So Debian/Ubuntu ship completely without Bash? According to [1], it's Bash, but it might be outdated. [1] https://wiki.debian.org/Bash https://wiki.debian.org/Bash
- chasil 4y ago
  Bash is shipped in Debian/Ubuntu, but as /bin/bash, not as /bin/sh. What is shipped as /bin/sh is described here: http://gondor.apana.org.au/~herbert/dash/ http://gondor.apana.org.au/~herbert/dash/ From the EPEL RPM: "DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks."
  - John23832 4y ago
    Hm but the default shell is still bash. It would make sense that "bashisms" don't work on "sh". You should use bash or bash derivatives (zsh) for bashisms. I think the bigger stumbling block is that people often can't differentiate bashisms from basic shell scripting.
    - gdavisson 4y ago
      bash is the default interactive shell for users, but dash is the default shell for scripts with a #!/bin/sh shebang (or no shebang, unless they're run from bash), system() calls, etc. This means bashisms will work sometimes, which can be worse than not working at all. I agree about the importance of differentiating bashisms from basic scripting, but I think the root cause of that is documentation (including this book) that don't make the distinction.

jalino23 4y ago

this true. getting started in the industry has a lot of assumptions about command line knowledge, every other tutorial or book kinda assumes it. it wasn't until 3 years later that I realized that I should have learned it sooner.

heresie-dabord 4y ago

The GNU and/or GNU-Linux terminal is the killer app. * M-Windows WSL2 * Cygwin * Mac OS X * ChromeOS Crostini (Debian Linux VM) * Linux (of course)