User Tools

Site Tools


blog:spring2016:mpotapen:journal

This is an old revision of the document!


UNIX/Linux Fundamentals Journal

Week 1

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.

Week 2

There was a lot of new information this week. We learned about the Unix file structure and the Unix philosophy

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:

  • Small is beautiful.
  • Everything is a file.
  • Do only one thing, and do that one thing very well.

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.

Unix File Structure

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:

  • Regular files are actually quite regular (text files, executable binary files, etc.).
  • Directories contain the paths of files.
  • Pipes allow processes to communicate with one another somehow.
  • Sockets have something to do with networks.
  • special files can be related to I/O sorts of things.

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.

Week 3

pbx0

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.

Practice

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.

Actual Project

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.

Things learned in class

I/O redirection

Giving a person a command means telling them to do something. Executing a command in Unix means telling the computer to do something. In many cases computers and people are poor substitutes for each other. In the case of Unix, commands always involve some input given by the user and some output given back by the computer. Different commands have different kinds of inputs and outputs and different ways that the inputs and outputs are handled. For instance, the ls(1) command requires a path as input (which may be given implicitly or explicitly) and prints it's output to the terminal by default. However the cp(1) command needs some explicit input by the user and instead of printing some output it outputs a file of some sort which can then be accessed by the user. The reason I'm going on about all this is that in class this week we learned how to redirect the input and output of commands to wherever you want.

The “>” symbol is used to redirect the output of a command. For example:

lab46:$ ls > list

redirects the output of the list command into a file called list. The “»” indicates that you want to append to the file rather than overwrite it. Standard out redirection is also represented by a file descriptor 1>. In other words, “1>” and “>” can be used interchangeably. You can redirect standard input using “<” and standard error using “2>”.

Additionally, the output of one command can be fed into the input of another command using the pipe symbol, “|”. For example:

lab46:$ history | less

Redirects the output of the history command into the input of the less command, which allows you to page through your command history.

Week 4

This week was spent learning about VI. VI, of course, stands for vertical integration. Hold on, 8th grade social studies is leaking, let me just fix that. Okay, VI actually is short for “visual”, but like vertical integration, it can greatly reduce overhead costs if applied properly. Just make sure you know how to control it or you're in for a world of pain.

The beauty of VI is that it was created before the invention of the mouse which, If you agree with Matt, is a humiliating and debasing thing for a human to have to use. Cursor keys didn't exist either and neither did many amenities that we're used to nowadays like volume buttons and delete keys. People had to be clever and economical with their keystrokes and needed a lot of functionality to be commanded by only a small number of actual buttons. The thing that appeals to me about VI is that it gives you the tools to have the computer do your work for you instead of having to scroll through documents yourself like some kind of animal. Using a computer well is a beautiful thing. Honestly speaking, it does put me off how different it is and I'm not entirely convinced that some of its appeal isn't just based on nostalgia but I have an open mind I look forward to becoming more proficient with it.

So what are the basics of VI? The first thing to know is how to type actual things to the document. It seems simple, and it is. But you have to be in insert mode. One of many ways to enter insert mode is to simply press the “i” key. Now when you start typing, words actually show up on the screen. Typing away at your document recklessly whilst being in command mode can be a very jarring experience. However, command mode is awesome and powerful. the “esc” key always puts you in command mode and it is where you can seriously start editing your document.

For example, let's say you want to copy 4 words adjacent to your cursor. Are you going to spend time trying to highlight exactly what you want with your mouse? No, because you're not a barbarian. You simply, like a gentleman, press “4yw”. The commands of VI combine very logically with each other. The “w” command advances your cursor by a word. The “y” command is copy. Putting a number prefix before commands tells VI to do the command that number of times. So “4yw” means copy the next word four times, or copy the next four words. Very elegant. You can do the same thing with lines instead of words by substituting the “w” key with the “$” key which moves the cursor to the end of the current line. Instead of copying the next x number of lines/words you can get the x previous lines/words by substituting the “w”/“$” commands for the “b”/“0” commands which do exactly the opposite. And the craziest thing is, this is just the tip of the iceberg.

I can't remember much else you can do with VI right now but believe me, there's a lot. Therefore, I'm going to end this entry for now but when I do run across other VI commands that those savages using Microsoft Word don't have access to, I will describe them below.

Week 5

In week 5, Matt taught us about wildcards and a variety of things about Linux in general.

Wildcards

Wildcards are characters that the computer interprets as a substitute for a certain class of character. Using a wildcard allows you to specify your search criteria with greater Flexibility. Matt showed us 4 wildcard characters. You can do a lot with those four. The * represents any number of any character. It's not super specific but it gets a large amount of its importance from being in combination with the other characters. ? represents one or more of any character. It's slightly more specific and as far as I can see so far its main functionality is to determine the size of the token that you're seeking. Putting characters inside of square brackets tells the computer to search for any of those characters. For example [aeiouy] can be used to search for vowels. [A-Z] can be used to search for capital letters. The fourth wildcard character is [^]. That is referred to as the inverted char class character and searches for everything not included in the brackets. [^aeiouy] searches for any character that's not a vowel.

Combining these wildcards can result in some very powerful searches but more importantly, it's fun to figure out how to use them to get what you want.

The in class examples concerned counting the number of files with certain attributes in their names. By using ls in combination with the wildcard characters and then piping (or if you're in on this joke, passing the joint) to wc you count files based on their file names. For example the command

MONTH Day, YEAR

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:

  • What action or concept of significance, as related to the course, did you experience on this date?
  • Why was this significant?
  • What concepts are you dealing with that may not make perfect sense?
  • What challenges are you facing with respect to the course?
blog/spring2016/mpotapen/journal.1456806106.txt.gz · Last modified: 2016/03/01 04:21 (external edit)