Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======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 

<cli>
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
</cli>

After uncompressing and compressing again, file(1) outputs 

<cli>
file.txt.gz: gzip compressed data, was "file.txt",
last modified: Tue Feb  2 17:11:17 2016, max speed, from Unix
</cli>

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:

<cli>
lab46:$ ls > list
</cli>

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:

<cli>
lab46:$ history | less
</cli>

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 

<cli>
lab46:~/src/unix/projects$ ls ??? | wc
</cli>

returns the number of files that have file names of exactly three characters. The command

<cli>
lab46:~/src/unix/projects$ ls *???* | wc
</cli>

Returns the number files with at least three characters in their file name. I wonder if there's a way to use these characters to represent a file with at most 3 characters (is there some kind of inclusive or command?). Anyway, I'll stop the examples here, thus ending the section on wildcards except for some brief, original words that I've just written about performing searches. You can't always get what you want but if you try, sometimes, you just might find that you get what you need.

====A Variety of Things About Linux in General====

Matt talked about the environment variable $PATH. $PATH tells the computer which directory to search through when trying to match what's in STDIN with possible commands. When typing ls, for example, and pressing enter, the computer will search through the directory specified by $PATH and see if it finds a file called "ls" and execute it if it does. A cool thing that can be done with commands is aliasing. By aliasing commands, one can run certain options every time they run the command without having to specify it manually. For example aliasing the command "rm -i" to "rm" results in the rm command running with the -i option switched on even if the user only types "rm" into the command line. Incidentally, the -i option tells the computer to ask if you're sure that you want to remove the files you've specified them before tossing them in the bottomless abyss into which I once lost a 15 minute power-point presentation due to a tragic miss-click.

Matt also mentioned that starting a file name with "." hides that file from ls. Luckily, you can alias ls to always run the option which shows hidden files. Matt also showed that you can use the up and down arrow keys to cycle through previously run commands, meaning you don't have to type them over again. Another useful but of information was that you can take advantage of Linux's multitasking capabilities by using the ctrl z key. Ctrl z takes the process currently running in the foreground and backgrounds it. You can then run the fg command to foreground that process. Matt also showed us some other ctrl key shortcuts which are summarized in the table below.

|  Ctrl key  |Function|
|c|exits process|
|d|exits process more nicely|
|h|backspace|
|j|enter|
|l|clear screen|
|a|move cursor to start of command line|
|e|move cursor to end of command line|
|k|kill command from the cursor to the end of the command line|
|s|transmit off|
|v|ctrl character escape|
|w|cut|
|y|paste|


====Week 6====

===Killing Things===

This week Matt taught us how to kill things like a ninja. The Unix operating system supports various signals that can be sent to programs. I've had some experience with signals when programming with the gtk package in my previous adventures in which I attempted to create windowed programs. The code must be written in order to handle the signals and act on them properly. In Unix, there are 64 signals that can be sent to programs and many of them kill the program by default. Again, it depends on how the program is written to handle those signals. Signals can be sent using the kill command. "kill -l" lists all 64 signals.

SIGHUP, number 1 on the list, stands for signal hang up. Hanging up on a stopped process results in the termination of that process. SIGINT, for Signal interrupt, is what is sent out when one presses the control c key. SIGILL generally gets sent out in the event of an illegal operation being performed. SIGTRAP is similar to SIGINT. SIGKILL is the agent 47 of kill signals. It never fails. SIGSTOP sends a stop signal to programs and when followed with a SIGCONTINUE effectively backgrounds the program. SIGSEGV is the signal sent out to kill programs that are seg faulting. 

===Scripting===
Typing commands into the command line and watching the computer do your work for you while you laugh maniacally and pet your cat is all well and good, but isn't there sometimes even more efficient ways to implement your evil plans? The answer is "yes, scripting". A script is a series of shell commands that are organized in a document so that they can be fed automatically into the computer instead of manually typing them. Scripts start with #! in order to tell the computer which shell the script is written for as different shells have different languages associated with them. Typing "#! /bin/bash" tells the computer that the document is a bash script. Scripts aren't really programs and a script language isn't really a programming language. It's more like pseudo code. For example, while there are variables in bash, there are no variable types or memory allocation functions. All variables are basically treated as a string.

There are some trick that Matt taught us about scripting. Curly braces isolate variable names in situations where the computer may misunderstand whether you are referring to a variable or the string you assigned to the variable name. Bash isn't really meant to complex calculations but it does have a command called "bc" which handles mathematical operations of some reasonable complexity. Some cool things you can do in bc is change the base used in calculations and change the output type to long int for more accuracy. Square brackets can be used to compare values. For example in the following code 

<code>
["${result}" -eq "4"];
</code>

compares the value of the "result" variable to the number 4 and returns true if they are equal. The square brackets can be combined with if then statements in the usual programming way in order to give your scripts some decision making capabilities. The bash scripitng language also has for in loops which are analogous to for each loops in other programming languages such as C/C++. The following code snippet results in bash outputting the numbers 1-10 in standard output through the use of a for loop.

<code>
for ((x=0;$x<10;x++)); do
      echo "x is $x"
done
</code>

It's generally considered good practice to end scripts with an exit 0 command. 

===HTML===
This week's project involved the use of HTML to create web pages and as a result was my first use of HTML. I learned a lot in the short time that I used it. HTML is used to toggle various properties of web pages (font of text, buttons, images) on and off. HTML works with tags that are placed around the object you want to toggle the property of. For example the <font></font> tags will change the font of the text within those tags. By the way, tags pretty much always start with <tag> and end with </tag>.

I also ran into CSS, which is a product of the modern internet that people use within HTML code to gain further functionality and organization. For example with out the css command "style" I'm pretty sure it's impossible to customize your own button without creating an image of it and putting it on the page through the use of the <img> tag. I wasn't able to spend a lot of time in HTML and the code I created wasn't very intelligently written partly due to my ignorance but I look forward to having more opportunities to learn about it.

====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?
Lab46 Wiki

User Tools

Site Tools

Page Tools
