Linux编程全书：从Shell到C，再到Perl的深度探索

需积分: 9 142 浏览量更新于2024-07-28 1 收藏 3.64MB PDF 举报

"Linux Programming Bible 是一本全面介绍Linux编程的参考书籍，由John Goerzen撰写，涵盖了广泛的Linux编程主题，包括Shell基础、C环境、Linux系统模型、进程通信以及Perl编程等。" 《Linux Programming Bible》是一本针对Linux编程的百科全书，适合初学者和有经验的开发者。它分为多个部分，深入讲解了Linux编程的各个方面。第一部分 - Shell和基本工具这部分介绍了Linux编程环境，包括Shell编程的入门，如何编写Shell脚本，以及如何使用正则表达式进行文本处理。此外，还介绍了经典的文本编辑器Emacs，以及理解和处理Linux中的数据文件和脚本的方法。第二部分 - C环境在这一部分，读者将接触到C语言编程的核心，如gcc编译器的使用，项目管理工具GNUMake，内存管理，库和链接，以及使用gdb进行调试的技巧。这些章节为在Linux环境下进行C语言开发提供了坚实的基础。第三部分 - Linux模型这部分深入探讨了Linux的系统模型，包括文件、目录和设备的管理，进程的概念，信号的处理，以及Linux I/O系统的工作原理。同时，也对终端进行了介绍，帮助读者理解交互式编程的机制。第四部分 - 与世界沟通这一部分涉及进程间通信（IPC），如共享内存、信号量、管道和FIFOs，以及网络编程的基础，特别是互联网套接字，包括高级TCP/IP套接字编程，这对于开发网络应用程序至关重要。第五部分 - 黏合剂：Perl 最后，书中介绍了Perl编程，包括Perl的基本语法，数据操作，以及如何用Perl实现CGI（通用网关接口）编程，让读者能够利用Perl进行系统管理和Web开发。这本全面的指南不仅提供了理论知识，还包含大量实例和实践建议，帮助读者在实际环境中应用所学。通过学习《Linux Programming Bible》，读者可以掌握Linux平台上的程序设计、系统级编程和网络通信等关键技能。

144 199 216 281 fs mounts tty

149 2 217 3 ide mtrr uptime

162 200 218 4 interrupts net version

172 202 219 564 ioports parport

176 203 226 apm kcore partitions

Failure

$ if ls /proc; then false; else echo Failure; fi

1 182 204 236 bus kmsg pci

103 185 205 237 cmdline ksyms scsi

105 192 206 238 cpuinfo loadavg self

113 195 207 239 devices locks slabinfo

118 196 208 240 dma meminfo stat

121 197 214 241 fb misc swaps

13 198 215 280 filesystems modules sys

144 199 216 281 fs mounts tty

149 2 217 3 ide mtrr uptime

162 200 218 4 interrupts net version

172 202 219 565 ioports parport

176 203 226 apm kcore partitions

Both commands successfully executed ls. The first command then executed the false command, which is a simple program that

always returns an unsuccessful return value. Instead of ending there, this command went on to display Failure even though the ls

was a success. This behavior is probably a bug. The second command executed the same ls, and the same false command.

However, it skips the echo if the ls is successful, regardless of the result of the false command. This is probably the desired

behavior.

Wildcards

Shell scripts frequently need to be capable of processing groups of files at once. Linux shells provide a capability of specifying

multiple files at once by giving a particular pattern. These files that match the pattern are then specified as if they had been typed

on the command line. Wildcards are the special characters used to form these patterns. The entire operation of specifying gro

ups of

files in this way is often referred to as globbing.

Each wildcard has a special meaning; that is, it can represent certain characters. Table 2-2 lists the most common wildcards and

explains their meaning and usage.

Table 2-2: Common Wildcards

Character

Meaning

Example

Matches zero or more characters.

*.c matches the a.c, asdf. c, and even .c files.

Matches exactly one character.

Letter9?.txt matches Letter90.txt, Letter95. txt,

Letter9A.txt, and Letter9..txt, but not

Letter95A.txt.

[...](character class)

Matches exactly one character from the

characters specified between the

brackets.

Letter9[A13].txt matches only Letter9A.txt,

Letter91.txt, and Letter93.txt. No other files

match.

[...](character range)

Matches exactly one character from the

range(or ranges) of characters specified

between the brackets.

Letter9[a-c1-3].txt matches Letter9a.txt,

Letter9b.txt, Letter9c.txt, Letter91.txt,

Letter92.txt, and Letter93. txt. No other files

match.

[^...](Negated character class

or range)

Matches exactly one character that does

not occur in the specified ranges or

characters listed.

Letter9[^9a-c1-2].txt matches any files that

would normally match the Letter9?. txt pattern

except for the files Letter99.txt, Letter9a. txt,

Letter9b.txt, Letter9c. txt, Letter91.txt, and

Letter92.txt.

{..., ...}

Alternation; matches exactly one of the

given substrings.

Letter{90,92,ABC}.txt matches only the files

Letter90. txt, Letter92.txt, and LetterABC.txt.

Quoting and escaping

In some situations, you may prefer to avoid having the shell interpret the wildcards, variables, or other special characters that may

occur on your comma

nd lines. Bash provides you with ways to indicate that these items should not be treated as normal characters,

without special meaning.

There are two methods for doing this. The first method, quoting, enables you to enclose whatever items you want to be taken

literally inside either single or double quotes. The second method, escaping, enables you to place a backslash immediately before

the character that you wish to be taken literally.

You use two characters for quoting: “ and ‘. The double-quote character is a bit weaker than the single-quote character; the double-

quote permits some special characters to function as they normally do. The single quote is stronger and prevents nearly everything

from functioning. Let’s examine a situation in which the single quote is more useful than the double quote, which is shown in the

following example:

$ echo hi > “Test File”

$ ls -l Test File

ls: Test: No such file or directory

ls: File: No such file or directory

$ ls -l “Test File”

-rw-rw-r-- 1 username username 3 Jul 23 09:08 Test File

$ rm “Test File”

The first line generates a file named Test File (note the space) and places the word “hi” into it. The second line is an attempt to

display information about the file. However, it doesn’t work. In this situation, the space character is special! It acts as a separator

between files, so Bash tells ls that it should act upon two separate files: Test and File. Obviously, this isn’t quite going to work

right.

Next, the third command places the filename inside dou

ble quotes. This time, Bash does not split the name into two files, so ls

looks for information on only one file. Similarly, with the rm

command, the file must be placed in quotes in order for it to function

properly.

A key difference between “ and ‘ lies with variable interpolation, which will be discussed in the Variables section later in this

chapter. The ‘ character prohibits variable interpolation, while the “ character does not. This means that the dollar sign is not safe

inside strings quoted with the double quote. Here’s an example of that behavior:

$ echo “Path: $PATH”

Path: /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

$ echo ‘Path: $PATH’

Path: $PATH

Because of this, many Bash programmers prefer to use single quotes for safety unless they have a specific reason to use double

quotes.

An alternative to quoting is escaping. Escaping can provide some benefits; when you use escaping for a particular character, you

always know that it is effective. A problem occurs when a string being quoted must contain the quote character itself; in such a

situation, escaping must be used.

Escaping is done in Bash by inserting a backslash before the special character. You don’t need to enclose the entire string in

quotes. However, every special character must be escaped. Here is an example:

$ echo hello > “Another Test File”

$ ls -l Another Test\ File

ls: Another: No such file or directory

ls: Test File: No such file or directory

$ ls -l Another\ Test\ File

-rw-rw-r-- 1 user user 6 Jul 23 09:25 Another Test File

$ rm Another\ Test\ File

The first line uses quoting as before. In the second line, one of the space characters is escaped. Because of this, ls looks for two

instead of three files; however, this is still not the desired behavior. When both spaces are escaped, the entire name is passed to ls

intact just as with the quotes. Similarly, the filename is passed intact with rm.

Unlike quotes, you should not escape things that are not special characters. Some sequences, such as \n

, have special meanings and

generate other characters in some situations.

Sometimes you may need to combine escapes with quotes. A typical example occurs when the string that is quoted contains an

example of the quote character itself. This situation can be extremely confusing at a shell prompt, so create the following script

and name it quotetest.sh:

#!/bin/bash

echo ‘Mary said, “I don’t use DOS.”’

After you have saved the file, you need to mark it executable, and then run it:

$ chmod a+x quotetest.sh

$ ./quotetest.sh

./quotetest.sh: line 3: unexpected EOF while looking for matching `”’

./quotetest.sh: line 4: syntax error: unexpected end of file

Bash obviously had some terrible trouble trying to deal with that statement. What happened is that the apostrophe in “don’t” was

treated as the end of the quoted string. When Bash encountered the quote after the word DOS, it considered it to be the start of a

new quoted string. However, this new string was never terminated.

The solution to this mess is to use escaping. Should you stay with single quotes and escape the apostrophe, or should you use

double quotes and escape them inside the string as necessary? Well, recall earlier that the single quotes are stronger than the

double quotes. One of the things that this applies to is escaping; escaping the apostrophe isn’t going to help. You can try this at the

prompt:

$ echo ‘Test \’ Test2

Test \ Test2

The backslash was taken literally, and did not cause Bash to actually print the embedded quote. The solution is to use double-

quote

characters. Modify the script so it looks like this:

#!/bin/bash

echo “Mary said, \”I don’t use DOS.\””

This time, the string is set off by double quotes. When you try running that script, you finally get the desired result:

$ ./quotetest.sh

Mary said, “I don’t use DOS.”

The script looks a bit complicated, but really it’s not tricky once you understand what’s going on. Everything is as we’ve seen

before, prior to the first backslash. The \” sequence tells Bash to print a quote character rather than use that character to indicate

the end of the string. Because the string is delimited by double quotes in this situation, the embedded apostrophe doesn’t pose any

challenge. Towards the end of the string, there is another \” sequence. Once again, this informs Bash to print the character instead

of interpreting it as the end of the string. Finally, the last character on the line is the character that closes the string.

Another option for all of this is to use escaping. You could use it like this:

$ echo Mary\ said,\ \”I\ don\’t\ use\ DOS.\”

Mary said, “I don’t use DOS.”

This option is somewhat less intuitive; you must escape every space and quote character. However, the effect is the same as with

the double quotes used above.

You should be familiar with two more special cases. First, if you want to send a backslash itself to a program, you need to escape

it. This is done as follows:

$ echo Good \\ Morning

Good \ Morning

$ echo Good \ Morning

Good Morning

Notice that the backslash didn’t appear in the output from the second command. The reason is that Bash interpreted it as escaping

the following space. In the first command, however, it did appear.

One other reason you might want to use the backslash is to enable you to split long lines into pieces. If you choose to do that, the

backslash must be the very last character on the line preceding the one with which it should be combined. Here’s an example

script.

#!/bin/bash

ls -l /dev/hda1 /dev/hda2 /dev/hda3 \

/dev/hda4 /dev/hda5 /dev/hda6 \

/dev/hda7

In this script, the long ls command line was split into three parts to make editing and manipulation easier. When the script is run,

Bash will combine the three parts back into a single line before executing the command.

Comments

You can insert comments into your Bash script. Like Perl, comments begin with a # symbol. Any text from that symbol until the

end of the line is ignored by Bash. Here are some examples of using comments in a script.

#!/bin/bash

# This is a Bash script.

ls /proc # Display a list of files in /proc

cat /proc/devices # Display the devices on the system

cat /proc/interrupts # Display a list of IRQs

Commenting is a very important part of writing programs. As you move into writing larger and larger ones,

comments will play an

increasingly important role in maintainability and documentation. This idea applies to shell scripts as well.

Note

The line beginning with #! at the start of each shell script has special meaning for the operating system. It indicates the

name of the interpreter used to execute the script. However, because # is the Bash comment character, Bash ignores the

line when the file is processed as a script. Therefore, it does not bother Bash when your script is executed.

Redirection and Piping

One of the most powerful features of the Linux shell i

s being able to combine programs in unique, arbitrary ways to form solutions

to new problems. The primary ways of doing this are with redirection and piping.

Redirection enables you to take that which would normally be displayed on the terminal and save it into a file. Also, input

redirection enables you to substitute the contents of a file for what would normally be typed on the keyboard.

Piping enables you to chain commands together, sending the output from one command into the input of the next. All the

commands run simultaneously, processing the data at once, as parts of a pipe.

These different capabilities are made possible by the Linux notion of the standard input and output for programs. By default, each

program has three standard file handles: standard input, standard output, and standard error. Standard input is used for reading

data, and reads data from the terminal’s keyboard by default. Standard output is used for displaying normal data, and is connected

to the terminal’s screen by default. Standard error is used for displaying error messages, and is also connected to the terminal’s

screen by default.

Table 2-3 contains a summary of these three Input/Output (I/O) channels.

Table 2-3: Standard Input/Output Channels

Name

Shorthand

Number

Purpose

Default Connection

Standard Input

Stdin

Reading input for a program

The terminal’s keyboard

Standard Output

stdout

Displaying normal output

from a program

The terminal’s display

Standard Error

stderr

Displaying error messages

or warnings of unusual

situations

The terminal’s display

Output redirection

The most straightforward way to use redirection is to use output redirection. In its simplest form, the messages that normally go to

the screen instead are placed into a file.

$ ls -l /dev/hda*

brw-rw---- 1 root disk 3, 0 Feb 22 21:41 /dev/hda

brw-rw---- 1 root disk 3, 1 Feb 22 21:41 /dev/hda1

brw-rw---- 1 root disk 3, 10 Feb 22 21:41 /dev/hda10

brw-rw---- 1 root disk 3, 11 Feb 22 21:41 /dev/hda11

brw-rw---- 1 root disk 3, 12 Feb 22 21:41 /dev/hda12

brw-rw---- 1 root disk 3, 13 Feb 22 21:41 /dev/hda13

brw-rw---- 1 root disk 3, 14 Feb 22 21:41 /dev/hda14

brw-rw---- 1 root disk 3, 15 Feb 22 21:41 /dev/hda15

brw-rw---- 1 root disk 3, 16 Feb 22 21:41 /dev/hda16

brw-rw---- 1 root disk 3, 17 Feb 22 21:41 /dev/hda17

brw-rw---- 1 root disk 3, 18 Feb 22 21:41 /dev/hda18

brw-rw---- 1 root disk 3, 19 Feb 22 21:41 /dev/hda19

brw-rw---- 1 root disk 3, 2 Feb 22 21:41 /dev/hda2

brw-rw---- 1 root disk 3, 20 Feb 22 21:41 /dev/hda20

brw-rw---- 1 root disk 3, 3 Feb 22 21:41 /dev/hda3

brw-rw---- 1 root disk 3, 4 Feb 22 21:41 /dev/hda4

brw-rw---- 1 root disk 3, 5 Feb 22 21:41 /dev/hda5

brw-rw---- 1 root disk 3, 6 Feb 22 21:41 /dev/hda6

brw-rw---- 1 root disk 3, 7 Feb 22 21:41 /dev/hda7

brw-rw---- 1 root disk 3, 8 Feb 22 21:41 /dev/hda8

brw-rw---- 1 root disk 3, 9 Feb 22 21:41 /dev/hda9

$ ls -l /dev/hda* > listing

The first ls command displays a long listing of the files in /dev

beginning with hda. As is customary, this listing is displayed on the

screen. The second command requests the same listing, this time redirecting the output into the file named listing. The greater-

than

symbol ( >) is the output redirection operator; it requests that the items that would normally go to standard output be sent to the

specified file. To be specific, it is changing what standard output is connected to; normally, it’s connected to the terminal’s

display. Here, standard output is connected to the file named listing. You can verify that this file actually contains the data that

normally would have been sent to the screen by using the cat command:

$ cat listing

brw-rw---- 1 root disk 3, 0 Feb 22 21:41 /dev/hda

brw-rw---- 1 root disk 3, 1 Feb 22 21:41 /dev/hda1

剩余516页未读，继续阅读

welcomeem

粉丝: 9
资源: 40

Linux编程全书：从Shell到C，再到Perl的深度探索

Linux+Programming+Bible+examples

KDE 2.Qt Programming Bible_kde_

[Linux.Bible][2005.Edition]

Linux alsa 学习书籍推荐

推荐几本入门Linux的书

有关liunx的英文参考文献

在Ubuntu Linux系统中如何安装和配置Apache、MySQL和PHP（LAMP）环境？请提供详细的步骤和命令。

提供Linux的学习资料

Linux服务搭建参考文献

宋宝华 linux 驱动 pdf

最新资源