----------------------------------------------------- Chapter 10 Reading Guide - A Practical Guide to Linux ----------------------------------------------------- -IAN! idallen@ncf.ca Here is a Reading Guide and some review questions for Chapter 10 "The Bourne-Again Shell". You will find questions similar to these on tests and exams. Chapter 10 - The Bourne Again Shell (excerpts) Note: For much of the material, the Korn Shell (ksh), Bourne Shell (sh), and Bash Shell (bash) behave identically. C-Shells are different. Note: For practice, type in all the textbook scripts and command lines. You can't practice debugging the scripts simply by reading them. Practice writing them. Note: Concentrate on the text sections related to material covered in lectures, assignments, and in these questions. Don't read the whole book. Skip over all the "Optional" sections in this chapter. Also skip over these sections: skip "Directory Stack Manipulation" p.313 skip most of "Startup Files" p.318 (only know .profile and .bashrc) skip "Removing Variables" p.322 skip "The readonly builtin" p.322 skip "The declare builtin" p.324-325 skip the table "Special Characters / Display in Prompt" p.331 skip "PS2" p.331 skip "CDPATH" p.332 skip "The shift builtin" p.334 skip "The set builtin" p.335-337 skip "History" and "Alias" p.340-350 skip "Brace Expansion" p.351 skip "Arithmetic Expansion" p.354 skip "Word Splitting" p.356 skip "Command Line Editing" p.359-362 Skip over the above sections. FIX: The Linux text incorrectly shows command lines that execute programs in the current directory without using the "./" pathname prefix, e.g. "bash$ whoson" (p.303) instead of the correct form "bash$ ./whoson" (p.304). Always put "./" in front of names that you want to execute in the current directory; do not depend on the current directory being in your search path ($PATH). (See the warning at the top of p.330. Fix all the examples in the texbook!) - Which successful shell has been used in all versions of Unix and Linux? (p.302) - What is the difference between the program "sh" and the program "bash"? (p.302) - What is a shell script? (p.302) - True or False: Shell scripts cannot have their input or output redirected; only Unix command output can be redirected. (p.302) - What is the purpose of "control flow" commands? (p.302) Read p.316 "Invoking a Shell Script" before you read p.303 "Making a file executable". These comments deal with page 316: - Just like many Unix programs (e.g. cat, sort, head, tail, wc, etc.), if a shell is given a file name to read, it reads command lines from the file and does not read standard input, e.g. $ bash whoson (p.316) Each line in the file is read by the bash program and is interpreted as a command line to execute. (Shells find and execute commands.) This means you can "execute" a shell script by invoking a second copy of the shell as a command and giving the second shell a script pathname to read on the command line, e.g. $ bash myscript.sh When the second shell has read the last line of the script, it exits on EOF. Nothing that the script file does affects the original shell process (the one into which I typed "bash myscript.sh"); the script is being run by a separate second shell process that exits when the script ends. - What *minimal* permissions are needed on a script file for a shell to *read* the file containing the shell script, i.e.: $ bash myscript.sh (Hint: The answer is the same as for "what permissions are needed for sort to read a file", or for tail or wc to read a file, etc. Execute permissions on the script being read are *not* required!) (p.316) - Erase the sentence at the top of page 317 that talks about scripts running "more slowly". They do not. "bash script" and "./script" are equally good; the first requires only read permission on the script, the second requires both read and execute permission (why?). Read the Notes file shell_script_execution.txt to understand how a shell script is actually "executed". Return to reading on p.303. - How do you run ("execute") a shell script? (p.303) (Re-read the "FIX" note above and fix "whoson" to be "./whoson".) - What permissions are needed to execute a shell script by using its name as the first word on a command line? (p.303) (Re-read the "FIX" note above and fix "whoson" to be "./whoson".) - True or False: The VI/VIM editor creates files with the execute permission set. (p.303) - What *minimal* permissions are needed for the Unix kernel to *execute* a file containing a shell script, i.e.: $ ./script (p.303) (Hint: The kernel only executes files that have the execute bit set. Shell programs must be able to read the file to "execute" the commands contained in the file.) Will the Shell (not the kernel) be able to execute (read) a script that has execute permissions but not read permissions? (Try it!) What minimal permissions are needed on an executable shell script? - p.303 - Do not expect the current directory to be in your search PATH. The system administrator has ill-advisedly included it in PATHs set for students on ACADUNIX. It is *not* included under most modern versions of Unix/Linux. Read p.304 on how to execute correctly a shell script that is in the current directory. Always use "./" in front of your script names to execute them out of the current directory. Read the top of p.330 for an explanation of the security risk of having the current directory in your search PATH. - Warning: I often create test questions that create scripts that have the same names as existing (but often obscure) Unix commands! If you fail to follow the "./whoson" syntax given at the top of p.304 you will not be able to run your shell scripts; because, you will execute the system command that has the same name instead. Always use "./myscript" to execute a script in the current directory. - Note: The book makes two errors throughout this chapter: 1) The book fails to use "#!/bin/sh -u" to start scripts 2) The book fails to use ./scriptname to run scripts In this course (and in the real world), you must not make these two mistakes. Go through your book now and fix all the script examples! All scripts should start with the interpreter line: #!/bin/sh -u (You can use #!/bin/bash but then your scripts won't work on ACADUNIX.) - What does the semicolon special character mean to the shell? (p.304) - How would you generate the following output sentence (containing special characters) on your screen using the "echo" command (p.37,320,348): $ echo (what do you type here to make the next line appear?) I read Chapter 2; so, it's easy to escape "special" characters. - True or False: If the command to the left of a semicolon fails (with a bad return status, or "not found"), the shell will not execute the command to the right of the semicolon. (Hint: Try it.) - True or False: Semicolons must be surrounded by spaces to be special. (p.305) - Note how an ampersand ("&") puts an *entire* pipeline into the background: $ sort /etc/passwd | tail -15 | grep '^zoo' & (p.306) It puts the whole command pipeline into a single "job" in the background, not just the last command in the pipeline. Killing or stopping the job affects all the processes in the pipeline. (p.306) Rembember to skip over all the "Optional" sections in this chapter. - True or False: All Unix commands send all their output to standard output (and only to standard output). (p.308) - What are the numbers and names of the standard three file descriptors given to a running program in Unix? (p.308) - The symbol ">" is a shorthand for which output unit? What is the full form (not a shorthand) for this kind of output syntax? - True or False: Programs can tell that output has been redirected by the shell. (p.308) - True or False: When displayed on your terminal, output on standard error looks different (visually) than output to standard output. You can tell the two kinds of output apart by looking at the screen. - True or False: Output on standard error is not affected by using ">" or by pipes ("|"). (p.309) - What syntax is used to redirect standard error into a file? (p.309) - True or False: You can redirect both standard error and standard output on the same command line. (p.309) - How do you tell the shell to make standard error redirect into the same file descriptor as standard output, so that both redirect together? (p.309) - True or False: These two command lines generate the same output: $ ls >out 2>&1 /etc/passwd nosuchfile $ ls 2>&1 >out /etc/passwd nosuchfile (Hint: Try them. Read p.309. Order is important here!) - True or False: The syntax for redirecting the output of an echo command to appear on standard error (instead of on standard output) is: echo 1>&2 "This is an error on standard error" - Standard error output does not get redirected into files or pipes unless you use some special shell syntax. How do I tell the shell to redirect the standard error output of a command into a pipe? (p.310) - What syntax do I use to send the standard output of a command to standard error (so that it does not get redirected)? (p.310) (This is most often used on the "echo" command in shell scripts, to generate error messages on standard error from inside the script.) - True or False: The following three commands are identical: echo "This is an error message appearing on standard error" 1>&2 echo 1>&2 "This is an error message appearing on standard error" 1>&2 echo "This is an error message appearing on standard error" (Hint: The shell does not care where in the command line you put your I/O redirection syntax. It finds it anywhere!) [...more to come in Chapter 10...]