I have a lot of similar points of phillbush.

Chapter 3.

This chapter, from my perspective, gives a nice overview of the shell as the program that stands on the other end of the terminal. Through the language you get the clear idea that you are sending "request", as they clearly say, to a Unix server and that these will be interpreted and come back, there's a sentiment of distance which we don't have toay.

The commands have a specific format, like functions you want to be executed.
They are separated by semicolon if on the same line.
Then once you are done you press RETURN to send the request to the shell.

You can group these commands using parenthesis, you can combine them using pipe, which takes precedence over the semicolon, you can even add a program in the middle to take a snapshot of the stream (like tee for example).

You can use the & terminator to tell the shell you don't want to wait for the program to end before getting back control of the shell, to let it execute in the background instead.
This & can be used anywhere on the command line, even in the middle.

They give a nice example, to get notified of when the tea finishes brewing after 5 min, and to get notified with a bell that will sound at their terminal (\a control character). It's interesting because I do the same but with the `at` command instead.

Then the chapter dives into the composability of the shell, especially the IO operations.
It goes in detail about each of the special characters interpreted by the shell: < > | ; &

One interesting thing is how it allows non-obvious use of redirection, like:
Which is the same as:
But less obvious.
And talking about less obvious, they say that people seem to find "cat file |" more natural than `<file`. (Also mentioned by phillbush)

Another special character is the kleene star, or `*` metacharacter, along with the other regular expressions (table 3.1).
Can be used instead of ls.
And they explain that names that start with dots are ignored to avoid problems with "." and "..", which gives rise to dot files.

These metacharacter can be escaped, there's a lot of ways to do that and they go in depth.

One of the exercise points the issue with filenames starting with '-', that could be confused as command line arguments.
And also points out that filenames cannot contain /, though trickily you could use a utf-8 homoglyph.

One thing I wasn't aware of is the {..} expression to run command in current shell, which isn't really practical but good to know.

Another weird behavior I wasn't aware of, is that the metacharacter matching would match literally if no file is found, as though it had been quoted. (Seems like phillbush was also surprised by this)

Comments are inserted using `#`, that's if the word begin with #.

There's a whole section about echo and the argument if it should print a newline or not and what nothing means. If it should add \c or \b instead.
In all cases we can use echo -n to suppress the new line (not portable), or \c if POSIX.


Additionally, there's a lot of small hints at how easy it is to customize your environment, and you're encouraged to do so.
$PS2 is mentioned as the multiline input prompt, which can be modified to taste.

The shell being a program like any other, it can be customized, and take arguments and inputs which are shell scripts. Which starts a whole new section about how to write them.

These scripts need to be in the $PATH, which introduces the concept of the .profile as the "config" for your shell.

Positional parameters/arguments $1 up to $9, and $0 for the name of the program, along with `$*` for all arguments, are also talked about.

Writing personal programs from scratch is hard, what's encouraged is to combine pre-existing ones to create others. So the book then goes into multiple utilities and how to integrate them together in scripts with backticks/backquotes (not $() like phillbush mentioned) and IO redirections.

NB: grep -y argument is now obsolete and synonym for -i. (Case independent matching)

The command `pick` is used a lot, to present arguments one at a time interactively.

To facilitate writing scripts you can use variables, like any other programming language. Here they discern the temporary ones and the ones exported globally.
You can print them with `set`.

Shell scripts also have the ability to load other scripts (like an include), using the . (dot).

More shell script IO is introduced.
There are 3 default file that are always present, the file descriptor for standard input, standard output, and error. You can redirect one unto the other if needed 2>&1 for example.
The heredoc can be used to say that the input is here instead of a fie.

In continuation with the shell as a programming language, we see how loops can be written in both long form and compressed form (single line).


There's then a final bundle example script, which I personally find truly horrible and bad at explaining the concept reviewed.

Still in sync with the idea that the shell is a programming language, and that the environment is very personal, there's a mention of other shells that can be used instead like the C shell.


Chapter 4 first part.

The chapter focuses on text editing and filtering, what it calls data transformers and programmable filters.

There's a small introduction to regex, which probably is better to learn by looking at more modern books. It then shows how this is applied within grep.

At the time grep was also distributed in variant programs, egrep and fgrep, which today are the same as grep -E and grep -F, respectively. These variants are deprecated, but are provided for backward compatibility.

Other common editing tools are talked about:

• sort and uniq
  
• comm
  
• tr
  

And a mention of the dreadful dd, which dates back from tape processing and doesn't follow the convention mentioned.


It continues with this example:


Which I think is also a horrible example because it uses the command 5, which is a custom command introduced before in the book. It's probably a bad idea to alias your command as a number.

Finally, sed appears with its usual syntax of matching and acting on match.


It's talked as an ed on the command line.

Trivia: They emphasize that using "sed 3q" to print the first few lines of a file is easier than having a separate program called "head" because it's more instinctive and easier to memorize. Well, maybe in those days when ed was so popular, but definitely not today.

There's a lot of good sed examples and table 4.2 has a sed commands summary.