Bourne tutorial



Yüklə 478,18 Kb.
Pdf görüntüsü
səhifə3/20
tarix08.10.2017
ölçüsü478,18 Kb.
#3721
1   2   3   4   5   6   7   8   9   ...   20

+--------------------------------------------------------------+

|

    Table 2



       |

|

      Filename Expansion with directories



       |

|Pattern   Matches

       |

+--------------------------------------------------------------+

|*

   All non-invisible files



       |

|abc/*


   All non-invisible files in directory abc

       |


|abc/.*    All invisible files in directory abc

       |


|*/*

   All non-invisible files in all subdirectories below |

|*/.*

   All invisible files in all subdirectories below     |



+--------------------------------------------------------------+

Filename expansions are based on the current directory, unless the filename starts with a slash.

The Bourne shell differs from the C shell if the meta-characters do not match any file. If this happens, the

pattern is passed to the program unchanged. (The C shell will either do this, or generate an error, depending

on a variable).

If you are not sure how something will expand, use the echo command to check. It generates output more

compact than ls, and it will not list contents of directories like ls will. You will also notice the output is sorted

alphabetically. The shell not only expans filenames, but sorts them, for all applications.

Finding the executable

Once the shell expands the command line, it breaks up the line into words, and takes the first word as the

command to be executed. (The special Bourne variable "IFS" contains the characters used to "break up" the

line. Normally, this variable contains a space and a tab.) Afterwards, the first word is used as the name of the

program. If the command is specified without an explicit directory path, the shell then searches the different

directories specified by the "PATH" variable, until it finds the program specified.

If you have been following the points I made, it should not surprise you that a valid UNIX command might be

*

The contents of the directory determines the results, but if you created a file called "0," which contains



#!/bin/sh

echo Hey! You forgot to specify the command!

Click here to get file: 

0.sh


and if it is the first file (alphabetically) in your directory, then executing "*" would give you an error message.

(Provided the current directory was in your search path).

So you see, filename expansion can be anywhere on a command line. You can execute programs with long

names without typing the entire name. However, filename expansion only works if the file is in the directory

you specify. If you wanted to execute the program "my_very_own_program" without typing the complete

filename, you could type

my_* arguments

as long as "my_*" expanded to a unique program name. If this was in another directory, then you you have to

specify the directory path:

Bourne Shell Tutorial

http://www.grymoire.com/Unix/Sh.html

7 of 66


11/21/2011 12:03 PM


/usr/local/bin/my_* arguments

Understanding the relationship between the shell and the programs allows you to add features. Some people

create a file called "-i" in a directory. If someone then types

rm *


while in this directory, the first argument will probably be "-i." This filename is passed to the rm program,

which assumes the hyphen indicates an argument. Therefore rm runs with the interactive option, protecting

programs from accidental deletion.

One last point. Many DOS users complain that they can't execute

RENAME *.OLD *.NEW

I admit that this is a little awkward to do in UNIX. I'd like to say two things in defense. First, the above usage

of filename expansion is an "unnatural act," as far as the UNIX philosophy is concerned. There are many

advantages to the shell handling the filename expansion, and perhaps one disadvantage in one case. I believe

the advantages of the UNIX philosophy far outweight the disadvanges.

Second, I don't believe it is a disadvantage anyway. Renaming files like that is wrong. The only reason to do

so is because DOS does it that way, and you have to to this because you are limited to 11 characters. If you

must rename them, append a string to the end instead of changing the original filename. This is UNIX. You

can have filenames 256 characters long, so this approach isn't a problem. So if you must rename them, use

for i in *.OLD

do

mv $i $i.NEW



done

This alows you to undo what you did, and retains the original filename. Even better, move the files into

another directory, letting them keep their original name. I would suggest you type

mkdir Old

mv *.OLD Old

This makes undoing your action very easy, and works for files of any name, and not just "*.OLD."

Quoting with the Bourne Shell

The first problem shell programmers experience is quotation marks. The standard keyboard has three

quotation marks. Each one has a different purpose, and only two are used in quoting strings. Why quote at all,

and what do I mean by quoting? Well, the shell understands many special characters, called meta-characters.

These each have a purpose, and there are so many, beginners often suffer from meta-itis. Example: The dollar

sign is a meta-character, and tells the shell the next word is a variable. If you wanted to use the dollar sign as

a regular character, how can you tell the shell the dollar sign does not indicate a variable? Answer: the dollar

sign must be quoted. Why? Quoted characters do not have a special meaning. Let me repeat this with

emphasis.

Quoted characters do not have a special meaning

A surprising number of characters have special meanings. The lowly space, often forgotten in many books, is

an extremely important meta-character. Consider the following:

Bourne Shell Tutorial

http://www.grymoire.com/Unix/Sh.html

8 of 66

11/21/2011 12:03 PM




Yüklə 478,18 Kb.

Dostları ilə paylaş:
1   2   3   4   5   6   7   8   9   ...   20




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©www.genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə