Skimming this makes me long for the time when the multiuser nature of Unix was really utilized as intended.<p>I miss being on a system and typing "who" to see who is on, and starting a chat with them with "talk". Or sending mail to other users just on that system. Using "finger" to read updates in their .plan files.<p>Many of the "social" aspects of the internet today existed in that multiuser aspect of Unix, in a much more intimate way.<p>Macs and Linux machines are still multiuser systems, but "users" are pretty much just used to provide separate configuration and permissions scoping for different application services. It would be nice to have someone hop onto a terminal on my Mac once in awhile and say hello.
Chapter 8 was the most surprising part of the book for me when I first read it. Up till that point lot of the information was mostly what seemed like administrator/user territory. Then BAM! it goes into designing a full fledged interpreter for a BASIC level complexity language, suddenly you are into language design; utterly fascinating how using simple tools like yacc, lex and some simple code (the entire code for the interpreter is published in the Appendix) you can do amazing things as a programmer.
You have to read this so that when inodes come up at your sysadmin/devops social gathering's scintillating conversation you don't have to run to the bathroom and google it on your phone and try muddle your way through without your face turning red.<p>(inodes just strike me as one of those weird little things like SQL, except for much smaller/easier to learn--just something critical, always there, and for some reason, not understood by a lot of sysad/devops types. I forgot the detail until rereading this book recently. I imagine you can expect the details to vary widely on modern filesystems, but ext4 (descending from and backwards compatible with ole ext2) probably has the concept, and BSD's ffs/ufs, and the idea probably gives you some hazy idea of this general area of the world for a lot of filesystems<p>I also find the treatment of some old topics kind of illuminating, like the stty command when I do obscure stuff like use serial terminals or try to use a text buffer as a tty--interesting that you can still tell the kernel "hey, do this dirty hack for my terminal when handling characters and things. Thanks.")
This is a great book, one of my faves. It is a surprise to see it hosted on archive.org when it is still in print, though. Please support good technical writing!<p><a href="https://www.amazon.com/Unix-Programming-Environment-Prentice-Hall-Software/dp/013937681X" rel="nofollow">https://www.amazon.com/Unix-Programming-Environment-Prentice...</a>
"The UNIX system is full duplex: the characters you type on the keyboard are sent to the system, which sends them back to the terminal to be printed on the screen. Normally, this <i>echo</i> process copies the characters directly to the screen, so you can see what you are typing"<p>Ohhhh that is why it is called echo!
> Although most users think of the shell as an interactive command interpreter, it is really a programming language in which each statement runs a command<p>I’ve read the book in one summer when I was in highschool and this sentence was the biggest light bulb moment for me. So simple and eloquent. This was the point where I _get_ what does programming and writing code really means.
I'd love this book if it was rewritten for ANSI C and maybe modern tools such as the ones for NetBSD or OpenBSD at least. AWK and sh still work of course.
This book has an exceptionally high signal:noise ratio. It's long been a favorite of mine, even with its relatively high price tag for a small paperback.
Amazingly I have this on my bookshelf, arms reach away, the times before everything was on the internet. Good times. Though whoever stole my ring-bound vi reference guide of that era - cursor you.
I love this book! There is a lot of abstraction today that most software workers benefit from, but I think there is a lot of value in understanding lower-level mechanisms.