------------------------ Week 5 Notes for DAT2330 ------------------------ -Ian! D. Allen - idallen@idallen.ca Remember - knowing how to find out an answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) ------ Review ------ In Week 4 (week04notes.txt) you started studying for your first term test. You can redirect stdout and stderr into the same file or pipe. You understand GLOB patterns (and hidden files). You know these shell meta-characters: # $ * | \ [] ; " ' <> ? You know how to write simple executable shell scripts with comments. You can use the argv.sh script to see command-line arguments. You understand inodes, hard-linked file names, and the "ln" command. - why do empty directories have a link count of two? - why does creating subdirectories increase the link count? - why does creating files NOT increase the link count? You can use the "script" command to record a terminal session. You can post and cancel Usenet news articles via news.idallen.com. You started studying the midterm practice questions. You started DAT2330 Exercise #2. ------------------ This Week (Week 5) ------------------ Your first Midterm Test is in your lecture period on Friday, February 6. (Postponed to February 13 due to Environment Canada storm warning.) * What are hard links good for? A CD database: - one file per CD - hard link the CD file into categories: genre, era, artist, etc. - one file can be visible in many directories - still have only one actual copy of the file data (easy to maintain) Web site reorganization: - to add a new name for a web page, add a link instead of copying the file to the new location - still have only one actual copy of the file data (easy to maintain) File sharing: - you may link to another user's file - you can use any name you want, and you can rename as you wish - still have only one actual copy of the file data (easy to maintain) * Shells, Prompts, and Standard Input - many Unix commands will read standard input (if given no file names) - shells also read standard input if given no file names - special: shells issue prompts before reading standard input - because shells are designed to read stdin and find and run commands - most other Unix commands do not prompt when reading stdin - if you give a shell a file name, it will read the commands from the file (without prompting) and it will ignore standard input * Executable Shell Scripts - must start with the #! pathname of the interpreter to use - must be readable and executable ("chmod +rx myscript.sh") - the #!/bin/sh -u line is processed by the Unix kernel - it is a comment line to the shells (ignored) - the kernel cannot "execute" a shell script text file - so the kernel executes the #! program instead and the #! program reads the text file See Notes: shell_script_execution.txt How a Shell Script is "Executed" - on Linux /bin/sh is a link to /bin/bash - /bin/sh works on all versions of Unix; /bin/bash only on Linux - use /bin/sh to start your scripts, not /bin/bash - the -u argument tells the shell to "check for undefined variables" - you can specify any executable binary program you like after #! - the kernel will execute that program and had it the script file name - we will only use #!/bin/sh in DAT2330 * The Search Path - Running Linux: "What is a Command" p.96 - Learning Unix: PATH p.64 - the $PATH variable contains the list of directories (never files) searched by the shell when it tries to find a command name - directories are separated by colons (":") - only command names without slashes are looke up in $PATH - a command name containing a slash is NOT looked for in $PATH - e.g. $ ./a.out # uses the a.out in "."; does not search $PATH $ PATH=/bin:/usr/bin ; ls - shell tries first directory in PATH: /bin - shell looks for /bin/ls - this exists, so it is executed $ PATH=/bin:/usr/bin ; gcc - shell tries first directory in PATH: /bin - shell looks for /bin/gcc - this is not found - shell tries next directory in PATH: /usr/bin - shell looks for /usr/bin/gcc - this exists, so it is executed $ PATH=/bin:/usr/bin ; nosuch - shell tries first directory in PATH: /bin - shell looks for /bin/nosuch - this is not found - shell tries next directory in PATH: /usr/bin - shell looks for /usr/bin/nosuch - this is not found - shell issues message "nosuch: Command not found" $ PATH=/bin:/usr/bin ; /usr/games/fortune - command name contains slashes, $PATH is NOT used - shell executes /usr/games/fortune directly - $PATH is NOT used - your shell has some built in commands, e.g. echo, cd, umask, pwd - built-in commands are not looked up in $PATH $ PATH=/junkxxxx ; pwd # works because pwd is built-in to shell - examples: $ PATH=/bin:/usr/bin ; ls # works $ PATH=/junkxxxx ; ls # fails (PATH must contain directories) $ PATH=/bin/ls ; ls # fails (PATH must contain directories) New commands: which - tell which $PATH directory contains a command whereis - locate commands in "standard" directories (ignores $PATH) (also locates man pages for you, if any) Note that "whereis" may tell you that a command exists in some standard directory, but when you try to execute the command it may not be found, if the standard directory is not one of your PATH directories. The shell only looks in PATH, not in any "standard" places. * Software Packaging using tar (with and without compression) - Running Linux: "Using tar" p.178 - Running Linux: "Using tar with gzip and bzip2" p.183 $ tar cvf tarfile infile... # create tarfile $ tar tvf tarfile # verbose table of contents of tarfile $ tar xvf tarfile # extract contents of tarfile Add the letter "z" to create/list/extract a compressed tar archive: $ tar czvf tarfile infile... # create compressed tarfile $ tar tzvf tarfile # TofC of compressed tarfile $ tar xzvf tarfile # extract contents of compressed tarfile A compressed tar file is simply a tar file that has been compressed after being created. You can create a compressed tar file by compressing (using gzip) an uncompressed tar file (and vice-versa). Note that the *entire* tar file is compressed as one file. The individual files inside the tar archive are not individually compressed. (Windows "zip" files are individually compressed in the zip archive.) Readings: * Running Linux "What is a Command" p.96 "Using tar" p.178 "Using tar with gzip and bzip2" p.183 * Learning Unix PATH p.64 * Course Notes shell_script_execution.txt How a Shell Script is "Executed" unix_command_list.txt Basic Unix/Linux Command List