[cs615asa] HW3

[Jan Schaumann]

Hello,

I've just sent out grades for HW#3.  If you have not received your
grade, please contact me asap.

As many of you noticed, this assignment was not terribly complicated,
but writing _simple_ tools is actually something that needs to be
learned, too.  It is by example of such simple tools that we can easily
learn lessons that we then, hopefully, can apply to more complex
assignments, such as HW#4.

A few notes:

====

One of the most common mistakes I've seen was to approach the problem of
supporting multiple operating systems by using a logical 'if Linux then,
else if NetBSD then, else if OmniOS then' check.

This necessarily leads to significant code duplication -- the command
executed for each OS are almost identical.  This also has the side
effect of explicitly not supporting any other OS and means your tool can
only process input from one platform if it is actually running on that
platform.

Code duplication is in virtually all cases a mistake.  Every time you
write the same chunk of code you should step back, take the code, put it
into a function or module and reference that.  This avoids
inconsistencies or bugs when you later make changes in one block, but
forget to do so in the other.  This also works for when the code in
question is not 100% identical:  factor out the commonalities and pass
suitable arguments instead.

Scalable programs also often operate under what is known as "Postel's
Law" (and look up who Jon Postel was, too), also known as the Robustness
Principle: "Be conservative in what you do, be liberal in what you
accept from others."  That is, your program should be able to handle
unexpected input and produce very specific, explicit output (similarly
following the Principle of Least Astonishment).  That is, a user might
expect your program to produce the correct output if executed on OS X,
where the ifconfig(8) output is identical to that on some other
platforms.

By writing your program to not require running on one platform, it
becomes more flexible, too.  You can then run

ssh linux-lab "ifconfig -a" | ifcfg-data -i

===

Your program accepts data on stdin.  There is no need for you to
explicitly read it into a variable just to then echo it into a command.

while read line; do
	echo $line | command
done

is functionally equivalent (though an order of magnitude slower) than

command

Note that in both cases 'command' reads data from stdin.  In the first
case, you read data from stdin, then feed it the command.  In the second
case, 'command' consumes stdin directly.  No need for you to play man in
the middle here.

Note also that whenever possible you should avoid the use of temporary
files.  Safely creating, using, and then deleting files includes a
number of complexities that often can simply be avoided altogether:

- where to create files
- what to name them
- how to ensure no other process reads/writes them while you consume them
- how to ensure your program can't be used to destroy other files via a
  symlink attack
- how to handle the case of not being able to create a file
  (due to permissions in the directory, being out of disk space, being out
   of inodes, ...)
- how to handle the race condition of multiple instances of your program
  reading/writing to the same file
- how to ensure the file is removed when your program exits (including
  unexpected exits, such as when the user interrupts the program)

===

Several of you generated output for OmniOS's IPv6 addesses that looked
like this:

::1/128
::/0

These are pairs of IP address and netmasks.

Similarly, for other platforms you did not properly identify the IPv6
netmasks (often termed 'prefix length') for other platforms.

As usual, the assignments for you should also be used as an incentive to
research the topic at hand and understand what it is you're doing.  Ie,
here we wanted to extract IP addresses, netmasks, and mac addresses --
hoping you would learn not just which strings to extract, but what those
are.

We will cover this in more detail in today's class.

===

Before you submit your homework, *test it*.  There were more than one
case where some code blocks had simple syntax errors or typos that lead
to the program not working or not working as expected.

Consider your homework submission to me equivalent to deploying your
code into production: you want to be certain that it works.  If there
were any last second changes, make sure to execute all code paths again
to ensure that nothing else broke.

===

For HW#4, please try to keep the above in mind; be sure to ask questions
about anything that you are not sure about.

-Jan