User Tools

Site Tools


opus:fall2011:ccaccia:part1

Part 1

Entries

September 1, 2011

LOL

Today I learned how to enter the email client called “Apline”. I would say that it is a very simple email program, that once you have learned some basic's is very easy to navigate. I struggled with entering the proper commands and then also found it difficut to move back to the menu after entering my inbox. Once I understood the basic keyboard shortcuts for composing messages, sending messages, and viewing messages I was off and running. I also tested the email client for delivering mail outside of the Lab46 network, and sending a message to my inbox from home. Both email test's were sucessfull in reaching there destination.

This was significant for me because accessing my class email is a productive and usefull task.

September 8th, 2011

Today I spent some time on the “man” or manual command. I have found this to be one of the most useful tools when casting spells with UNIX. With so many command prompt possibilities in UNIX it is impossible to memmorize all of the commands and flags. The manual command will open a help screen for that specific command, show you how it is entered, and will also list all of the flags and definitions pertaining to the command you have entered. To execute this command you simply type “man”(space)“command”; for example, if I wanted the manual page for the listing command (ls), I would enter the command as you see below.

lab46:~$man ls

If I wanted to learn more about the command “cat”, I would type the following:

lab46:~$man cat

When bringing up the manual page on a particular command it will define the command, list and define all flags associated with the command, give you a detailed description of the command, and also tell you the correct layout or proper use of the command.

I did find it challenging to sometimes understand the proper format for executing commands as expained in the manual, but I believe that to be more of an issue with my lack of paitence. This is probably one of the most important or significant commands available to the user. It's most significant use to me would be that with this command I do not have to memmorize all flags associated with each individual command. The “man” command is a huge resource at your fingertips and available at anytime.

September ,26th 2011

Today I learned the basic's of Shell Scripting in UNIX/Linux using the “vi editor”. Using “vi” the class wrote a shell script that converted Decimal base 10 to Binary base 2. Although I cannot recall from memory all the programming commands that made this possible, I was able to understand the process of making the progam do what we wanted. This was significant to me because I thought it was really exciting to brainstorm an idea, and implement that idea to code format via Vi text editor. It was also very exciting to see that the script we wrote worked and converted numbers perfectly.

September 29th, 2011

Today I learned about creating a chat bot through a Vi Text Editor, shell script. Creating a bot to communicate with other users on the chat forum is significant to me because you are communicating directly with a computer, via a pre-defined program script. It almost seems as if the chat bot has artificial intellegence and is communicating with you independently. I personally seem to be a little overwhelmed with the code syntax required for writing a shell script, but I am getting better every time I use it. Eventually I would like to further develop my chat bot as a project for the class.

Topics

Part 1:                                                             Part 2:                                                Part 3:
1.) Listing                         7.) File Types                  1.) Vi Text Editor               7.) Job Control       1.) Compiler                  7.) C       
 
2.) Remote Host                     8.) Regular Files               2.) Insert Mode                  8.) Tab Completion    2.) Regular Expression        8.) Compressing/Decompressing
 
3.) Killing a process               9.) Directory Files             3.) Command Mode                 9.) Viewing           3.) Ownership                 9.) Shell Scripting
 
4.) Local Host                     10.) Pseudo Files                4.) Foregrounding a process     10.) The Unix Shell    4.) Permissions               10.) Text Processing
 
5.) Home Directory                 11.) Removing Files              5.) Multitasking                11.) Copying           5.) Moving/Renaming           11.) Object Code
 
6.) Current Working Directory      12.) Backgrounding a process     6.) Signals                     12.) Creating          6.) VI Extended Command Mode  12.) Linker
 

Keyword 1

Listing:

The list command allows the user to see the names of files and subdirectories in your current working directory. The command for listing is represented by the abreviation “ls”. When using list in UNIX/Linux you can also apply some flags to the listing command. Flags are commands typed in after the list command that will provide specific information taylored to your needs. I have noted most of the “ls” command flags below. The first block defines each flag, and the second block shows the commands as they would be typed at the command prompt.

ls -l --> Lists in long format and provides much more information
ls -a --> List's all files
ls -s --> Gives the size of the files
ls -t --> Sorts files by the time modified rather than by file name
ls -f --> Marks directories with a trailing slash, and executable files with a trailing asterisk
ls -r --> Recursively lists subdirectories
lab46:~$ls -a
lab46:~/ls -s
lab46:~/ls -t
lab46:~/ls -l
lab46:~/ls -f
lab46:~/ls -r

Keyword 2

Remote Host:

Remote Host's are computers that are not accessed by end-user's directly, but instead are accessed from a different location, via the internet. In most casses remote host's are referred to as servers. A servers primary role is to store data that can be retrieved from a end-user, or multiple end-users, through a remote connection over a network. A remote host can also be a user's computer that is accessed over the internet for purposes such as remote control operations, and file transfers. For a computer system to be considered a “Remote Host” it has to have some software that provides the structure or protocol for a browser based working enviroment, such as a server based operating system, or a application process that establishes a remote connection to another PC.

For example:

From my home in Horseheads, I can access Corning Community College's Lab46 UNIX/Linux terminal. I have to run application software, like Putty, on my computer in order to log on to the Lab46 server. Putty is a software system that provides a UNIX/Linux based shell or working enviroment that will allow me to communicate remotely to the College's UNIX/Linux server. Once connected to the server, Putty will allow me to access or “retrieve” data over the internet, and without being anywhere near the college's direct network. In this scenario, both computers, once connected could be considered a Remote Host.

Keyword 3

Killing a Process:

The “kill” program in UNIX/Linux is a very powerful command that can send a signal to a process or terminate it entirely. Programs by nature will constantly run until the user commands the program to stop, or the program finishes its task. However, sometimes a program will freeze up and not allow the user to communicate through the keyboard. Usually executing a “^C” (Ctrl C) or typing “quit” at the command prompt will send and interrupt signal to the running process and terminate the program. In some cases a running program may encounter a error and freeze any input from a keyboard. In this situation executing “^C” or typing “quit” at the command prompt will not work. This is one time where the “kill” command will be useful. Terminating background processes is also another useful way to use the “kill” command. Background processes do not read or accept commands from the keyboard and the background program cannot be accessed directly. This situation is very common and a great exercise for the “kill” command. To kill a process you first have to determine what the “PID” or Process ID is. This can be done by typing the “ps” command at the prompt. This command will list all running currently running processes, and also display's the PID number. Once you have located the PID number of the process you want to kill you would then type, at the command prompt, kill [PID].

This is an example of how it would look at the command line:

lab46:~$ ps
User     PID   %CPU %MEM   VSZ   RSS   TTY     STAT  START  TIME  COMMAND
ccaccia  23078  0.0  0.1  13668  2044  pts/60   SNs  Sep27  1:11   irssi
lab46:~$ kill 23078
lab46:~$ ps
User     PID   %CPU %MEM   VSZ   RSS   TTY     STAT  START  TIME  COMMAND

lab46:~$

Typing the command: “kill 23078” would kill or terminate to process running on PID# 23078 as seen above.

Keyword 4

Local Host:

Local hosts are the computers that a program or application is physically running on. For example, if you're at home on your PC and open your web browser your machine is considered to be the local host because you are running the application on the same machine. Local hosts, like remote hosts, are identified by their IP address. The IP address for a local host is always “127.0.0.1”. The reason for this is because the 127.0.0.1 IP address is considered to be a “loopback” address. Any data or information sent to it will be routed directly back to the local machine.

Keyword 5

Home Directory:

The home directory is a directory that contains files for a specific “userid”. When logging into the UNIX/Linux server, by default you are put in your home directory. Therefore you can say that the home directory is by default your current working directory as soon as you login. If you “cd” into a different directory then you are moving out of your home directory and the new directory you have entered then becomes the current working directory. At anytime, if you want to get back to your home directory, simply type the command “cd” without a following directory name and you will be taken back to your home directory.

lab46:~$ pwd
/home/userid ----> (default Home Directory)
lab46:~$ cd bin
lab46:~/bin$ pwd
/home/userid/bin ----> (new current working directory)
lab46:~/bin$ cd
lab46:~$ pwd
/home/userid ----> (back to default Home Directory)
lab46:~$

Keyword 6

Current Working Directory:

The current working directory is defined as the “default” directory used as a command line. To change your current directroy you have to type the command “cd” (change directory) followed by the directory name you want to enter. To display the current working directory you enter “pwd” at the command line, which will list the name of the directory you are currently in. UNIX/Linux is a hierarchical file system. This means that all directories and files are created from a default home directory and are built from there. In the example below I have shown what happens when you display the current working directory and also change it. To return to the default root directory simply entering the command “cd” by itself will take you there.

lab46:~$ cd tmp
lab46:~/tmp$ cd bin
lab46:~/tmp/bin$ pwd
/home/userid/tmp/bin
lab46:~/tmp/bin$ cd
lab46:~$

Keyword 7

File Types:

A file is defined as “Any source, with a name, from which data can be read”. A file in UNIX/Linux is the core of it's exsistance. Everything as related to UNIX, is a file. There are three basic file types in UNIX/Linux, a regular or ordinary file, a directroy file, and a special or pseudo file. UNIX is a hierarchical system of files, some files are stored as text, some files are designed to be executed, and some files serve a purpose for a specific program or process. Reguardless of the purpose each file serves, I think it is important to understand that creating and deleting files

In UNIX you can determine what type of file you have by executing the ls -l command. Executing this command will bring up a list of all files in the working directory. The “-l” is added to the ls command because it will provide more information on that directory such as permissions and file types. When looking at the result of your ls -l command you want to look at the first position on the permission line. If it is blank (-) then you are looking at a ordinary or regular file, if it is a (d) or (l) then it would be a directory file, and anything else would be considered a special or pseudo file.

lab46:~$ ls -l
total 4 
lrwxrwxrwx 1 ccaccia lab46   17 Aug 28 10:37 Maildir -> /var/mail/ccaccia
drwxr-xr-x 2 ccaccia lab46 4096 Sep 29 16:39 bigdaddy
-rw-r--r-- 3 ccaccia Lab46    6 Sep 08 16:14 motd
crw-r--r-- 4 ccaccia Lab46    9 Aug 29 12:14 pseudo file
lab46:~$ 

The first digit of the permission line indicates file type. In this example I have surrounded the file type with a “(_)”. I have also cut out all data with the exception of the file permission.

(l)rwxrwxrwx  (l)= Link Directory File (Still directory)
(d)rwxr-xr-x  (d)= Directory File
(-)rw-r--r--  (-)= Regular or Ordinary file
(c)rw-r--r--  (c)= special or pseudo file

Keyword 8

Regular Files:

Regular files are the most common files and are also what most people associate with the word, file. Regular files consist of data that is written to some sort of storage device, like hard Optical storage disc's, or hard drive disc's. Regular files can also be broken down in to two types of files, text and binary files. Text files are lines of data containing language characters like letters, numbers, punctuation, symbols, spaces, and tabs. Binary files do not contain text based files, but instead, they contain data that only makes sense to programs, when executed. Binary files contain the computer instructions for executing a program, and text files would be the data stored as a result of the user accessing or editing a file within a specific program. For example: the program “vi text editor” is stored as a binary file, because it is a file that the computer has to execute to open a program. The binary file for the text editor creates the shell for the program to operate, and stores the text data a user creates or edit's while using the program. Once you have created a shell script or a few lines of notes, you then save the file you created or edited for later use as a text file. Files such as video, music, pictures, spread sheets are stored as Binary files because they rely on another program, or process to interpret and execute the file.

Keyword 9

Directory Files:

Directory files are the organizational tool for the UNIX/Linux operating system and create the infrastructure of the Hierarchical filesystem. These files do not contain or hold regular data, but instead are used to access and organize other files. Along with organizing and accessing the file system, directory files can also exist within each other. Directory files can be created and deleted by the end-user depending on their specific needs. Directory files could be viewed as houses in a neighborhood, each house contains data for a specific purpose and is then organized for access by programs, processes, or end-users. This is repeated for each house in the neighborhood, some houses contain device files, some contain regular files, some contain special files, and some contain more directories with files or another directory inside of them. Each house in the neighborhood stores data for an specific purpose, and like houses are numbered, directory files are also assigned names for identification later. In my opinion, I feel directory files are the bone structure to the entire UNIX/Linux system. Without this file type all data stored in an operating system would be un-organized and difficult, if not impossible, to access quickly when needed.

Keyword 10

Pseudo Files:

Pseudo files are very unique to the UNIX/Linux operating system. As discussed earlier in my opus, both Regular files and Directory files house data on a storage device. Because they hold data they will vary in size. Directory files in particular could require a lot of space on a storage device because they contain regular files, Pseudo files, and other directory files. Pseudo files, on the other hand, do not require much space on a storage device because they do not “store data”. These types of files, in most cases, are designed to communicate directly with the kernel of a computer system. Pseudo files exist to provide a service for a physical hardware device, such as a keyboard, printer, monitor, and hard drives. Pseudo files consist of many different types of files. A device file, or special file for example, is the software's representation of a hardware device in, or connected to the computer system. Another type of pseudo file is called a “named pipe”. Theses file types allow you to connect the output of one command or process to the input of another. The last pseudo file type I will mention is a “Proc File”. A proc file is designed to allow the user to view and sometimes edit data within the kernel. Proc files allow for direct communication and translation between computer's device processes, and the end-user.

Keyword 11

Removing Files:

Removing files in the UNIX/Linux system depends on the file type your removing. Directory files require a specific “remove” command that is slightly different from removing other file types. To remove a directory you will need the command, “rmdir”, which is short for “remove directory”. Removing all other file types requires the UNIX/Linux command, “rm”, or “remove”. There is a particular format that needs to be followed in order remove a file. At the command line prompt in UNIX you have to follow correct syntax by typing the command, followed by a space, then an “option” (if needed), then the name of the file type you want to remove. Adding an option after the command will allow you to specifically remove certain parts of files within a directory. In the manual page for removing files the syntax format is listed as: rm [OPTION]… FILENAME or DIRECTORY. Options are not a necessary requirement for removing a file, however, using an option can remove files, tailored specifically to your needs. In the example below I have displayed the process for removing a regular file, and also a directory.

lab46:~$ ls
Maildir  bigdaddy  bin  closet  irc
lab46:~$ cd bin
lab46:~/bin$ ls
test
lab46:~/bin$ rm test
rm: remove regular file `test`? (y)
lab46:~/bin$ cd
lab46:~$ ls
Maildir  bigdaddy  bin  closet  irc
lab46:~$ rmdir bin
lab46:~$ls
Maildir  bigdaddy  closet  irc
lab46:~$ 

sadf

Keyword 12

Backgrounding a Process:

Running programs in UNIX/Linux is a process of reading input from a keyboard and then writing the output to a monitor. This is a process UNIX/Linux describes as reading from stdin, or standard input, and then writing to stdout, or standard output. Most command based programs in UNIX are processed sequentially, or the command is input and the user is left waiting for that command to execute to standard output before you can type another command. Programs that run this way are called Foreground processes, meaning they run in the foreground and need to complete execution before moving on to another command. In most situations this is the type of environment a end-user will operate within. However, sometimes programs take a long period of time to execute and complete a commanded task. Rather than wait for the program to write to standard output, you can send the program to the background, to finish it's task. This allows the end-user to continue with another command in the foreground, while the computer executes the original program in the background. This is a very powerful tool in UNIX because it essentially allows you to multi-task in a command based operating environment. Once the original program completes it's assignment it will then send the result to standard output and appear on your display. As a end-user it is very important, when running background processes, to be alert as to when the standard output is sent to the monitor because it will appear on your UNIX terminal, mixed in with whatever commands you are currently working on in the foreground. To send a program to the background to execute you need to add a “&” (ampersand) to the end of the command. Providing the command was entered properly, the process will be sent to the background for completion. At times a background process may produce a standard error because it's trying to read from standard input, which does not exist in a background process, and may pause indefinitely waiting for the end-user to input the required data. The only thing possible in this situation would be to bring the background process to the foreground. This can be completed by using the command “fg %(job#)”. Once this command is executed the selected background process will be moved to the foreground, and then be available for standard input.

As a side note, if you're not sure if you have a background process running you can type “jobs -l” at the command prompt and the system will display to output what current processes are running in the background.

Below I have displayed an example in the UNIX environment for sending processes to the background, listing all processes currently running in the background, and then bringing the background process to the foreground. I will be executing a chat bot program, and then sending it to the background to process so I can continue with another command. Once I have completed the multi-tasking I will then bring the background process back to the foreground.

lab46:~$ ls
Maildir  bigdaddy  bin  src  motd  closer  public_html 
lab46:~$ cd bigdaddy
lab46:~/bigdaddy$ ls
bigdaddybot.sh  script1.sh  script2.sh  script3.sh  notes  commands
lab46:~$ ./bigdaddybot.sh &
[1] 6599
lab46:~/bigdaddy$ pwd
home/userid/bigdaddy
lab46:~/bigdaddy$ jobs -l
[1]+ 6599 Running    ./bigdaddybot.sh &
lab46:~/bigdaddy$ fg %1
./bigdaddybot.sh
^C  --> The bot is on a continuous loop and will run until ^C is entered
lab46:~/bigdaddy$ jobs -l
lab46:~/bigdaddy$

Objectives

Objective 1

Create an executable program what will launch me into my Alpine e-mail client without typing “alpine” at the command prompt. I would also like this executable program to be password protected.

Method

Using Vi Text Editor, create a shell script titled, “e”, that resides in my home directory and when executed, will take me directly to my Alpine inbox.

Measurement

Use shell script command code to create a password to access my Alpine email client. Using “if” and “fi” statements to provide or deny access to Alpine email inbox. If access is accepted you will be sent to Alpine immediately, if you mistype your password, you will be prompted to enter it again. Failing to enter the password correctly a second time will result in a “Goodbye” message and the program will terminate putting you back to the home directory command prompt.

Analysis

It took some time to understand the “if” and “fi” but success was ultimately achieved. The program works perfectly, entering the correct password at the first prompt will launch you into Alpine. Entering in incorrect the first time will prompt you to enter again. If the second password entry is correct you are taken to the Alpine login, and if entered incorrectly you will see a statement telling you “Access is denied…GOODBYE”. Failure to enter the correct password after the second time will terminate the program and put you at the command prompt of your home directory.

There is definitely room for improvement here! When successfully routed to the Alpine e-mail client you are prompted to enter your alpine password as well. It would be nice to have the shell script insert that password for you, being that you already entered a password when prompted by the shell script. I named the file “e”, for e-mail, to shorten the time you would normally use to enter in the six characters of “Alpine”. When executing the program in your default home directory the command to launch the script is: ( ./e ), reducing the number of characters from six to three.

For this example the correct password = tom

lab46:~$ ./e
Please enter your password: c
Access Denied

Please enter your password: cab
Access Denied.... GOODBYE
lab46:~$
lab46:~$ ./e
Please enter your password: t
Access Denied

Please enter your password: tom
Access Granted
Welcome "userid"... routing you to Alpine email client:

(Alpine login password:  ---> Opens Alpine home page)

lab46:~$

Experiments

Experiment 1

Question

How do I move a file from the current working directory to my home directory?

Resources

mv manual page, built into UNIX

mvdir manual page, built into UNIX

Hypothesis

According to the manual page on the mv or move command, when moving files from the working directory to the home directory, at the command prompt you will need to type “mv”… “filename” … “destination directory” and then press enter.

Experiment

I am going to test my hypothesis using a program called “Putty” which, will provide a UNIX/Linux environment to execute the mv commands. I will create a directory file called “testdir” and a regular file named “test” within my created directory. First I will move the “testdir” to my home directory, then will move the file “test” from within the testdir to the home directory. Upon completion both the testdir and the file test should reside seperatly in my home directory.

Data

Process worked well. I created a directory called “testdir” inside of another directory called “closet”. I changed directories to “closet” and typed the “ls” command to make sure the testdir was there, and it was. I typed the following in: mv testdir /home/ccaccia, and the move was sucessful. I changed directories back to my home directory and typed the “ls” command to view the files. Sure enough the directory testdir was now in my home directory. At the command prompt I then typed: mv /testdir/test /home/ccaccia, this moved the test file from my testdir directory to the home directory. I again typed the “ls” command at the home command prompt and both “testdir” and “test” where now seperated in my home directory.

Analysis

Based on the data collected my hypothesis was correct and worked well. There were no shortcomings in the experiment that I noticed.

Conclusions

Moving directory files or regular files in UNIX/Linux is really a very easy process. While performing the experiment I did learn that you do not have to “cd” into a directory if you want to move a file out of that directory. Simply typing in the “directory/file” would move that file from within the directory to the destination directroy, saving me a step.

Experiment 2

Question

How do we view a text file in UNIX/Linux

Resources

http://www.math.utah.edu/lab/unix/unix-commands.html

cat manual page within UNIX library

Hypothesis

Based on what I have read, to view a text file in UNIX/Linux, at the command prompt you type: cat “filename”. This standard input should take that text file and print it to standard output on my monitor.

Experiment

I am going to test this experiment using a ssh shell program called “Putty” from home to access the UNIX/Linux server. Once logged on to the server I will use the UNIX command environment to perform the experiment.

Data

lab46:~$ls
Maildir  bin  e  motd  src  test  tmp  bigdaddy
lab46:~$ cat test
This is a test.
This text file was created by yours truly, for purposes of casting spells in UNIX
I am now a full blown cat slayer

lab46:~$

Analysis

Based on the data collected, my hypothesis was correct! Bingo, bango, bongo…

Conclusions

This really was a very basic experiment. I find in incredible that by simply typing the word “cat” followed by a text document will send to standard output a copy of a text aquired through standard input. Like I said… really basic, but really neat as well.

Experiment 3

Question

Can I change the file permission on a directory I created, and will that also change the file permissions for text files within the directory?

Resources

Hypothesis

Based on what I have read I should be able to change file permissions for directories and regular files. According to what I have read, I will not be able to change the permissions in a file by changing the permission of the directory file it is in. However, I should be able to change the permissions for a file within a directory, while in my home directory. I should not have to “cd” into the directory that contains the file.

Experiment

I am going to test this experiment by loggin on to the UNIX/Linux server and applying my theory. I plan on changing a file permission of a directory, then through “ls -l” review the file permissions for regular files within the directory to see if they automaticaly changed as well. Then I will try and change the file permission for a file within a directory that is not my current working directory.

Data

lab46:~$ mkdir testdir
lab46:~$ cd testdir
lab46:~/testdir$ touch test
lab46:~/testdir$ touch test2
lab46:~/testdir$ ls -l
-rw-r--r-- 1 ccaccia lab46   0 Sep 15 14:15 test
-rw-r--r-- 1 ccaccia lab46  10 Sep 15 14:15 test2
Lab46:~/testdir$ cd
lab46:~$ chmod 777 testdir
lab46:~$ cd testdir
lab46:~/testdir$ ls -l
-rw-r--r-- 1 ccaccia lab46   0 Sep 15 14:15 test   --> File permission did not change
-r--r-- 1 ccaccia lab46  10 Sep 15 14:15 test2  --> File permission did not change
lab46:~/testdir$ cd
lab46:~$ chmod 777 testdir/test
lab46:~$ cd testdir
lab46:~/testdir$ ls -l
-rwxrxxrxx 1 ccaccia lab46   0 Sep 15 14:15 test ---> File permission **did** change!
-rw-r--r-- 1 ccaccia lab46  10 Sep 15 14:15 test2
lab46:~/testdir$ cd
lab46:~$

Analysis

The hypothesis was correct! I was not able to change file permissions for a directory and that change also be made for the regular files within the directroy. I was however able to change the file permission for a file not in my current working directory.

Conclusions

I really enjoyed this experiment. It really helped me see what I could and could not do when it comes to changing file permissions.

opus/fall2011/ccaccia/part1.txt · Last modified: 2011/11/30 23:46 by ccaccia