.bash_profile

.bashrc

1. Use a Linux text editor to create your .bash_profile and .bashrc files with the minimum suggested content described in Start-Up Files. These files do not exist yet; you must create them.

   Do not set any options or aliases in your .bashrc that you do not understand! If you don’t know the meaning of a setting, don’t use it. You can RTFM in the bash man page for all BASH settings, and RTFM in command man pages to learn about options to commands.

   Using the PS1 variable from Worksheet #2 HTML, set your prompt to include your user name, your computer name, and the basename of your current working directory. Put this setting (or one like it) in your .bashrc file.

   Your .bash_profile must contain only one line. Your .bashrc must contain at least two lines (not including comment lines).

I will be spot-checking your knowledge of your aliases and shell options. Students using aliases they don’t understand will experience much confusion trying to do future assignments. Only use aliases and shell options that you understand.

2. Verify that nothing prints on your screen after you enter your password when you run the non-interactive shell connection using ssh localhost true as described in the section on Non-interactive shells and PS1:

   $ ssh localhost true
   *** COURSE LINUX SERVER ***
   user@localhost's password:
   $

   For non-interactive commands to work properly, there must be no output on your screen after you enter your password using the above non-interactive command line using the true command.

Your instructor will mark the .bashrc and .bash_profile files in your account after the assignment due date. Do not upload them to Blackboard. Leave them there on the CLS. Do not delete anything.

Run the Checking Program to verify your work so far.

environ.sh

1. Use the echo command to display on your screen the value of the environment variable containing your userid.

   When you have the right command line, put a copy of the command line into file environ.sh in the Base Directory. (Put a copy of the command line in the file, not the command output.) You may use a text editor such as The VI Text Editor to create this file.

   The file should now contain one command line – exactly the same command line that you typed to display the value above.

2. Use the echo command to display on your screen the value of the environment variable containing your home directory.

   When you have the right command line, append a copy of the command line to the end of the file environ.sh in the Base Directory. (Append a copy of the command line to the file, not the command output.) You may use a text editor such as The VI Text Editor to edit and add to the end of this file.

   The file should now contain two command lines.

3. Use the echo command to display the value of the environment variable containing your assigned shell.

   Append the command you use to do this to file environ.sh in the Base Directory. (Put in the command, not the output.) The file will contain three command lines.

4. Use the echo command to display the value of the environment variable containing your shell search path. Append the command you use to do this to file environ.sh in the Base Directory. (Put in the command, not the output.) The file will contain four command lines.

5. Assuming that environ.sh is in your current directory, use the sh shell to run (execute) your four-line shell script by typing sh -u environ.sh and the values of all four environment variables should display on your screen. (If environ.sh is in some other directory, use the appropriate pathname to it.)

6. To verify that you have used proper procedures for expanding variables inside your script, set the USER variable to be a GLOB character temporarily and then run the script again like this (assuming that environ.sh is in your current directory):

   $ USER='*' sh -u environ.sh

   Make sure that the first line of script output is the single GLOB character * and not a list of file names. If you see a list of file names as the first line, re-read the first sentence of this task, above.

7. Add one or more shell comment lines to the end of the file, describing in your own words the use for or meaning of each of the four variables in your script. A shell comment line starts with a number sign (octothorpe, pound-sign, or hashtag) character “#”, e.g.

   # This is a shell comment line.  The shell will ignore it.
   # This is another comment line.  It starts with the # character.
   # Comment lines should be added to the bottom of the file.

   1. Use your own words (do not copy mine or others) in your comment lines.
   2. Use as many comment lines as you need to describe all four variables.
   3. The comment lines should all be on separate lines; do not add comments to the ends of any executable lines in the file.
   4. Do not put any blank lines in the file (lines with nothing on them). Every line should contain some text. No blank lines. Use a program to count the lines in the file to be sure.

Run the Checking Program to verify your work so far.

pathtest.sh

1. Use a text editor to create a file named pathtest.sh under the Base Directory. This file will contain these four command lines:

   1. The first line must set the shell search PATH variable to include the Source Directory for this assignment appended at the (right) end of the path. Append to the existing PATH variable, as shown in the course notes.
   2. The second line must safely echo the new value of PATH onto your screen. Follow correct double-quoting procedures when expanding variables, as noted in Shell Variables.
   3. The third line must be the command that shows the host name (computer name) of the CLS machine (the same name as seen in the shell prompt).
   4. The fourth line must have the shell find and execute a command named assignment07check (the basename of the Checking Program), which it will do using the modified PATH you set at the top of the script. No slashes should appear in this command name, so that the shell uses your modified $PATH, set on the first line, to find it and run it. (Review how the shell search PATH works.)

2. After you have created your four-line shell script, enable execute permissions on the script file and then run (execute) it using these two command lines:

   $ chmod u+x pathtest.sh                       # all lower-case letters
   $ ./pathtest.sh

   Remember how to make a file executable and run it from the current directory; you will need this again.

   When you run the script, each of the four command lines in the script will execute, one after the other. The first line, setting the search path, should produce no output. There will be three outputs that come from the next three lines of the script:

   1. The second line of the script will display the modified PATH.
   2. The third line will display the name of the machine.
   3. The fourth line should find and run the assignment07check checking program and generate lots of output.

Hints:

1. You need to know how the shell uses the PATH variable to find and run commands.
2. You need to know how to append to PATH.
3. Remember to quote all variable expansions.
4. If you see command not found output coming from commands inside the executing script, you have either spelled a command name incorrectly or have not correctly set the shell search path inside the script file. This script will only work if the shell search PATH is set correctly at the beginning (top) of the file.

3. As you did in the previous task, add one or more shell comment lines to the end of the file, describing in your own words what this script does and how it does it. Use your own words (do not copy mine) in your comment lines. Use as many comment lines as you need to describe the script.

Run the Checking Program to verify your work so far.

goodquotes.sh

2. Copy the script file badquotes.sh from the Source Directory into the current directory using the new name goodquotes.sh as you copy it.

3. Enable execute permissions on the script file and run the script (as you did in the previous task).

   Note that the output of running the script generates an error message and the lines output on the screen don’t match what is written in the script file. For example: many quotes are missing, GLOB characters and variables are expanding, and the spacing of the words is different.

4. Use a text editor to add Quoting inside the script file so that every line is fully quoted to appear onto your screen exactly as written in the file, blanks included, with no meta-character expansion by the shell. The correct ten lines of output should look exactly like this when you are finished, including all the extra spaces between some of the words:

   Where is the question mark after the file name /etc/passwd?
   Is one also missing after the file name /etc/group?
   Do you see any *[square]* *[brackets]* in this line ??????????
   The BASH shell prompt is contained in the upper-case  $PS1  variable.
   This line isn't appearing on my screen correctly.  It's missing the quotes.
   This line is also "missing" all the quotes.  It is "not right" yet.
   This line is also missing "quotes".  It's output that doesn't make sense.
   This line isn't working either.  The shell gives an error message.
   ***  This is a file to practice shell quoting.  Do you see this line?  ***
   Do   you   see   this   last   line   with   the   extra   spaces  ?

   The correct script output (above) is exactly ten lines, 114 words, 674 characters and has a checksum of 11849 1.

Hints:

1. You must edit the goodquotes.sh file to make the entire line of text on each line one single shell argument to echo. Review how the shell finds arguments and how to use Quoting to hide shell metacharacters.

2. You can check whether you have successfully created one single argument on each line by using an alias to temporarily substitute the argv.sh program from the Class Notes for the echo command.

   You can easily get a copy of the argv.sh program from the course notes on the CLS using the newnotes symbolic link you created in a previous assignment.

   Read the goodquotes.sh file for details on using an alias to run argv.sh. You have to put the argv.sh program into the same directory as goodquotes.sh under the name argv.sh and make it executable.

3. If your line and word count is correct but the number of characters is less, you probably failed to make the entire text one argument to echo on each line. You must use Quoting to hide all the blanks and special characters from the shell on each of the lines. The argv.sh program will tell you if you got it right.

goodquotes.txt

5. When the output of your edited script is correct, run the script and redirect the script output into file goodquotes.txt in your Base Directory (which should still be your current directory).

   The file must contain exactly the same lines, words, and characters as given above. The checksum of the file must be the same as above.

   Hint: Make sure you spell the extension on the pathname correctly.

Run the Checking Program to verify your work so far.

check

1. Create a symbolic link named check in your Base Directory that links to the Checking Program in the Source Directory.

Instead of typing the huge absolute pathname when you want to run the Checking Program, all you need to type is the short name of this symlink, which now points to the long pathname.

When in your Base Directory you can use your symbolic link ./check to run Checking Program to verify your work so far.

You already created symbolic links to oldnotes and newnotes in a previous assignment. These (shorter) symbolic links let you access the course notes using much shorter pathnames. Sysadmin often create (shorter) symbolic links to long pathnames that they use frequently.

ln/abcd0001.txt

1. In your Base Directory, create a sub-directory and an empty file ln/abcd0001.txt (no spaces), where the text abcd0001 is replaced by your own eight-character userid in the file name. NOTE: The sub-directory name is ln (two letters), not 1n (digit letter).

2. For every unique character in your own eight-character userid, create a sub-sub-directory under ln with that single-character name.

   For example, the userid abca0151 would result in six unique sub-sub-directory names under the ln directory – one sub-sub-directory for each of the unique characters a, b, c, 0, 1, 5. (You can create multiple directories with one single command line.)

   Do this for your own userid, which means you may have more or fewer sub-sub-directories, depending on the letters and digits in your own userid.

3. Inside each of those new sub-sub-directories, create a single Hard Link to the empty file from the first step. Keep the same file name as the original for each hard link you create. Use hard links, not symbolic links.

   Continuing the above example, the abca0151 user would hard link the original empty file name abca0151.txt into each of those six new sub-sub-directories, creating six additional names for the same file. Keep the same file name as the original for each hard link.

   Check the link counts on everything to make sure that you have created links to the same file and not made copies of the file. Use hard links, not symbolic links.

4. For every lower-case letter directory name you created, create a short, relative Symbolic Link that is its upper-case equivalent. If you created directory a, then create symlink A that points to a so that both ls ln/a and ls ln/A give identical results. (You must use symbolic links, because you cannot make hard links to directories.)

5. In every file you have just created in this section, enter the following information, one name per line: Enter the names of the three common file system commands that are “directory only” commands that require permission only on the directory inode to work properly, and that do not require permissions on the file inode to work. The answer is three lines, one command name per line. (See your in-class notes for the three names I wrote on the board, or read the course notes about links and inodes.) The right answer has this format (three lines; three words; nine characters):

   $ wc abcd0001.txt
   3 3 9 abcd0001.txt

   Again, the text abcd0001 must be your own userid, in all cases.

Hints: All the file names you created in this section should be hard links to the same file; you have very little editing to do. The three command names are all commands that are directory operations that manipulate file names; they don’t touch the file data and don’t need any permissions on the file data.

Use your symbolic link ./check (created in the previous task) to run Checking Program to verify your work so far.

My DiskUse

1. After you have run the Checking Program at least once, you will find created for you in the Source Directory a disk usage directory named DiskUse/abcd0001 (where abcd0001 is replaced by your own userid). Copy, using the archive option, this directory into your Base Directory using the name My DiskUse. You will know you got it right if your personal copy of the My DiskUse directory has the same disk use summary (du -s) as the one in the Source Directory.

In your personal My DiskUse directory, some of the files are hard links to each other. (If there are no hard links anywhere, you didn’t use the archive option to the copy command that preserves hard links. Delete everything and re-copy.)

Your personal copy of the My DiskUse directory contains exactly four sub-directories, each of which contains many other files and sub-sub-directories. (If you don’t see four sub-directories under your copy of My DiskUse, read all the words in the Hints again.) A recursive list of pathnames under My DiskUse counts 302.

There are four levels of difficulty in this task, one for each of the four sub-directories in your personal My DiskUse directory. Do the easy level first, followed by the medium level, followed by the hard level, followed by the ug1y level.

Read this task all the way through, especially the Hints, before you delete anything, or else you will have to start over again.