UNIX编程艺术：Eric Steven Raymond

需积分: 0 46 浏览量更新于2024-07-24 收藏 2.21MB PDF 举报

"The Art of UNIX Programming 是一本由 Eric Steven Raymond 编著的关于UNIX编程艺术的书籍，旨在探讨和分享UNIX系统设计与编程的最佳实践。本书的电子版遵循 Creative Commons Attribution-NoDerivs 1.0 许可协议，允许非商业性使用，但保留了纸质出版和盈利使用的权利给 Pearson Education, Inc.。书中涵盖了多个IBM、Compaq、Apple、Microsoft、Sun Microsystems等公司的商标技术，如AIX、UNIX、DB/2、MacOS、Java、J2EE等。" 在《UNIX编程艺术》中，Eric Steven Raymond深入探讨了UNIX操作系统的哲学和设计原则，这些原则不仅影响了UNIX本身，还对后来的开源软件和操作系统产生了深远的影响。以下是书中的关键知识点： 1. **UNIX哲学**：书中强调简洁、模块化和工具间的协作。每个程序应专注于做一件事并做好，通过管道和其他机制与其他程序协同工作。 2. **Shell脚本编程**：介绍了如何使用Bash或其他shell编写自动化任务，包括命令行参数处理、条件语句、循环和函数。 3. **文本处理工具**：详述了sed、awk和grep等经典工具的用法，这些工具是UNIX/Linux环境中强大的文本处理基础。 4. **I/O重定向和管道**：讲解了如何利用I/O重定向和管道来连接不同程序，实现数据流的高效传输。 5. **版本控制系统**：虽然书中可能未提及现代的Git，但会讨论早期的CVS和SVN，它们在软件开发中的版本控制和协作重要性。 6. **网络编程**：由于UNIX在互联网发展中的角色，书中可能会涵盖TCP/IP套接字编程，以及如何创建网络服务。 7. **程序设计风格**：讨论了良好的代码组织、错误处理和可读性，这些都是写出高质量UNIX软件的关键。 8. **标准库和API**：介绍了C语言的标准库函数以及POSIX API，它们是UNIX应用程序的基础。 9. **文件系统**：讲解了UNIX的层次结构文件系统模型，以及如何高效地使用文件和目录。 10. **进程管理**：涵盖了进程创建、通信和信号机制，这些对于理解多任务环境至关重要。 11. **系统调用**：深入系统内核层面，讨论如何直接调用操作系统提供的服务。 12. **移植性**：由于UNIX的开放性和跨平台特性，书中可能会探讨如何使程序在不同UNIX变种之间保持兼容。 13. **调试和性能分析**：介绍了一些基本的调试工具和性能分析技巧，帮助开发者优化程序。 14. **软件开发流程**：UNIX社区的开源开发模式和协同开发方法，例如RFC过程和开源许可证的应用。通过学习《UNIX编程艺术》，开发者不仅可以掌握UNIX编程的基本技能，还能理解其背后的思考方式，这对于理解和参与开源软件项目，或者在任何现代操作系统环境下进行高效编程都具有极大的价值。

List of Tables

8.1. Regular-expression examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

8.2. Introduction to regular-expression operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

14.1. Language choices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

14.2. Summary of X Toolkits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

xiv

List of Examples

5.1. Password ﬁle example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.2. A .newsrc example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.3. A fortune ﬁle example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

5.4. Basic data for three planets in a record-jar format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.5. An XML example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5.6. A .INI ﬁle example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5.7. An SMTP session example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

5.8. A POP3 example session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

5.9. An IMAP session example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6.1. An example fetchmail -v transcript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

6.2. An SNG Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

7.1. The pic2graph pipeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

8.1. Glade Hello, World. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

8.2. A sample m4 macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

8.3. A sample XSLT program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

8.4. Taxonomy of languages — the pic source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

8.5. Synthetic example of a fetchmailrc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

8.6. RSA implementation using dc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

9.1. Example of fetchmailrc syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

9.2. Python structure dump of a fetchmail conﬁguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

9.3. copy_instance metaclass code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

9.4. Calling context for copy_instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

9.5. ascii usage screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

9.6. Desired output format for the star table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

9.7. Master form of the star table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

10.1. A .netrc example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

10.2. X conﬁguration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

18.1. groff1 markup example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

18.2. man markup example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

19.1. tar archive maker production. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

Preface

Unix is not so much an operating system as an oral history.

<author>NealStephenson</author>

There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right

thing to do; expertise makes the right thing a reﬂex, hardly requiring conscious thought at all.

This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach

you the things about Unix development that Unix experts know, but aren’t aware that they know.

It is therefore less about technicalia and more about shared culture than most Unix books — both

explicit and implicit culture, both conscious and unconscious traditions. It is not a ‘how-to’ book,

it is a ‘why-to’ book.

The why-to has great practical importance, because far too much software is poorly designed. Much

of it suffers from bloat, is exceedingly hard to maintain, and is too difﬁcult to port to new platforms

or extend in ways the original programmers didn’t anticipate. These problems are symptoms of bad

design. We hope that readers of this book will learn something of what Unix has to teach about

good design.

This book is divided into four parts: Context, Design, Tools, and Community. The ﬁrst part

(Context) is philosophy and history, to help provide foundation and motivation for what follows.

The second part (Design) unfolds the principles of the Unix philosophy into more speciﬁc advice

about design and implementation. The third part (Tools) focuses on the software Unix provides

for helping you solve problems. The fourth part (Community) is about the human-to-human

transactions and agreements that make the Unix culture so effective at what it does.

Because this is a book about shared culture, I never planned to write it alone. You will notice that

the text includes guest appearances by prominent Unix developers, the shapers of the Unix tradition.

The book went through an extended public review process during which I invited these luminaries

to comment on and argue with the text. Rather than submerging the results of that review process

in the ﬁnal version, these guests were encouraged to speak with their own voices, amplifying and

developing and even disagreeing with the main line of the text.

In this book, when I use the editorial ‘we’ it is not to pretend omniscience but to reﬂect the fact that

it attempts to articulate the expertise of an entire community.

xvi

Preface

Because this book is aimed at transmitting culture, it includes much more in the way of history and

folklore and asides than is normal for a technical book. Enjoy; these things, too, are part of your

education as a Unix programmer. No single one of the historical details is vital, but the gestalt of

them all is important. We think it makes a more interesting story this way. More importantly,

understanding where Unix came from and how it got the way it is will help you develop an intuitive

feel for the Unix style.

For the same reason, we refuse to write as if history is over. You will ﬁnd an unusually large number

of references to the time of writing in this book. We do not wish to pretend that current practice

reﬂects some sort of timeless and perfectly logical outcome of preordained destiny. References to

time of writing are meant as an alert to the reader two or three or ﬁve years hence that the associated

statements of fact may have become dated and should be double-checked.

Other things this book is not is neither a C tutorial, nor a guide to the Unix commands and API. It

is not a reference for sed or yacc or Perl or Python. It’s not a network programming primer, nor an

exhaustive guide to the mysteries of X. It’s not a tour of Unix’s internals and architecture, either.

Other books cover these speciﬁcs better, and this book points you at them as appropriate.

Beyond all these technical speciﬁcs, the Unix culture has an unwritten engineering tradition that has

developed over literally millions of man-years

of skilled effort. This book is written in the belief

that understanding that tradition, and adding its design patterns to your toolkit, will help you become

a better programmer and designer.

Cultures consist of people, and the traditional way to learn Unix culture is from other people and

through the folklore, by osmosis. This book is not a substitute for person-to-person acculturation,

but it can help accelerate the process by allowing you to tap the experience of others.

Who Should Read This Book

You should read this book if you are an experienced Unix programmer who is often in the position

of either educating novice programmers or debating partisans of other operating systems, and you

ﬁnd it hard to articulate the beneﬁts of the Unix approach.

You should read this book if you are a C, C++, or Java programmer with experience on other

operating systems and you are about to start a Unix-based project.

The three and a half decades between 1969 and 2003 is a long time. Going by the historical trend curve in number of Unix

sites during that period, probably somewhere upwards of ﬁfty million man-years have been plowed into Unix development

worldwide.

xvii

Preface

You should read this book if you are a Unix user with novice-level up to middle-level skills in

the operating system, but little development experience, and want to learn how to design software

effectively under Unix.

You should read this book if you are a non-Unix programmer who has ﬁgured out that the Unix

tradition might have something to teach you. We believe you’re right, and that the Unix philosophy

can be exported to other operating systems. So we will pay more attention to non-Unix environments

(especially Microsoft operating systems) than is usual in a Unix book; and when tools and case

studies are portable, we say so.

You should read this book if you are an application architect considering platforms or implemen-

tation strategies for a major general-market or vertical application. It will help you understand

the strengths of Unix as a development platform, and of the Unix tradition of open source as a

development method.

You should not read this book if what you are looking for is the details of C coding or how to use

the Unix kernel API. There are many good books on these topics; Advanced Programming in the

Unix Environment [Stevens92] is classic among explorations of the Unix API, and The Practice of

Programming [Kernighan-Pike99] is recommended reading for all C programmers (indeed for all

programmers in any language).

How to Use This Book

This book is both practical and philosophical. Some parts are aphoristic and general, others will

examine speciﬁc case studies in Unix development. We will precede or follow general principles

and aphorisms with examples that illustrate them: examples drawn not from toy demonstration

programs but rather from real working code that is in use every day.

We have deliberately avoided ﬁlling the book with lots of code or speciﬁcation-ﬁle examples, even

though in many places this might have made it easier to write (and in some places perhaps easier

to read!). Most books about programming give too many low-level details and examples, but fail at

giving the reader a high-level feel for what is really going on. In this book, we prefer to err in the

opposite direction.

Therefore, while you will often be invited to read code and speciﬁcation ﬁles, relatively few are

actually included in the book. Instead, we point you at examples on the Web.

xviii

剩余548页未读，继续阅读

Norman163

粉丝: 0
资源: 10

UNIX编程艺术：Eric Steven Raymond

The Art Of Unix Programming

The Art of Unix Programming

UNIX编程艺术The Art of Unix Programming

The art of unix programming

The art of unix programming， UNIX编程艺术

The Art Of Unix Programming.rar

The Art of Unix Programming.pdf

文字生成视频-可灵1.6

广告监管领域行风突出问题排查报告.docx

Richdad（穷爸爸富爸爸现金流游戏）卷2

最新资源