That is indeed a pity. I try to compensate by making as much material as possible openly available, such as through the MOOC you mentioned (I've been working for five years on it), through my blog, and through open source software and content.
The proposed example problem that would be difficult to solve on the Unix command line can be written as a pipeline of just nine commands. See https://www.spinellis.gr/blog/20200225/
I'm going through the source code. It looks indeed well-written and structured. Its function is a bit difficult to catch the students' imagination, but I think I can make a good case for it.
The advantage of using the shell are the hundreds of powerful command-line tools you can use. Increasingly, there are Perl/Python/Ruby packages that offer similar functionality, but these require some ceremony to use and therefore prohibit rapid prototyping and experimentation.
We have measured many of the examples against the use of temporary files and the web report one against (single-threaded) implementations in Perl and Java. In almost all cases dgsh takes less wall clock time, but often consumes more CPU resources.
You can write many of the examples we provide in bash using tee and tee >(process) syntax when you pipe data into multipipe blocks. To collect the data from multipipe blocks you need to construct Unix domain named pipes and use them in exactly the right order. It quickly gets complicated and ugly. This is our fourth stab at the problem. The earlier ones generated bash scripts, which looked awful and were unreliable.
Pipexec offers a versatile pipeline construction syntax, where you specify the topology of arbitrary graphs through the numbering of pipe descriptors. Dgsh offers a declarative directed graph construction syntax and automatically connects the parts for you. Also dgsh comes with familiar tools (tee, cat, paste, grep, sort) written to support the creation of such graphs.
Rosetta Code proved very useful in an experiment to see how typos affect code written in various programming languages http://www.spinellis.gr/blog/20121205/.
I agree; tests can be too easily gamed. The assessment of courses I described in the blog was mainly based on the coursework. In the programming course a simple multiple-choice exam was used to weed-out students who might assign their coursework to somebody else. In the software engineering course, the "exam" consisted of the final presentation.
According to the data sheet http://datasheets.maxim-ic.com/en/ds/MAX1908-MAX8765A.pdf "D2 protects the MAX1908/MAX8724/
MAX8765/MAX8765A when the DC power source input is reversed. A signal diode for D2 is adequate because DCIN only powers the internal circuitry."
Strangely enough, Greece (which I had in mind when I wrote the blog post) has plenty of processes, procedures, bureaucracy, and comprehensive regulations AND also ranks quite low in the Transparency International Corruption Index, in part due to endemic clientilism.
Many people use UMLGraph to document and reverse engineer existing Java programs. But the reason I wrote it is exactly as a tool to create UML diagrams using a textual notation. It use as a documentation and reverse-engineering tool came about, because the notation is Java-like.
There are also tons of good code around. Most large, successful open source projects have source code full of gems from which we can all learn. Even better, by participating to a large open source project we can also learn a lot from the processes used in it.