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.
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
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.
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.
The home directory is the main directory for each user on the system. When a user first logs on to a Unix system, their working directory will be their home directory. Each user has their own home directory in which they are the owner of all of the files. The home directory is specified by the ~ symbol.
To change to the home directory at any time, a user only has to enter the cd command.
lab46:/var/public/data/fall2010$ cd lab46:~$
This is the directory that you are currently in and is the directory that will be shown in the command prompt. Any commands that reference files using a relative path name will use the current working directory as the starting point.
You can display the absolute path name of the current working directory by using the pwd (print working directory) command.
lab46:~$ pwd /home/rhensen
In order for Unix to properly make use of certain files, it must know the type of file. Most files are regular files, such as text files, and are treated by Unix as simply a container or data. The next most common types of file are directories, which are used to contain other files. Aside from these two main types there are also different varieties of special files.
The type column of a listing of files is the leftmost character on each line. The top file is a regular file since it has a - in this field. The middle file is a directory since the type field displays a d. The last one is a type of special file called a link, which can be seen from the l.
-rw-r--r-- 1 rhensen lab46 30 Feb 10 23:12 lab03.txt drwxr-xr-x 2 rhensen lab46 6 Jan 25 22:33 bin lrwxrwxrwx 1 rhensen lab46 17 Jan 19 11:57 Maildir -> /var/mail/rhensen
A wildcard character is a symbol that is used to substitute for characters in a string. The question mark (?) symbol is used to represent one and only one character. The star (*) is used to represent zero or more characters. Square brackets ([]) can be used to match particular characters or a range of characters.
Alternatively (or additionally), if you want to demonstrate something on the command-line, you can do so as follows:
lab46:~$ ls file* file1 file2 file3 file32 filea lab46:~$ ls file? file1 file2 file3 filea lab46:~$ ls file[3]* file3 file32
In Unix, the Tab key can be used to complete the names of commands and path names that you have begun typing. Tab completions only work when the user has typed enough that there is only one command or path name that can be filled in by hitting Tab.
Here hitting Tab after each letter typed does nothing for t and te, but it eventually completes the line with an important command when tet is entered.
lab46:~$ t lab46:~$ te lab46:~$ tet lab46:~$ tetris-bsd
$PATH is an environment variable that is used to reference all of the directories within a user's search path. Whenever a command is entered, Unix will look through the directories specified in the $PATH variable in order to find that command. If this variable were not used, all commands would have to be entered with an absolute path name.
The value of $PATH can be displayed with the command “echo $PATH”.
lab46:~$ echo $PATH /home/rhensen/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
The term local host refers to the computer that a user is currently at.
For example, I am currently accessing Lab 46 from my home computer using Putty. In this case my computer is the local host.
The term remote host refers to a machine that a user is able to access from across a network without being physically present at that machine.
For example, I am currently accessing Lab 46 from my home computer using Putty. In this case, Lab 46 is the remote host.
login as: login as: login as:@lab46.corning-cc.edu's password:
My reason for taking this course is to gain familiarity with the Unix environment and develop a working knowledge how to essentially get Unix to do what I want it to.
For me, I feel that I have a good working knowledge of something when I am able to use my knowledge to solve a problem that I have not seen before. I believe that one of the most important skills to develop when working with computers is to be able to apply what you know to different situations.
As I use Unix throughout the semester, either through assignments or during my own personal use, I will reflect on the ease with which I am accomplishing my desired actions.
I will feel that I have become familiar with Unix when I am comfortable with a variety of commands, have an understanding of how the Unix shell operates, and most importantly when I am able to effectively use the manuals to better understand commands that I am not familiar with.
This far into the course, I feel satisfied with my progress so far. I do not know a great deal of commands, but I know enough to navigate through the directories and perform some basic actions with files, such as copying. I am very comfortable with how to use path names, which is a major component of understanding any OS especially when using a CLI. I also have a good understanding of how to use certain features of the shell, such as wildcards and piping. One area that I am still having some difficulty with is using unfamiliar commands correctly. I know how to access the manual pages, but I am still finding that reading through these is difficult and it is sometimes hard for me to find useful information from these. I would like to become more comfortable with learning new commands and effectively using the documentation.
Is it possible for Unix to match wildcard characters in a file name when using wildcards?
No outside resources have been used for this experiment.
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.
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).
After performing the ls command using different variations of wildcard patters, I have determined that:
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.
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.)
Can output redirection be used with aliases in order to easily create a log file from the output of a certain command?
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)
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.
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.
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.
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"
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.
Is it possible to remove a directory by deleting the . file that is contained within the directory?
No outside resources have been used for this experiment.
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.
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.
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
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.
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.