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:

• 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.

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.

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:

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.

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.

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.

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

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

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

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

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

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.

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.

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.

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

["${result}" -eq "4"];

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.

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

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

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.

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?

Presented within will be various questions evaluating your knowledge and experience gained this semester. In places where you are able, the more you write and explain topics the better the chance you will have of receiving full credit (and alternatively, the more credit you will receive should something defer correctness).

The questions on this experience are open resource with the exception of other individuals. In that respect, it is CLOSED PERSON. This means you are not to communicate with other people (either in the class or otherwise), in real life or electronically. Use your own knowledge, use your own skills, and use your own ability to access the allowed resources to aid you in coming up with your well thought out responses to each question.

You are allowed, and expected, to seek clarification on any question by asking me. But the aim here is to evaluate what you have learned, so do not expect any handholding, handouts, or tutoring. You may find I will be more responsive to finer, more fluent questions; just asking “I don't know, what do I do?” is neither inspiring nor encouraging.

You are to do all items. Submission is to be as follows:

• an organized and easy to read presentation of information on your EoCE wiki page.
• if applicable, a submitted archive using the submit tool (likely via Makefile)

The EoCE will be worth 24% of your overall grade, and will be broken down as follows:

• If there is an In-Person Knowledge Assessment, the EoCE breakdown will be as follows:
  • 1/3 will count toward the project component of your grade (constituting 8% of the project component total).
    • this will include any programs/scripts created and their correctness to stated specifications
  • 1/3 will count toward the journal component of your grade (constituting 8% of the journal component total).
    • this will involve documenting your responses to various questions on this EoCE document, along with the consideration of correctness to stated specifications (where applicable)
  • 1/3 will count toward the participation component of your grade (constituting 8% of the project component total).
    • this involves completing the in-person knowledge assessment, with consideration of correctness to stated specifications
• If there is no In-Person Knowledge Assessment, the EoCE breakdown is as such:
  • 1/2 will count toward the project component of your grade (constituting 12% of the project component total).
    • this will include any programs/scripts created and their correctness to stated specifications
  • 1/2 will count toward the journal component of your grade (constituting 12% of the journal component total).
    • this will involve documenting your responses to various questions on this EoCE document, along with the consideration of correctness to stated specifications (where applicable)

DEADLINE FOR SUBMISSION: You have until 02:14:59pm (that's 14:14:59 in 24-hour time) Thursday, May 12th, 2016 to complete your EoCE(s). This is the ultimate deadline for any and all coursework. There is no “late”, only “too late”. Don't be that person, not with this.

While some classes are allocated a specific meeting time during finals week, I make all such times available should you be free and have questions. Available times (all in R108) are:

• Monday, May 09th, 2016 from 10:00am - 02:00pm
• Tuesday, May 10th, 2016 from 08:00am - 02:00pm
• Wednesday, May 11th, 2016 from 10:00am - 02:15pm
• Thursday, May 12th, 2016 from 10:00am - 02:15pm

Good luck!

Analyze the following script and respond to the questions that follow:

1

#!/bin/bash
#
# Run this script as follows:
#   ./script 44.1 33 22 3 11 12 23 0 34 2 45 5 1 3.14159 4
#
function process() {
    sleep   "$1"
    echo -n "$1 "
}
 
for data in $*; do
    process "$data" &
done
wait
echo
 
exit 0

ASSUMPTIONS: To make your task easier, you may work with the following assumptions:

• no value provided on the command-line will be greater than 60 (ie all values will range from 0-59)
• no need to do command-line argument error checking: assume only correct values will be provided

• What does the $* variable do?
• What does the & symbol do?
• What is this script doing? (think general operation/end product)
• How is it doing this?
• Adjust the script to output each value on a line by itself, include it below
• Comment the script and include your updated code below (first code block)
• If you wanted to reverse the order of processing, how would you do it (second code block)

Please respond to all questions either directly after, under, or in an otherwise clearly identified manner.

Place your code to the updated scripts here:

# Your commented, one value per line script

# Your script that reverses order of processing

In /var/public/spring2016/unix/eoce/ is a file called swe7tfa.mp4, which is your EoCE puzzlebox. Unravel its mysteries, and post any command-lines used and end results obtained here.

lab46:~/src/unix/eoce/0x1$ 

Feel free to create any many stanzas of cli tags as needed (just make sure for every opening tag there's a corresponding closing tag).

Write two scripts, each one implementing palindrome checking functionality.

Each script must validate whether or not input is a palindrome (or not), and output a message appropriately.

Each script must perform its palindrome processing in an entirely different way from the other.

The intent here is to come up with fundamentally different ways of solving a problem.

Put your code for your first iteration here:

# Your code

Put your code for your second iteration here:

# Your code

As a mid-level UNIX support specialist, and fledgling scripting deity, you find a commonly given explanation for why something broke that seemingly started working on its own has been that it “must be the phase of the moon”.

Bored one afternoon with debugging misguided user configurations that set ls colors of directories to red foreground on red background (what were they thinking?), you decided to hone your moon phase skills and offer up a bit of variety to support clients.

The pom(1) tool reports the current phase of the moon. It can also be given an argument of a particular date, and it will report the moon phase.

Your task is to write a script that:

• if given no command-line arguments, will report the next day and approximate starting time (from the current date) that “The Moon will be Full”.
• if given a command-line (a specific year), display that year's full moons (From Jan 1st - Dec 31st), identifying the date and approximate start time of each occurrence.

Understanding should not come from exclusively memorization; in fact, it is far more important to know where to look than to know every possible aspect of a thing. The frequently-used aspects will flow, the lesser-used should be a good or reference away.

In computing, the ability to deal with binary, octal, and hexadecimal values in a quick and effective fashion involves having more immediate recall on a subset of important knowledge; specifically, how these different number bases correspond up to a common value (we'll go for 15, or 0xF in hex).

I've drawn the following table on the board in various classes; it is a good thing to be able to produce on your own, and to memorize its contents (especially how they relate to one another).

Your task is to write a script that calculates and outputs the following:

lab46:~/src/unix/eoce/0x4$ ./0x4
+===============================================+
|  binary  |  octal   |  decimal  | hexadecimal |
| (base 2) | (base 8) | (base 10) |  (base 16)  |
+===============================================+
|   0000   |   000    |     0     |     0x0     |
|   0001   |   001    |     1     |     0x1     |
|   0010   |   002    |     2     |     0x2     |
|   0011   |   003    |     3     |     0x3     |
|   0100   |   004    |     4     |     0x4     |
|   0101   |   005    |     5     |     0x5     |
|   0110   |   006    |     6     |     0x6     |
|   0111   |   007    |     7     |     0x7     |
|   1000   |   010    |     8     |     0x8     |
|   1001   |   011    |     9     |     0x9     |
|   1010   |   012    |    10     |     0xA     |
|   1011   |   013    |    11     |     0xB     |
|   1100   |   014    |    12     |     0xC     |
|   1101   |   015    |    13     |     0xD     |
|   1110   |   016    |    14     |     0xE     |
|   1111   |   017    |    15     |     0xF     |
+===============================================+
lab46:~/src/unix/eoce/0x4$ 

By “calculates and outputs”, I mean:

• you are not just to have fixed literal lines that you are displaying.
• you must calculate each value, and you must do so using variables, if statements, and loops.
• you can use pipelines to commands, but I do not want any calculators used (sorry, no bc).
  • you may use simple iteration, as provided via the bash let keyword
• You are managing the progression of numbers on your own!

Your script should produce the table, resembling mine as closely as possible.

Provide your script here:

During some standard time between now and 02:14:59pm (that's 14:14:59 in 24-hour time) Thursday, May 12th, 2016, you are to approach me to perform an in-person knowledge assessment. This is to help ensure consistency and validity of the other work you are performing on the EoCE (which of course you are following the rules and doing it all yourself with no outside help).

Valid times include any remaining class or office/lab hours with no structured/scheduled activities, or any of the finals week availabilities.

Note that you only have a single opportunity to take this (no make sure you allocate yourself an adequate amount of time).

Pro tip: Don't wander in 30 minutes (or similarly time deficient) before a deadline and expect an extension/more time to work on it.

When ready, please proceed: UNIX IPKA

Answer me the following:

• Of all the work you've done this semester in this course, identify something that was meaningful to you. What is it?
• Why does it stick out in your mind? Explain.
• How did you feel about the course?
• Was it useful/interesting to you?
• What was your least favorite aspect, and why?
• Any comments, suggestions?

After an exciting and intellectually challenging run, we're arriving at the end of this semester's journey. Some will be moving on, others sticking around for more. I make it a practice to listen to your thoughts and suggestions. The course, as we all experienced it, unfolds in a manner pertaining, in part, to how you respond to concepts and topics (do we need more time, can I crank it up a couple notches, etc.) so each semester and each class is entirely different from any other- because of each of you, and all of us, working together and learning together.

So, searching deep down within your soul- balancing reason with emotion, and considering attendance and timeliness; what grade do you feel you deserve for this course, and why? Justify your answer based on your own perceived performance to course ideals and content, not on need or desire.

All responses to questions, unless specifically indicated otherwise, should be addressed on this document (or the intended wiki document).

Please edit the appropriate section and provide the necessary information.

For any other deliverables, if using a project directory tree you can obtain a copy of, when ready, submit it using the Makefile, as follows:

lab46:~/src/CLASS/eoce$ make submit
...

If no formal project, you can submit requested files (preferably in an archive of their own), using the submit tool. A project called eoce has been likely set up for this purpose.