As an aid, feel free to use the following questions to help you generate content for your entries:
Learned how to change file permissions, using chmod command.
* Why was this significant?
This is significant because it lets you change the file to what you want it to be. For instance if the file is read only, you could possible change that so you can also write to the file.
* What concepts are you dealing with that may not make perfect sense?
The numbering systems involved with chmod.
* What challenges are you facing with respect to the course?
Remembrance off all the chmod possibilities involved with file changes.
As an aid, feel free to use the following questions to help you generate content for your entries:
Learned how to display currently running processes, using the ps(1) command.
* Why was this significant?
The significance of this is that it tells you what programs are running at the current moment, and their computing information, such as PID's and CPU usage.
* What concepts are you dealing with that may not make perfect sense?
Arguments to the ps(1) command.
* What challenges are you facing with respect to the course?
Using the cron command.
As an aid, feel free to use the following questions to help you generate content for your entries:
Learned how to compile/assemble source files into executables.
* Why was this significant?
This is significant because now I can run C code from an executable file.
* What concepts are you dealing with that may not make perfect sense?
Arguments involved with gcc/g++ compilers.
* What challenges are you facing with respect to the course?
Creating files that need to be compiled at a later date.
As an aid, feel free to use the following questions to help you generate content for your entries:
Learned how to use the grep command.
* Why was this significant?
This is significant because the grep command will find text within a certain file for you.
Using wildcard helpers with grep.
* What challenges are you facing with respect to the course?
The usage of wildcards to have successful data results.
Definition (in your own words) of the chosen keyword.
The creation and manipulations of a file.
Demonstration of the chosen keyword.
lab46:~$ lab46:~$ cat > file.c Any text can go here ^D (command to end operation) lab46:~$ lab46:~$ cat file.c Any text can go here lab46:~$
Definition (in your own words) of the chosen keyword.
Screen-oriented text editor originally created for the Unix operating system.
Demonstration of the chosen keyword.
Lets use file.c from the previous topic.
Syntax: vi [-rR][file…]
Exiting and Entering VI:
ZZ save file and exit VI
:wq same as above
:e! return to last saved version of current file
:q quit without save, (Note :q! is required if changes have been made)
:w write without exit (:w! to force write)
lab46:~$ vi file.c * enters VI program Any text can go here ~ ~ "file.c" 2L, 22C 1,1 ALL :q lab46:~$
Definition (in your own words) of the chosen keyword.
Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer.
Demonstration of the chosen keyword.
Environment Variables include:
USER (your login name)
HOME (the path name of your home directory)
HOST (the name of the computer you are using)
ARCH (the architecture of the computers processor)
DISPLAY (the name of the computer screen to display X windows)
PRINTER (the default printer to send print jobs)
PATH (the directories the shell should search to find a command)
env: Display environment variables.
lab46:~$ env Term=xterm SHELL=/bin/bash SSH_CLIENT=67.252.199.108 61408 22 SSH_TTY=/dev/pts/74 USER=tedmist1 MAIL=/home/tedmist1/Maildir PATH=/usr/lcoal/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games LC_COLLATE=C PWD=/home/tedmist1 HISTCONTROL=ignoreboth SHLVL=1 HOME=/home/tedmist1 LOGNAME=tedmist1 SSH_CONNECTION=67.252.119.108 61408 10.80.2.38 22 _=/usr/bin/env OLDPWD=/usr/local/bin lab46:~$
Definition (in your own words) of the chosen keyword.
PATH is an environment variable on Unix-like operating systems. This path specifies a set of directories where executable programs are located.
Demonstration of the chosen keyword.
Examples of SHELL variables are:
cwd (your current working directory)
home (the path name of your home directory)
path (the directories the shell should search to find a command)
prompt (the text string used to prompt for interactive commands shell your login shell)
SHELL variables are both set and displayed using the set command.
lab46:~$ set BASH=/bin/bash HOME=/home/tedmist1 LOGNAME=tedmist1 PWD=/home/tedmist1 SHELL=/bin/bash USER=tedmist1 lab46:~$
Definition (in your own words) of the chosen keyword.
A special character usually used in the middle of a search term in a keyword search to retrieve results containing words with any character or no character in the position.
Demonstration of the chosen keyword.
Syntax:
? Matches any one character in a filename.
* Matches any character or characters in a filename.
[ ] Matches one of the characters included inside the [ ] symbols.
lab46:~$ lab46:~$ cd script lab46:~/script$ ls file1 file2 file3 file4 file5 file6 file8 script8 typescript lab46:~/script$ ls file? file1 file2 file3 file4 file5 file6 file7 file8 lab46:~/script$ ls file* file1 file2 file3 file4 file5 file6 file7 file8 lab46:~/script$ ls [f]* file1 file2 file3 file4 file5 file6 file7 file8 lab46:~/script$
Definition (in your own words) of the chosen keyword.
Tab completion is a common feature of command line interpreters, in which the program automatically fills in partially typed commands.
Demonstration of the chosen keyword.
Changing directories into your home directory.
If you haven't provided unique enough information to the command-line, the tab completion cannot complete. Hitting tab a second time will give you a list of possible choices.
lab46:~$ cd ho <-- hit tab lab46:~$ cd home/ <-- this is what should appear after hitting the tab command <hit return> lab46:~/home$
lab46:~$ cd home/ <-- if you hit the tab command twice the next prompt should appear: lab46:~$ cd home/ .swp username/
Definition (in your own words) of the chosen keyword.
The ability to suspend an interactive job and resume it at a later time, or send it into the “background”.
Demonstration of the chosen keyword.
Need to know information:
Process ID (PID): a unique number assigned to each running process on the system.
Foreground Process: a process that is running in the foreground (currently using STDIN/STDOUT/STDERR).
Background Process: a process that is running independently in the background, allowing you to use your shell (which is in your foreground) or start additional applications.
Killing a Process: in UNIX, you can terminate processes with the kill(1) utility.
The ps(1) utility is used to list the running processes on the system. Running with no arguments will show the current processes attached to your login session.
The kill(1) utility is used to terminate certain PID numbers running.
lab46:~$ ps USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND tedmist1 13123 1.0 0.1 13628 1956 pts/74 SNs 12:53 0:00 -bash tedmist1 13126 0.0 0.0 8588 996 pts/74 RN+ 12:53 0:00 ps u lab46:~$ kill 13123 lab46:~$
Definition (in your own words) of the chosen keyword.
A program that decodes instructions written in a higher order language and produces an assembly language program.
Demonstration of the chosen keyword.
The Unix command for compiling C/C++ code is gcc.
Where hello is the name of the desired executable, and hello.c is the name of the text file containing the program source.
The -o argument to gcc indicates the name of the output file.
C Compiler
lab46:~$ gcc -o hello hello.c lab46:~$ ls hello (green coloration indicating it as a special file) hello.c lab46:~$
C++ Compiler
Where hello1 is the name of the desired executable, and hello.cc is the name of the text file containing the program source.
The -o argument to g++ indicates the name of the output file.
lab46:~$ g++ -o hello1 hello.cc lab46:~$ ls hello1 (green coloration indicating it as a special file) hello.cc lab46:~$
State the course objective
The ability to accomplish/automate tasks
In your own words, define what that objective entails.
The ability to create ones own task, and have it run at a certain point of time on each day you so wish it to run.
State the method you will use for measuring successful academic/intellectual achievement of this objective.
Such an objective can be accomplished using the cron command. Cron the name of a program that enables Unix users to execute commands or scripts automatically at a specified time/date.* * * * * command to be executed - - - - - | | | | | | | | | +----- day of week (0 - 6) (Sunday=0) | | | +------- month (1 - 12) | | +--------- day of month (1 - 31) | +----------- hour (0 - 23) +------------- min (0 - 59)
Follow your method and obtain a measurement. Document the results here.
The method of measurement would be the times in which your task will be occurring. If the task only runs for a week the measurement of that task will be a week.
Reflect upon your results of the measurement to ascertain your achievement of the particular course objective.
Good, in this objective I learned how to automate tasks to my wanting.
* Is there room for improvement?
Yes, by learning all the commands and proper syntax involved.
* Could the measurement process be enhanced to be more effective?
No, it will just take time to learn such things.
* Do you think this enhancement would be efficient to employ?
Yes, by running tasks on certain days, thus you would not forget to run them on that day.
* Could the course objective be altered to be more applicable? How would you alter it?
The course objective is just fine the way it is. It is already applicable, thus no changes needed to be made.
What is the question you'd like to pose for experimentation? State it here.
Is there anyway display commands from a history list and then re execute a command from the history list?
Collect information and resources (such as URLs of web resources), and comment on knowledge obtained that you think will provide useful background information to aid in performing the experiment.
My information came from Harley Hahn's Guide to Unix and Linux, Chapter 13: Using the Shell: Commands and Customization.
Based on what you've read with respect to your original posed question, what do you think will be the result of your experiment (ie an educated guess based on the facts known). This is done before actually performing the experiment.
If there is a way to display commands from a history list, then I can re execute those commands from the history list using another command.
State your rationale.
My rationale involving my experiment was that of the curiosity in which I could look back in time to see what commands I have used.
How are you going to test your hypothesis? What is the structure of your experiment?
During this experiment I will be running the command, “history”, to display commands from the history file. From there I will be the commands “!” and “!!” to perform different needed tasks. The command “!” will re execute a certain command number from the history list. While, “!!” will re execute the last command used from the history list.
Perform your experiment, and collect/document the results here.
When running the “history” I get a listing from the command numbers used of 321 to my most current command 533 or history. If I run the “!” command, for example of line 521, which was a “ls” command used earlier. The prompt would look like this “!521”, thus if done right an listing of files should have appeared in your home directory, just as the ls was directed for earlier. The format for the “!” goes as the following “!filename”. Since the “!!” will re execute the last command in the history list, the same ls should appear if you had used the “!!” command. If all completed right you would have two file listings of your home directory in visible sight.
Based on the data collected:
Yes, my hypothesis was correct.
My hypothesis was applicable.
The command worked just as I thought it would have.
There are no foreseen shortcomings in my experiment.
There are no foreseen shortcomings in my data.
What can you ascertain based on the experiment performed and data collected? Document your findings here; make a statement as to any discoveries you've made.
In conclusion using the history command can be very useful if you had forgotten a certain command used a while back. Also the “!” command can be a quick way to use that same forgotten command if you don't want to retype out that command.
What is the question you'd like to pose for experimentation? State it here.
Is there a way to run programs at a lower priority in comparison to other programs running?
Collect information and resources (such as URLs of web resources), and comment on knowledge obtained that you think will provide useful background information to aid in performing the experiment.
My information came from Harley Hahn's Guide to Unix and Linux, Chapter 26: Processes and Job Control.
Based on what you've read with respect to your original posed question, what do you think will be the result of your experiment (ie an educated guess based on the facts known). This is done before actually performing the experiment.
If there is a way to run programs at a lower priority then what command can be used to do such actions.
State your rationale.
My rationale for this question is that when running multiple commands, how can you prioritize which needs more priority over the other.
How are you going to test your hypothesis? What is the structure of your experiment?
I am going to test my hypothesis by running a command and setting it to run in the background. Then run another program. Using the ps utility check out the %CPU usage for the commands used. And hello and hello2 as the desired executable. I will be using the files hello.c and count.c as the files with the program source code.
Perform your experiment, and collect/document the results here.
To run programs at a lower priority use nice(1).
Syntax: nice [-n adjustment] command.
However, nice will not automatically run the program in the background. You will need to do that yourself by typing an & character at the end of the command.
lab46:~$ nice gcc -o hello hello.c & [1] 13842 lab46:~$ gcc -o hello2 count.c lab46:~$ ps USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND tedmist1 13123 1.0 0.1 13628 1956 pts/74 SNs 12:53 0:00 -bash tedmist1 13955 0.0 0.0 8588 996 pts/74 RN+ 14:07 0:00 ps u tedmist1 13465 2.0 0.1 9525 992 pts/74 RN+ 14:07 0:00 nice gcc -o hello hello.c & tedmist1 13812 1.1 0.0 8678 994 pts/74 RN+ 14:07 0:00 gcc -o hello2 count.c
Based on the data collected:
Yes, my hypothesis was correct.
My hypothesis was applicable.
More commands were needed to be used than I originally thought I had to use.
I had only ran two programs while there could have been more
programs running at once, thus making my experiment more applicable.
I used the gcc compiler only, I could have used the g++ compiler. Possibly could have gotten different results, thus different data.
What can you ascertain based on the experiment performed and data collected? Document your findings here; make a statement as to any discoveries you've made.
From my experiment, provided above, I can say that I know now how to set commands, while running in the background, to a lower priority over other commands running. This can be very helpful if you have a program that can run in the background and which uses a large amount of CPU time. Using the nice(1) utility provides that the program have a reduced amount of CPU usage. Thus, leaving other programs to use that CPU speed.
Perform the following steps:
Whose existing experiment are you going to retest? Provide the URL, note the author, and restate their question.
I will be retesting Reid Hensen's Experiment 3 in Part One.
http://lab46.corning-cc.edu/opus/spring2012/rhensen/start
Question: Is it possible to remove a directory by deleting the . file that is contained within the directory?
Evaluate their resources and commentary. Answer the following questions:
I do not, no resources were provided for the experiment.
* Are there additional resources you've found that you can add to the resources list?
I would add Chapter 25: Working with Files, found in Harley Hahn's Guide to Unix and Linux.
* Does the original experimenter appear to have obtained a necessary fundamental understanding of the concepts leading up to their stated experiment?
Yes, I do believe the original experimenter appeared to have an understanding of the concepts prior their experiment.
State their experiment's hypothesis. Answer the following questions:
Their experiment's 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.”
Yes, I do believe so.
* What improvements could you make to their hypothesis, if any?
Make it shorter and to the point. No need for a lengthy hypothesis.
Follow the steps given to recreate the original experiment. Answer the following questions:
Yes, the instructions are correct in achieving the results.
* Is there room for improvement in the experiment instructions/description? What suggestions would you make?
No, the instructions are straight forward and easy to follow.
* Would you make any alterations to the structure of the experiment to yield better results? What, and why?
No, I would not do so because there is no changing what the experiment can entitle. Different results are not obtainable for this experiment.
Publish the data you have gained from your performing of the experiment here.
lab46:~/test$ rm . rm: cannot remove `.': Is a directory lab46:~/test$ rmdir . rmdir: failed to remove `.': Invalid argument
Answer the following:
Yes, the data is in-line with the published data from the original author.
* Can you explain any deviations?
No deviations in data.
* How about any sources of error?
No sources of error, besides the ones in experiment.
The stated hypothesis is adequate.
Answer the following:
The started hypothesis was correct on the results of the experiment.
* Do you feel the experiment was adequate in obtaining a further understanding of a concept?
No, no further knowledge was learned from this experiment.
* Does the original author appear to have gotten some value out of performing the experiment?
The knowledge that you cannot remove your current working directory.
* Any suggestions or observations that could improve this particular process (in general, or specifically you, or specifically for the original author).
No suggestions to be made or needed in this experiment.