This is going to confuse the frankfurter out of a newbie. First it presents the idea that Windows has a shell, and even multiple shell programs. Screenshots 'n' everything.

But then, nope:

> Windows is not anything like Linux under the hood. So to get a shell working, we have three options:

> Use a tool which provides common Linux tools which have been written to work with Windows

> Use a "virtual machine" running Linux

> Use the Windows Subsystem for Linux

What "common Linux tools which have been written to work with Windows" is referring to is installing Cygwin.

This a fairly hamfisted presentation of a subject matter that could be handled in a way that is simultaneously easier to grasp and factually correct.

First of all, your goal is to teach about a specific command interpreter language, you really want to clarify how there are multiple ones which have different syntax, and brush that whole topic aside as fast as possible.

> You can see what the version is of your shell by running:

> bash --version

Yikes. If we know we are running Bash, the way to know what version it is is:

  echo $BASH_VERSION

and not to run another instance of Bash.

Can this book teach something simple, like comments?

> The shell ignores any text which follows a # hash symbol.

Wrong:

  $ echo 'all of # this is seen'
  all of # this is seen

"this is seen" looks like an example of "any text" to me.

A hash comment marker is ignored if it is not quoted and escaped so as to be part of a word. The hash is also part of certain bits of syntax:

  $#               (dollar hash) number of positional parameters

  ${variable#pat}  expand the content of variable, chopping off
                   a leading portion which matches the pat pattern.
                   Example:

                     $ echo $TERM
                     xterm-256color

                     $ echo ${TERM#xte}
                     rm-256color

  $ echo foo#bar
  foo#bar

"The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." - Ward Cunningham (possibly)

Thanks to those who've commented with corrections/suggestions, I'll go through them try and get the content fixed up where possible. Will need to have a lie down and possibly an epidural before going through the comments again to pull out the changes needed.

For people who think that they're the intended audience of these kinds of guides: do you find them effective?

I learned how to use a POSIX shell years before I learned how to program (outside of a shell, that is), and I've often wondered how to help people (particularly younger colleagues) who learned things the other way around.

My experience so far is that a lot of people get stuck in an "experience trough," for lack of a better phrase: they're comfortable navigating around the filesystem and running basic commands, but struggle with some of the more powerful building blocks that can make someone a real shell power user (`xargs`, nontrivial uses of `find`, here-strings, subshells and blocks, process substitution, etc.).

Good guide to shell in general.

Google shell style guide [0] was also a good read. I thought that the "When to use Shell" section is a section that is good for any kind of guide, not just for bash / shell.

Also, maybe not so much a pitfall / bug, but something I had to deal with recently was that bash does not handle the EINTR when calling write() in the printf and echo builtins [1][2][3], etc.

[0] https://google.github.io/styleguide/shellguide.html#s1.2-whe...

  If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now. Bear in mind that scripts grow. Rewrite your script early to avoid a more time-consuming rewrite at a later date.

[1] https://unix.stackexchange.com/a/487260

  handle the EINTR when calling write() in the printf and echo builtins. 

[2] https://github.com/torvalds/linux/blob/ca1fdab7fd27eb069df13...

  Q: what's up with this '/bin/echo' ?

  A: bash's builtin 'echo' command does not check calls to write() against
   errors. If you use it in the cgroup file system, you won't be
   able to tell whether a command succeeded or failed.

[3] https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00031...

  write() not retried after EINTR in printf and echo

I will use the word `bash` for convenience. `bash` is powerful because it is convenient. `bash` is also powerful because it doesn't tell users how to behave or what to do. `bash` is all about empowering the user. That is what makes it great. `bash` is a meta language for the convenience and the empowerment of programmers. Over time, impossible tasks become trivial. You start off by using `bash` to create simple models of larger/more complex problems, then you adopt pipes and redirection, and eventually you don't need much handholding and you are 10x better at modeling problems, mocking designs, and general problem solving. Will there be 8 hour days to understand some simple concepts? Sure. Do they pay off? Yes. Absolutely yes. Undergraduate computer science background makes bash even more useful and helpful. Outside of college learning, you might be able to grok some things using man pages, tutorials, and various resources (like books).

Bash is so painful to use without vi mode (set -o vi).

Obligatory pedantry: Bash is A shell. It's definitely not "The Shell".

Thanks for taking the time to do this and share it. I think it's a great resource for someone just starting out (this guy). Then more advanced materials can take it from there.