======Part 1====== =====Entries===== ====Entry 1: January 28, 2012==== Today I completed the first set of assignments for the class. Due to the fact that the class is only beginning, the lab section was intended to mostly explain how to perform basic actions that are needed to work in the Unix environment. Some of the essential commands needed to start using Unix are the commands to list the files within a directory, copy a file, remove a file, and move a file. Most Unix commands can also be used with special options that provide additional functionality when using the commands. This feature brings up another important feature of Unix commands, which is how to access the manual pages for the different utilities. A manual can be viewed by entering the “man” command followed by the name of the command you are looking for information on. The lab makes note of an interesting detail in Unix, which is that unlike DOS there is no rename command. If the move command is given a source file and a destination that is another file name that does not exist, Unix will recreate that file under this name. Although this is not the purpose of the command that is implied by its name, this effectively works the same as a rename command. For this reason, giving Unix a rename command would be redundant and would provide no additional functionality. I find it interesting that Unix seems to be designed to offer small powerful tools that can be used in creative ways to get the results that the user is looking for. ====Entry 2: February 3, 2012==== Today’s lab focused on the topic of file and directory management within Unix. While I am new to Unix, I am happy to see that for the most part navigating through the directory is the same as it is in DOS. I would by no means consider myself especially proficient in DOS, but I have a good understanding of how to use the directory and this knowledge applies to Unix as well. The cd command is used to change to new directories and can be used with either relative or absolute pathnames. The notable difference that I have seen with Unix is that each file has a set of permissions that can be changed using octal or symbolic values. While this feature may be confusing at first if the concept is new, I felt that this was actually a fairly intuitive and powerful way of dealing with file permissions. Permissions are an important attribute of all files on a system and greatly affect how resources and the system itself are used. The chmod command is an easy way to assign permissions to each file and the –l option on the ls command is a good way to determine the source of the problem if a user is unable to access a file. As per the instructions in the lab, I have made an ASCII tree that shows the location of my home directory on Lab 46 and some of the files and directories that are contained within it. /(root) | home | rhensen | -------------- | | | Maildir bin src | ------------------ | | | lab1.file submit unix ====Entry 3: February 17, 2012==== This week’s lab focused on different elements of the Unix shell, which provide insight into how to effectively work in the Unix environment. Unix makes use of hidden files, which are identified by having a dot (.) in front of the file name and can be displayed by using the –a option with the ls command. Knowing how to access hidden files can yield some useful results as is the case with the .signature file (which holds text that will be added to the end of every email you send) and the ~/.bash_history file (which contains the history of previous command the user has entered, even from previous sessions). Other useful features that were explored were variables and command aliases. Variables are used to reference data that is in memory and are specified using the dollar sign ($) character. Aliases are a way to set a command to use certain options automatically. For example, the ls command does not automatically classify different file types by color. A special option is needed to do that, which is added automatically whenever the ls command is used because it is set in the alias. A case study was also given which shows how to deal with files that are named in ways that make them difficult to use in Unix. For example files that contain spaces, dollar signs, or wildcard characters will have these characters interpreted as such rather than as part of the file name. This exercise was useful for showing different ways around these bad names. ====Entry 4: February 24, 2012==== The lab for this week further explored some fundamental concepts of the Unix shell. The major concepts covered by this lab are wildcards, I/O redirection and piping, pagers, and different uses of quotes. Wildcards are used to match characters for a command. This is especially useful with the ls command in order to display certain types of files. Wildcards can be used to match a certain number of characters, specific characters, or to exclude specific characters. A single character is represented by a question mark (?), zero or more characters are represented by a star (*), and specific characters can be entered between brackets ([]). I/O redirection can be used to manipulate the input and output data streams in order to send this information somewhere else. Piping is the process of using the output of one command as the input for another, which allows the user to perform complex tasks which cannot be done with just one command. Pagers are utilities that can be used to scroll through the output of commands that produce more output than can be read all at once. Pagers can be used with piping so that the pager utility is being performed on the output of a certain command. The two pagers explored are the more and less utilities. The more utility allows more of the output to be displayed when the space bar is pressed, whereas the less utility opens up the output in a way that allows it to be scrolled through. The lab also provided a further explanation of the different uses of quotes. Single quotes (‘) tells Unix to interpret all symbols as characters and to assign no meaning to characters such as spaces or dollar signs. Double quotes (") are less strict and allow variable names and commands to be interpreted as such rather than simply as text. =====Keywords===== {{page>unixpart1&nofooter}} =====Experiments===== ====Experiment 1==== ===Question=== Is it possible for Unix to match wildcard characters in a file name when using wildcards? ===Resources=== No outside resources have been used for this experiment. ===Hypothesis=== In cases of files that are given unconventional names, it is possible for filenames to exist that contain characters such as * or ?. Since these characters are also used to represent wildcard patterns, I was wondering if there are ways to make Unix recognize these symbols as characters in a filename instead of wildcard symbols. I believe that Unix allows for at least one method of being able to find filenames that contain these characters when using wildcards. ===Experiment=== To perform this experiment I will create two files which I will name “?uestlove” and “ringo*”. I will then use the ls command with different wildcard patterns such as “?*” and “* *” (which I do not believe will work) as well as using different patterns that make use of single and double quotes as well as brackets (which I believe may yield the desired results). ===Data=== After performing the ls command using different variations of wildcard patters, I have determined that: * “ls ?*” and “ls * *” will display a listing of all of the files in the current working directory and display the files in all of the subdirectories. * “ls [?]*”, “ls ‘?’*”, and “ls “?”*” will all match the file called ?uestlove. * “ls *[*]”, ls *’*’”, and “ls *”*”” will all match the file called ringo*. * The command “ls *[?*]*” can be used to match both files in a single listing. ===Analysis=== Judging from these results, it is possible to match file names that contain wildcard symbols as characters in a wildcard pattern. This is not only possible to do, but there are several methods that can be used to make Unix interpret these symbols as characters. Unix is also robust enough to allow both of these characters to be matched in a single listing using brackets. The unexpected outcome of this experiment is the both the “?*” and the “* *” listing displayed all of the files in subdirectories as well. I have briefly attempted to researched why this is the case but have not been able to find much information on it. However, determining the reason for this seems to be outside the scope of this experiment. ===Conclusions=== The results of this test have shown that unconventional file names do not hinder the ability of Unix to match file names using wildcards. This demonstrates three methods that can be used to identify wildcard symbols as characters so that these characters can be matched. (Note: In writing up the experiment on this page "* *" is written with a space since this webpage did not seem to like when the two stars are used together without the space.) ====Experiment 2==== ===Question=== Can output redirection be used with aliases in order to easily create a log file from the output of a certain command? ===Resources=== This article was used to fine tune the method that I used after I was unhappy with the initial results. http://en.wikipedia.org/wiki/Tee_(command) ===Hypothesis=== A log file is sometimes useful to keep a record of the output generated by the output of a command. However, this is really only useful when the output is added to the log file automatically, which is why I believe the use of the alias will be helpful. I think that setting an alias for the ls command that will redirect the output to a file will effectively keep a record of each output that command generates. This is not to say that the ls command is the most useful command to have a log file associated with, but the method can hopefully be used with other command that better lend themselves to having a log. ===Experiment=== In order to set the alias for the ls command to redirect its output to a log file, the following command was used. lab46:~$ alias ls="ls >> /home/rhensen/log" The redirect and append option was used to redirect the output so that new output is added to the end of the log file instead of replacing the file’s previous contents each time there is new output. An absolute pathname is defined for the log file in order to avoid creating a new log file for each working directory that the command is used in. ===Data=== After setting this alias and using the ls command, the test worked as planned and the output was sent to the log file (this file will be created if it does not already exist). Also issuing the command again will append the output to the file instead of replacing it. Although redirecting the output to a log file works as I had hoped, this method leaves something to be desired since the output is sent only to the log file and cannot be displayed on the screen for the user to see. ===Analysis=== Since I was not entirely satisfied with the initial results of the experiment, I did some research into finding a solution that would allow the output to be displayed on STDOUT as well as sent to the log file. This research led me to a command called “tee” which allows output to be redirected to STDOUT as well as one or multiple files. I decided that the following command would yield the desired results. (Note: Since tee is a separate command, a pipe is used instead of redirecting the output. The –a option tells the tee command to append the file with the new output.) lab46:~$ alias ls="ls | tee -a /home/rhensen/log" ===Conclusions=== This second command achieved the results that I had in mind when I wanted to set up a log file. This appears to be a valid method of tracking the output of a certain command automatically. ====Experiment 3==== ===Question=== Is it possible to remove a directory by deleting the . file that is contained within the directory? ===Resources=== No outside resources have been used for this experiment. ===Hypothesis=== Each directory contains two files which are "." and "..". The . file refers to the directory itself and the .. file refers to the parent of that directory. These files are in each directory to allow the Unix shell to use relative path names. I believe that if the . file is removed, this would logically cause the current working directory to be deleted. It would seem to be a problem if Unix allowed the user to do this, which is why I believe that removing directories cannot be done in this way. ===Experiment=== To test this I will create a new directory called "test" and then change to that directory. From here I will issue the commands "rm ." and "rmdir ." to see which one works. ===Data=== Performing both of these commands yields the following results. lab46:~/test$ rm . rm: cannot remove `.': Is a directory lab46:~/test$ rmdir . rmdir: failed to remove `.': Invalid argument ===Analysis=== It appears that the file type of the . file is a directory, which is why the rm command does not work. The rmdir command seems to be designed to not accept . as an argument for the command. ===Conclusions=== Although I wanted to test this theory, I believed that there was a chance this would not work since there would likely be an error caused by removing the current working directory. Testing this theory actually has helped me to understand why the rm command cannot be used on directory files. At first the rmdir command appeared to be redundant, but now I see that it is needed to prevent problems from being caused by the rm command.