LUX 211 - Shell Programming

Lesson 1: Chapter 1, Welcome to Linux and Mac OS X; Chapter 2, Getting Started; Chapter 3, The Utilities


This lesson introduces the concepts from the first three chapters of the text. Objectives important to this lesson:

  1. UNIX, Linux, and OS X
  2. Linux features
  3. Installing Linux
  4. Terminal command line entry and troubleshooting
  5. Issuing commands with root permissions
  6. More on online help
  7. Basic utilities
  8. File utilities
  9. System utilities
OS in contextChapter 1

This lesson begins with a definition of an operating system. Any operating system should include some key features:

  • it coordinates the activities of programs and system hardware, allowing the programs to interact with hardware and each other
  • it performs startup and shutdown functions for the device that runs it
  • it typically includes one or more user interfaces
  • it is meant to run at startup, from a hard disk, a solid state drive, a bootable flash drive, or installed firmware
  • drivers are additions to operating systems that accommodate new hardware; as such, updates to operating systems are available from hardware vendors as well as from operating system publishers

The text moves on to a quick overview of three operating systems: UNIX, Linux, and OS X. Once upon a time, before the US Government required that it be split up into several pieces (in 1984), Bell Telephone logothe Bell System was a huge telephone/telecommunications company, that included a research and development division called Bell Telephone Laboratories, also known as Bell Labs. They invented a lot of things, including the UNIX operating system. At the time it was created, Bell Labs was not allowed to sell UNIX, so it was given away, mainly to universities who modified it as part of their own research and development programs.

This situation eventually led to two major versions of UNIX. One was controlled by Bell Labs itself, and it was called UNIX System V. Ownership of System V has changed over the years, and several updates of it have been issued. The text mentions SVR4, which stands for System V, Release 4.

The second version of UNIX is sometimes called BSD, which stands for Berkeley Software Distribution, because that version was standardized by the University of California, Berkeley. This version has been adapted many times and has been provided to many other schools for their use in classes and in running their computer systems.

Each of the two major versions of UNIX has its own history, features, and limits placed on its use. One limit is that UNIX is typically run on a server, and users must connect to the server, and run a session on it to use the system's features, utilities, and programs. This limitation led to the creation of new versions of UNIX that could be run as an operating system on personal computers. One of the more successful projects to create such a system was Linux.

Linux was created as an operating system based on UNIX, but it was meant from the start to be made free software, which the text tries to define. It was primarily created at the University of Helsinki by Linus Torvalds, who wanted to call it Freax. It was called Linux by a coworker who thought that was a better name. The coworker was probably right. As I said, our text makes an effort to explain free software, but it uses the most common metaphors that are not very clear. This article is clearer. Let me paraphrase it:

  • "Free as in beer", means that you are not charged for something. If someone gives/offers you a beer (or a coffee, or a sandwich, or whatever) and does not want money from you, that is one kind of free. If software is this kind of free, there is no charge for it. Several kinds of Linux are free in this sense, but they are not all free in the next sense.
  • "Free as in speech" means that you are allowed to have your own thoughts, needs, opinions, and expressions of the same. Software that is this kind of free is software that you are allowed to change to suit your own needs. You are allowed to make improvements to it, you can show them to people, and you can request that new versions of the software contain your improvements. This is the open source kind of free. You should note in the article I linked to above that there many kinds of license that define what freedoms you do or don't have with regard to open source software. Know your rights if you want to make changes.

Linux can be one or both kinds of free. It does not have to either kind of free. If you download a version that has no cost but you have no access to the source code, that version is only free of cost. If you download a version that costs money for a license, but you can make modifications to it, that version is only open source free.

The text spends several pages informing us that there have been several groups who have created similar products, such as Linux and GNU. Linux was meant to be both kinds of free, and some versions are. GNU was meant to be free as in speech, not necessarily free as in beer, so some versions of it are sold. Some versions of Linux follow this model as well. It might be observed that some people working on these projects have found themselves in the role of accidental adversaries, working against each other when they should have been working toward a mutual success.

The text also tells us that OS X, the Apple operating system, was developed from versions of BSD UNIX, and is very similar to Linux. The author tells us that many of the concepts in the text about Linux apply to OS X as well, and that he will point out some differences in Appendix D. Mac users are welcome to study this chapter, but this course does not cover it.

The text discusses the virtues of virtual machines (VMs) for several pages, explaining that they have value for schools and businesses that need to run, test, or develop products under several operating systems. The text also lists several VM products that can be run natively under Linux, which is a departure from the usual list of VM products that can be run under Windows. This (older) article on Lifehacker lists several favorites that can be run under multiple operating systems. We are using Virtual Box in our classroom, to run a Linux virtual machine on a Windows computer.

The author spends most of the rest of the chapter giving us a sales pitch for Linux and for the C language. We are not speaking C in this class, and we are already going to use Linux, so we can skip ahead to chapter 2.

Chapter 2

The second chapter breaks the news that this book is about things you can do from the command line. As you should know from LUX 205, there is nothing wrong with a Linux version that uses a GUI. As long as you can access the Terminal window, you can do anything that's possible from a command line.

The text covers logging in to a system with a terminal program, such as Putty or SSH. This is not needed in our environment, but it is good to know if you find yourself having to log in to a server across a network, instead of running a virtual machine that runs Linux. It is also good to be aware of the note on page 26 that computers running OS X will not allow remote logins by default.

In LUX 205, we introduced reading parameters from a command line that called a script by using $1 through $9, which allows for up to nine parameters. (There is more to it, but that isn't important right now.) On page 29, the text mentions that there is a $0 that holds the name of the program that is currently running. In the case of a command line interface, this variable will hold the name of the currently active shell.

The text discusses editing on a command line, but the shells we have been using lately do not present much of a problem in that area. More useful are the command about execution, especially ones you might enter by mistake:

  • ctrl-z Suspends the currently running process, and puts the word "stopped" on the screen.
  • fg Continues a stopped process in the foreground.
  • bg Continues a stopped process in the background.
  • The text presents several commands that may be used to stop a process that is being executed. Some processes expect one command in particular, while others are open-minded, and will accept any of the suggestions.
    • ctrl-c (interrupt command)
    • Delete key or Del key
    • ctrl-\ (quit command)
    • ctrl-z to suspend, then jobs or ps (to list processes), and kill process_number

The text gives us a section on page 31 about repeating and editing command lines. This is an example of there being several hard ways to do most things in UNIX/Linux, where one easy way would be more useful and memorable. Remember that you can usually bring up the last several command lines by pressing the up arrow key, that each of them can be edited, and that the new version can be executed by pressing the Enter key again. One might argue that the commands covered in this section could be used in a script, but so could entering the actual command you mean to have executed, instead of some shorthand, Klingon version of it, so you could read, edit, or reuse it later.

The text changes topics to consider running commands that require root (superuser) privileges.

  • The text tells us we could just log in as root, but advises us this is generally a dangerous thing to do, because you could do something to the computer that would be hard or impossible to repair. It is safer to log in as we usually do, with an ID that has more limited rights, then to assume elevated rights only when needed. Well, not so much in our case, since we are working on virtual machines, the only IDs we create typically have all rights, and we can restore the virtual Linux box by reinstalling for a minute.

  • In a real system, we tell users to use a quick workaround for individual commands. Note the syntax, and the reason a normal user won't be able to do this one:
    su -c 'command we want to perform'

    This line starts with the command su, which the text says means switch user, but really means switch to the rights of the root user for the time it takes to execute this command line.
    The -c part means what comes next is the command you want executed with elevated rights.
    The part in single quotes is the actual command you want to perform, including any parameters for the command.

    After you press Enter, the system pauses and asks for the root user's password. That's right, boys and girls, the person issuing this command has to know how to log in as root. Either we are not going to have every user on our system empowered to do this, or we are going to publish the root password in the company newsletter. Guess this one is just for admins who play by the rules.

    By the way, note in the first example on page 33 that this technique opens a new shell, and we must exit that shell to return to the shell in which we started.

  • The second example on page 33 tells us that some Linux distributions allow any user to execute a command with elevated rights by using the sudo command, followed by an authentication.
    sudo command_we_want_to_run

    This command starts with sudo, and it is immediately followed by the actual command we want to run. The system is expected to ask for a password for the current user, the authentication, and it then runs the intended command with elevated rights.
    If the sudo command is issued as noted above, it runs in the current shell, so there is no need to exit.

  • We can tell sudo to start a new shell with its -s switch, which places you in a new shell with elevated rights, and will require an exit command to return to the original shell.
    $ sudo -s
    [sudo] password:
    # commands you need to execute
    # commands you need to execute
    # exit
    $ back to original shell

The text reviews several methods for getting to help files on your system.

  • On many UNIX systems there are tutorial programs that can be started with the learn command. Working your way through this utility may be useful to you.
  • The --help option takes you through help screens about certain common UNIX commands, such as cat and ls. It is not, however, universally liked, and may be of less use to you than the man command. (Example: cat --help)
  • There is also a help command in bash. This is s command, not a switch, so it precedes the name of the command you want to learn about. (Example: help while).
  • The man command activates the on-line manual for UNIX. It may be issued by itself on a command line, or you may type the word man followed by a specific command you would like to see the manual pages for. (Example: man cal).
  • Sometimes, the man command gives you more information than you actually need at the moment. The whatis command is used to display shorter descriptions of other commands. Note that whatis does not work unless an administrator has created the database that whatis reads. This database must be created before the whatis command will work properly on some versions of UNIX/Linux.
  • The info command can be used like the man command, but the text warns us that its syntax is like that of the word processor emacs, which has not been discussed yet.

The text continues with a few more discussions that we can skip. We can move on to the third chapter.

Chapter 3

Chapter 3 is about utilities in Linux, but it takes a short side trip on page 50 to talk about special characters. These are characters that have special meaning to the operating system. For instance, we often see a switch begin with a hyphen, a backslash, or a forward slash. We also see the forward slash, /, as the delimiting (separating) character in path names. The text presents a list of special characters on page 50, and you should know some of their uses already:

& ; | * ? ' " ` [ ] ( ) $ < > { } # / \ ! ~

In fact, some of these characters have multiple meanings. For example, in a test command, an ampersand can mean AND, but when it follows a command name, it can cause the command to run in the background. And that is only what we covered in class last term.

The text goes into a rather weird place next, telling us how to override the special nature of most of characters listed above when we want to cause those characters to appear on a screen. The problem is that there is no universal solution. The text explains three different methods used to show a special character to the user:

  • The book tells us that preceding most special characters with a backslash will cause the system to forget the special meaning(s) of those characters. It calls this quoting the character (which is weird, because you are not using a quote), but it is also called using an escape sequence, or an escape character. For characters that work like this, a single backslash means to ignore the special nature of the next character. For example, if you want to show a $ on the screen, you can tell the system to echo \$. This method only works for one character at a time.
  • Single quotes are something you should have seen before. Special characters that are enclosed in single quotes are echoed like ordinary characters. There is no real limit to the number of characters that can be enclosed by the single quotes. If you tell the system to echo 'The value of variable1 can be shown by telling the system echo $variable1.', you should expect to see every character between the two apostrophes appear on the screen.

The discussion of utilities begins on the next page, where we are told that some will run only from a command line, some only from a GUI command, and some will run from either. The balance of the chapter is, in fact, a long list of utilities with brief descriptions for each one. You should review each of them, paying more attention to the ones you have not already learned.