This is an old revision of the document!
I didn't register in time to make the first class but seeing as how I previously took C/C++ with Matt I don't think it's hurt me too much. This week we spent some time doing what, in street lingo, is referred to as “housekeeping tasks”. Namely, configuring the repository software so we can backup our work, familiarizing ourselves with the lab46 website, etc. I've taken it upon myself to install openbsd on a small desktop that I have at home. That involved downloading a .fs file (don't know what that extension means) and burning it onto a bootable USB stick using Win32DiskImager. It sounds simple but you'd be surprised how much googling I had to do to figure it out. In the end, I managed it but I still haven't configured some things such as making bash color code the files in that cool, super helpful way. I don't know if having openbsd at home is going to be at all useful or relevant to class but it was fun to do.
There was a lot of new information this week. We learned about the Unix file structure and the Unix philosophy
Matt delineated three principles that make up the Unix philosophy and they seem to make a lot of sense. However, he also insisted that the world began on January 1, 1970 which I think brings up a lot more questions than it answers. For example, if the world began on January 1st 1970, then who is John F. Kennedy? Anyway, the three principles (in no particular order) are:
In my limited programming experience, I've found the first point to be very easy to agree with and in general it's the one that most resonates with me. The third bullet appears to be logical enough but the second bullet is the one where I have some confusion. If a file is something that has information in it, isn't literally everything on a computer a file just by definition? Or is that not the definition of a file? I have some more questions but I think some of them will be answered as time goes on.
Imagine opening up a Russian nesting doll and instead of finding one awkwardly depicted grandmother, there are multiple to choose from, and then possibly multiple others inside those. That's the way the directories are organized for us in Unix. The analogy breaks down immediately though because, of course, Unix directories also contain other types of files. Namely, Unix has regular files, special files, and directories. Special files include things like sockets and pipes. So far I know that:
Unix also has a permissions structure. Every sentient(?) being in the universe is determined to be either the owner (of a certain file), a member of the same “group” as the owner, or other (everyone else). For every file each of these categories may or may not have the permission to write to the file, read from the file or search/execute the file. The file permissions are encoded using the octal number system with 0 meaning no permissions, 1 meaning execute permission, 2 meaning read permission, and 4 meaning read permission. Combining the permissions means adding the numbers together.
pbx0 is the week three project. There was a practice section which was followed by the actual project, which in this case took the form of a puzzle.
The procedure for the practice section was as such:
Do the following, and discuss the results in your Opus: | ||
a. | Copy file.txt into your home directory. | |
b. | Using file(1), what type of file does this appear to be? | |
c. | View the contents of this file using cat(1). Is it what it appears to be? | |
d. | Using gzip(1), compress this file with default compression. What does file(1) say? | |
e. | Uncompress the file, and recompress using arguments for fastest (not highest) compression. What does file(1) report now? |
The results of step b indicate that file.txt is an ascii text file. Cat can read the file which confirms this prediction. After compressing the file with gzip, file(1) reads
lab46:~/src/unix/projects/pbx0$ file.txt.gz: gzip compressed data, was "file.txt", last modified: Tue Feb 2 17:11:17 2016, from Unix
After uncompressing and compressing again, file(1) outputs
file.txt.gz: gzip compressed data, was "file.txt", last modified: Tue Feb 2 17:11:17 2016, max speed, from Unix
The only difference between the two outputs is that the second specifies the compression that was used on the file, quite informative.
The project involved a file called “riddle.html” which has several layers of archiving, compression (both zip and gzip), and encoding. The task was to undo all that until you receive a simple message. All in all, it was just a matter of googling and looking at various man pages to figure out the proper next step. On the last step I caused myself some slight extra work by not seeing the new “results” file and mistakenly thinking that the penultimate file wasn't being decoded properly. I modified the file by deleting the first line so that I could use base64 on it. Without the modification base64 considers the file as “invalid input” and doesn't decode while with the modification base64 decodes the file and then tells you it's invalid input. I'm not sure what base64 needs in an input file and I can't see any answers in the man page for that.
This weeks class was divided between two topics: i/o redirection, which I learned a lot from, and the purpose of of various directories in the unix file system, which I did not retain much of.
This is a sample format for a dated entry. Please substitute the actual date for “Month Day, Year”, and duplicate the level 4 heading to make additional entries.
As an aid, feel free to use the following questions to help you generate content for your entries: