Nixers Book Club - Book #1: The UNIX Programming Environment - Community & Forums Related Discussions

Users browsing this thread: 1 Guest(s)
seninha
Long time nixers
It's time to bump this thread.
How was your week? Have you have a good reading?

Second half of chapter 4 introduces us to awk, a great programming language. That very section of the book motivated me to read another book from Kernighan: The AWK Programming Language, which motivated me to solve the Advent of Code puzzles in AWK. It's very easy to parse input and do simple algorithms on awk, and I recommend anyone to learn it and to try to implement your algorithms in awk before writing the programs in C.

The final program of this chapter is an implementation of calendar(1), an application that is not available on Linux but exists on BSDs, the implementation very straight forward.

Chapter 5 teaches how to do actual programming in shell script by implementing several examples.

cal(1).
The first program is a wrapper around cal(1), this example teaches about the case and set built-ins, and introduces us to the basic of shell programming. It is a very straight forward example but that doesn't apply very well to UNIXes of today. In most implementations, you can "cal october", but "cal 10" still prints the calendar for year 10.

which(1).
The second program is an implementation of which(1), a command that reports which version of a program will be executed when calling it. This example introduces us to test(1), if, and exit status.
One implementation is to loop over the directories named in PATH, searching for an executable file of the given name.
The loop should use sed(1) for generating the list of directories, and test(1) for testing whether there is a file and it is executable.

Quote:The test command is actually one of the clumsier UNIX programs.

The author is probably referring to the different implementations of test and how they differ from one another. There is also a test builtin in most shells, with a different syntax from the test(1) program.
test(1) is unusual because its sole purpose is to return an exit status. It produces no output and changes no file.
A few commands, such as cmp(1) and grep(1), have an option -s that causes them to exist with an appropriate status but suppress all output.

watchfor(1) and checkmail(1)
Those programs introduce us to loops. There is probably a more elegant solution than looping and sleeping some seconds,
like using inotify, on Linux.

nohup(1)
That is a very interesting example, that implements nohup(1). It teaches about signals, trap built-in, test -t (to test whether the standard output is a terminal), nice(1), and the exec builtin. Phew, that is a lot of stuff to be introduced in a single program.

Quote:The command sequence that forms the first argument to trap is like a subroutine call that occurs immediately when the signal happens. When it finishes, the program that was running will resume where it was unless the signal killed it. Therefore, the trap command sequence must explicitly invoke exit, or the shell program will continue to execute after the interrupt

overwrite(1)
That is another interesting example, and one that should be required by POSIX.
It is a very useful program, but because of how shell works, its imput is somewhat clumsy.

zap(1).
Zap is a simple implementation of pkill(1) or killall(1). It uses pick(1), that will be implemented later. It introduces us to the IFS variable and teaches a lot more of signals and how to kill (send them).

pick(1).
One of the nicest examples in this chapter. Pick lets you select some items from the input or arguments and output those that were selected. There is a newer implementation of pick(1) that uses fuzzy finding and I recommend anyone to use: https://github.com/mptre/pick
This program introduces us to using /dev/tty for reading and writing to the terminal rather than to the stdin or stdout.

news(1).
This is a simple program to get the newest files from a directory. There is a news(1) in plan 9.

get(1) and put(1).
This is a simple implementation of the SCCS version control system.
Particularly, I did not like those examples, as those programs are clumsy compared to today's version control systems. But maybe they made sense back in the days. Interestingly, GNU has a program called CSSC ("Compatibly Stupid Source Control") to convert the "compatibly stupid" SCCS into CVS.


Messages In This Thread
RE: Nixers Book Club - Book #1: The UNIX Programming Environment - by seninha - 05-12-2020, 11:12 AM