|
|
UNIX / Linux Tutorial
1.13.9 Including Other Files | 1.13.10 Running Shell Commands
1.13.11 Getting vi Help | 1.14 Customizing Your Environment
1.14.1 Shell Scripts | 1.14.2 Shell Variables And The Environment
1.13.9 Including Other Files
If you use the :r command, you can include the contents of another file in the current
file. For example, the command:
:r foo . txt
inserts the contents of the file foo.txt in the text at the location of the cursor.
1.13.10 Running Shell Commands
You can also run shell commands within vi. The :r! command works like :r, but
rather than read a file, it inserts the output of the given command into the buffer at the
current cursor location. For example, if you use the command:
: r ! ls -F
you'll end up with:
COW IS THE TIME FOR ALL WOMEN TO COME TO THE AID OF
THE HUNGRY.
letters/
misc/
papers/_
˜
˜
You can also "shell out" of vi, in other words, run a command from within vi, and
return to the editor when you're done. For example, if you use the command:
: ! ls -F
the ls -F command will be executed and the results displayed on the screen, but not
inserted into the file you're editing. If you use the command:
: shell
vi starts an instance of the shell, letting you temporarily put vi "on hold" while
you execute other commands. Just log out of the shell (using the exit command) to return to
vi.
1.13.11 Getting vi Help
vi doesn't provide much in the way of interactive help (most Linux programs don't),
but you can always read the man page for vi. vi is a visual front-end to the ex editor;
which handles many of the last-line mode commands in vi. So, in addition to reading the
man page for vi, see ex as well.
1.14 Customizing Your Environment
A shell provides many mechanisms to customize your work environment. As mentioned
above, a shell is more than a command interpreter—it is also a powerful programming
language. Although writing shell scripts is an extensive subject, we'd like to introduce
you to some of the ways that you can simplify your work on a Linux system by using these
advanced features of the shell.
As mentioned before, different shells use different syntaxes when executing shell
scripts. For example, Tcsh uses a C-like syntax, while Bourne shells use another type.
of syntax. In this section, we won't be encountering many differences between the two, but
we will assume that shell scripts are executed using the Bourne shell syntax.
1.14.1 Shell Scripts
Let's say that you use a series of commands often and would like to save time by
grouping all of them together into a single "command". For example, the three
commands:
/ home / patrick # cat chapter1 chapter2 chapter3 > book
/ home/patrick# wc -l book
/ home/patrick# lp book
concatenates the files chapter 1, chapter 2,and chapter 3 and places the result in
the file book. The second command displays a count of the number of lines in book and
the third command lp book prints book.
Rather than type all these commands, you can group them into a shell script. The shell
script used to run all these commands might look like this:
# ! / bin / sh
# A shell script to create and print the book
cat chapter1 chapter2 chapter3 > book
wc -l book
lp book
Shell scripts are just plain text files; you can create them with an editor such as emacs or
vi.
Let's look at this shell script. The first line, "# ! /bin/sh", identifies the file
as a shell script and tells the shell how to execute the script. It instructs the shell to
pass the script to /bin/sh for execution, where /bin/sh is the shell program itself. Why is
this important? On most Linux systems, /bin/sh is a Bourne-type shell, like bash.By
forcing the shell script to run using /bin/sh, you ensure that the script will run under
a Bourne-syntax shell (rather than a C shell). This will cause your script to run using the
Bourne syntax even if you use tcsh (or another C shell) as your login shell.
The second line is a comment. Comments begin with the character "#" and continue
to the end of the line. Comments are ignored by the shell—they are commonly used to
identify the shell script to the programmer and make the script easier to understand.
The rest of the lines in the script are just commands, as you would type them to the
shell directly. In effect, the shell reads each line of the script and runs that line as if you
had typed it at the shell prompt.
Permissions are important for shell scripts. If you create a shell script, make sure that
you have execute permission on the script in order to run it. When you create text files,
the default permissions usually don't include execute permission, and you must set them
explicitly.Briefly, if this script were saved in the file called makebook, you could use
the command:
/home/patrick# chmod u+x makebook
to give yourself execute permission for the shell script makebook.
You can use the command:
/home/patrick# makebook
to run all the commands in the script.
1.14.2 Shell Variables And The Environment
A shell lets you define variables, as do most programming languages. A variable is
just a piece of data that is given a name.
tcsh, as well as other C-type shells, use a different mechanism for setting variables 3
than is described here. This discussion assumes the use of a Bourne shell like bash.See
the tcsh manual page for details.
When you assign a value to a variable (using the "=" operator), you can access the
variable by prepending a "$" to the variable name, as demonstrated below:
/home/patrick# foo=''hello there''
The variable foo is given the value hello there. You can then refer to this value by
the variable name prefixed with a "$" character. For example, the command:
/home/patrick# echo $foo
hello there
/home/patrick#
produces the same results as:
/home/patrick# echo ''hello there''
hello there
/home/patrick#
These variables are internal to the shell, which means that only the shell can access
them. This can be useful in shell scripts; if you need to keep track of a filename, for
example, you can store it in a variable, as above. Using the set command displays a list
of all defined shell variables.
However, the shell lets you export variables to the environment. The environment is
the set of variables that are accessible by all commands that you execute. Once you define
a variable inside the shell, exporting it makes the variable part of the environment as well.
Use the export command to export a variable to the environment.
Again, here we differ between bash and tcsh. If you use tcsh, another syntax is 3
used for setting environment variables (the setenv command is used). See the tcsh
manual page for more information.
The environment is very important to the UNIX system. It lets you configure certain
commands just by setting variables which the commands know about.
Here's a quick example. The environment variable PAGER is used by the man command
and it specifies the command to use to display manual pages one screen at a time.
If you set PAGER to the name of a command, it uses that command to display the man
pages, instead of more (which is the default).
Set PAGER to "cat". This causes output from man to be displayed to the screen all at
once, without pausing between pages.
/home/patrick# PAGER=cat
Now, export PAGER to the environment.
/home/patrick# export PAGER
Try the command man ls. The man page should fly past your screen without pausing for
you.
Now, if we set PAGER to "more", the more command is used to display the man page:
/home/patrick# PAGER=more
Note that we don't have to use the export command after we change the value of PAGER.
We only need to export a variable once; any changes made to it thereafter will automatically
be propagated to the environment.
It is often necessary to quote strings in order to prevent the shell from treating various
characters as special. For example, you need to quote a string in order to prevent the shell
from interpreting the special meaning of characters such as "*", "?" or a
space. There are many other characters that may need to be protected from interpretation.
A detailed explanation and description of quoting is described in SSC's Bourne Shell Tutorial.
The manual pages for a particular command tell you if the command uses any environment
variables. For example, the man man page explains that PAGER is used to specify the
pager command.
Some commands share environment variables. For example, many commands use the
EDITOR environment variable to specify the default editor to use when one is needed.
The environment is also used to keep track of important information about your login
session. An example is the HOME environment variable, which contains the name of your
home directory:
/home/patrick/papers# echo $HOME
/home/patrick
Another interesting environment variable is PS1, which defines the main shell prompt.
For example:
/home/patrick# PS1=''Your command, please: ''
Your command, please:
To set the prompt back (which contains the current working directory followed by a "#"
symbol):
Your command, please: PS1=''\ w # ''
/home/patrick#
The bash manual page describes the syntax used for setting the prompt.
The PATH environment variable. When you use the ls command, how does the
shell find the ls executable itself? In fact, ls is in /bin on most systems. The shell uses
the environment variable PATH to locate executable files for commands you type.
For example, your PATH variable may be set to:
/bin:/usr/bin:/usr/local/bin:.
This is a list of directories for the shell to search, each directory separated by a
":". When you use the command ls, the shell first looks for /bin/ls,
then /usr/bin/ls,and so on.
Note that the PATH has nothing to do with finding regular files. For example, if you
use the command:
/home/patrick# cp foo bar
the shell does not use PATH to locate the files foo and bar—those filenames are assumed
to be complete. The shell only uses PATH to locate the cp executable.
This saves you time, and means that you don't have to remember where all the command
executables are stored. On many systems, executables are scattered about in many
places, such as /usr/bin, /bin,or/usr/local/bin. Rather than give the command's
full pathname (such as /usr/bin/cp), you can set PATH to the list of directories
that you want the shell to automatically search.
Notice that PATH contains ".", which is the current working directory. This lets you
create a shell script or program and run it as a command from your current directory without
having to specify it directly (as in ./makebook). If a directory isn't in your PATH, then
the shell will not search it for commands to run; this also includes the current directory.
1.1 Introduction 1.2.10 Referring To Home Directories 1.3.4 Copying Files
1.6 Exploring The File System 1.8 Wildcards 1.9.3 Pipes 1.10.3 Permissions Dependencies
1.12.4 Stopping And Restarting Jobs 1.13.3 Inserting Text 1.13.9 Including Other Files
1.14.3 Shell Initialization Scripts System Administration 2.3.1 The /etc/imitate file
2.4 Managing File Systems 2.6 Managing Users 2.6.5 Groups 2.7.2 gzip and compress
2.8.3 Making Backups To Tape Devices 2.9.1 Upgrading The Kernel
2.9.3 Installing A Device Driver Module
BOOK: LINUX QUICK COMMAND REFERENCE
http://personal.atl.bellsouth.net/~psadler
© copyright KnowledgeWorks, Inc. (2001)