======Part 2======

=====Entries=====
====Entry 1: October 3, 2012====

Today we learned about fixing file names that have spaces. 

In Unix white space is an argument separator. Therefore a file named: the best file.txt will cause issues when you try to run a command on it. 

There are three main ways to fix or run command on the file.
1. Use Quotes. Put the file name inside quotes. 
Example:  "the best file.txt"
2. Use the Wild Card
Example: cat the*
3. Use the whack (\). It is an escape character that disables the whitespace or character following the whack.
Example: cat the\best\file.txt

Other uses for whack (\):

\n  //new line character//

\b  //backspace//

\t  //tab//


====Entry 2: October 19, 2012====

Today we were given **Tools to Fix Problems**, i.e we learned how to kill processes!

By the act of running a program, you create a process or an instance (copy of program in memory that is running) of that program.  You can see what processes **you** have running by using the ps command.

<cli> lab46:~$ ps </cli>


  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  ks010285  6609  0.0  0.1  13636  2024 pts/32   SNs  13:53   0:00 -bash
  ks010285  6684  0.0  0.0  10360   992 pts/32   SN+  14:28   0:00 less
  ks010285  6918  0.0  0.0  13664   348 pts/17   SNs+ Sep21   0:00 /bin/bash
  ks010285  7321  0.1  0.1  13628  1952 pts/33   SNs  15:21   0:00 -bash
  ks010285  7324  0.0  0.0   8588   984 pts/33   RN+  15:21   0:00 ps u    
  ks010285 11118  0.0  0.0  13596    20 pts/52   SNs  Aug29   0:00 /bin/bash
  ks010285 11233  0.0  0.1  42436  1704 pts/52   SN+  Aug29   8:08 irssi 
  

ps aux will give you **all** processes running on a system regardless of user.  

<cli> lab46:~$ ps aux </cli>

The top command will show the most active processes running on a system. 

<cli> lab46:~$ top </cli>
  
Once you have identified a process by its PID, you can run any number of commands on that PID including the kill command which will terminate processes in different manners. 

  kill -1 will terminate a process nicely, closing any files if necessary
  kill -2 will interrupt a process. Similar to Control C
  kill -9 should be used sparingly as a last resort when process isn't responding to other commands. 


====Entry 3: October Day 24, 2012====

Todays class lecture was very helpful as we explored the use of regular expressions, and my confusion as to when to use regular expressions and when to use wildcards was resolved. 

Wildcards are used for pattern matching outside of a file.  Regular expressions are used for pattern matching within the file.  

**Basic Regular Expressions**

Important!
Put regular expression pattern in '   '. 

(grep, vi, sed and regular expressions go together.

  ^  - match beginning of line

  $  - match end of line

  \< - match beginning of word

  \> - match end of word

  .  - match any single character

  %%*%%  - match 0 or more of the previous

  [ ] - character class - match any of enclosed

  [^] - inverted character class - do not match any of enclosed

Examples:

  'and'    : all lines that have this pattern somewhere in word

  '^or'    : all lines that start with or

  '^[Oo}r  : match beginning of line that has either upper O or lower o

  '^[Oo]r.*e$ : match beginning of line w/ upper or lower Or, 0 or more of any character, and ends with    lowercase e. 

  '^[^aeiouy].*g.*[es]$'  : do not start with a lowercase vowel, have a 'g' somewhere and end with a 's' or  'e'. 

  '...k'      : at least 4 characters end with a k. 


**Extended Regular Expressions**

In order to use extend regular expressions, you need to use the egrep command. 

  () - grouping   with see command, there are \( \) there are backslashes around parentheses. 

  |  - or
 
  +  - match 1 or more of the previous

Examples: 

  lines ending in ing or ed:     egrep'(ing|ed)$'    or '(ing$|ed$)'   or  '^.*(ing|ed)$'   or 'ing$|ed$'


**Patterns:
Its important to be observant of one word per line patterns.**

**Common Debugging Strategies**

The following are variables: 

  {0}
  {0#**/} 
  
If you want to find out what is in a variable you can echo the variable in your script.  i.e. 

<code> echo ${0} </code>

 

 



====Entry 4: October 25, 2012====

Today we put into practice the regular expressions that we learned on Wednesday.  We created a command line script to grab course information from a previously saved 2013 course html file from the CCC website.  

The first step was to view the html file, therefore we performed the cat command on the file. 

<cli> lab46:~$ cat 2012courselist | less </cli>


By recognizing patterns within the html code, we were able to identify key pieces of the code that were necessary for pattern identification for our next command.  As the line that contained the course information began with <TH CLASSS="ddtitle", we used the grep command and the regular expression **^** (line begins with identifier) to grab all of the lines that contained course information. In order to view the information in a page like environment, we piped the "grepped" file to less. 

<cli> lab46:~$ cat 2012courselist | grep '^<TH CLASS="ddtitle"' | less </cli>

This produced all the html lines that began with <TH CLASS="ddtitle".  As this list was still messy, we cleaned up and formatted the list by using the sed (string editor) command.  

A few key points about the sed command:

  * sed 's/  /            Search for all lines containing this pattern, between forward slashes
  * /  /g'                replace all lines with the whatever is between forward slashes.
  * %%//g' %%             replace all lines with nothing.  

As we were only interested in the course numbers and course names from these html lines, we used the sed command to get rid of all the information before the course name, by identifying the portion of the line that came before the course name with following regular expressions: 

  * ^                beginning of line 
  * .                any single character 
  * %%*                0 or more of the previous (any single character)%%
  * crn_in=.....">   the characters crn_in= , followed by 5 any character symbol, and the character " and >. 
  * %%//g'%%         nothing replacement pattern


<cli> lab46:~$ cat 2012courselist | grep '^<TH CLASS="ddtitle"' | sed 's/^.*crn_in=.....">//g' </cli>

We cleaned up the list further, by deleting the "garbage characters" at the end of the line with the following regular expressions:  


  * $   match everything before this symbol at the end of the line 

  * %%//g'%% replace with nothing


<cli> lab46:~$ cat 2012courselist | grep '^<TH CLASS="ddtitle"' | sed 's/^.*crn_in=.....">//g'| sed 's/<\/A><\/TH>$//g' | less </cli>

Finally, in order to change the order of the information on the line, the following command line argument was written. By identifying groups between the dashes within the original pattern, the groups were able to be replaced once again by using the sed command.


  \1		\2		\3			\4 

  Title		 -CRN		-CRSE   NUMBER		-SEC

CRSE NUMBER-SEC:CRN:Title



<cli>
lab46:~$ cat 2012courselist | grep '^<TH CLASS="ddtitle"' | sed 's/^.*crn_in=.....">//g' | sed 's/<\/A><\/TH>$//g' | sed 's/^\(.*\) - \([0-9][0-9][0-9][0-9][0-9]\) - \(.*\) - \([0-9]*\)$/\3-\4:\2:\1/g' | less
</cli>






=====Keywords=====

{{page>unixpart2&nofooter}}

=====Experiment 2=====

====Question====
Is it possible to make a script executable when you create it (at inception) rather than having to change the permissions after you write it?

====Resources====
I discussed the possibilities with Professor Haas, and we worked to create a script that will set the permissions of the file at the creation of the script. 

====Hypothesis====
I would have to surmise that it is most definitely possible to create a script executable upon initial creation. 

Despite the fact that I was told that it was possible by a very reliable source, it was my gut instinct that with the endless possibilities involving scripts and command line arguments, that there must be some way to set permissions. 
====Experiment====
I am going to write a script that includes the steps to create and set permissions of a file. After I have written the script, I am going to run the script and test out the results. 

  Step 1:  Create a script named mkscript.sh
<code>
  #!/bin/bash
  #
  #set the permissions of an executable script

  if [ ! -z "$1" ]; then
	touch $1
	chmod 700 $1
	vi $1
  else
	echo "Enter name of file to be created with mkscript"
  fi
</code>

  Step 2:  Set the permissions on the mkscript.sh to executable

  Step 3: Executed mkscript.sh and enter a file name to be created. 


The if statement of the script tests to make sure that when the mkscript.sh is executed, that a file name is given for the new file. If not, it prompts the user to enter a file name when executing the mkscript.sh. Once a file name is entered, script creates the file, changes the permissions to executable, and opens the file in vi for editing. 







====Data====


1. Ran script without entering a file name

<cli> lab46:~$ ./mkscript.sh
Enter name of file to be created with mkscript
</cli>
  
2. Ran script including a file name
  
<cli>
lab46:~$ ./mkscript.sh testfile
</cli>
  
3. vi opened automatically. Wrote a short script in the file and then saved and closed.

<code>
  #!/bin/bash
  #
  #testfile from mkscript

  echo This is a test to see if my experiment worked!!!!
</code>

4.  Ran the file command on the testfile
<cli>
  lab46:~$ file testfile
  testfile: Bourne-Again shell script text executable
</cli>

5. Executed the testfile
<cli>
  lab46:~$ ./testfile
  This is a test to see if my experiment worked!!!!
</cli>
====Analysis====
Based on the data that I collected, my hypothesis is correct. It is possible to set the permissions of a file at inception through the use of another script file. 

====Conclusions====
Through the use of scripts, you can streamline any repetitious task.