BBS.ChinaUnix.net
½ñÈÕÍÆ¼ö    Ê×Ò³ | ÐÂÎÅ | Linux | AIX | ²©¿Í | ÂÛ̳ | ´æ´¢ | È˲Š| Åàѵ | ֪ʶ¿â | ×ÊÁÏ | ¶ÁÊé | ÊÖ²á | ¾«»ª | ÏÂÔØ | ¿Õ¼ä     
  »áÔ±: ÃÜÂë: Ãâ·Ñ×¢²á | Íü¼ÇÃÜÂë | »áÔ±µÇ¼ | ËÑË÷ | °ïÖú 


The Art of Unix Programming
Ê×Ò³ » ÂÛ̳ » ITͼÊéÓëÆÀÂÛ »  
[´òÓ¡] [¶©ÔÄ] [ÊÕ²Ø] [ÍÆ¼ö¸øÅóÓÑ] [±¾ÌûÎı¾Ò³]
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
1Â¥ ·¢±íÓÚ 2008-5-18 01:10 
[local]1[/local]

Dedication
To Ken Thompson and Dennis Ritchie, because you inspired me.

Table of Contents

Requests for reviewers and copy-editors
Preface
Who Should Read This Book
How To Use This Book
Related References
Conventions Used In This Book
Our Case Studies
Author's Acknowledgements



I. Context
1. Philosophy
Culture? What culture?
The durability of Unix
The case against learning Unix culture
What Unix gets wrong
What Unix gets right
Open-source software
Cross-platform portability and open standards
The Internet
The open-source community
Flexibility in depth
Unix is fun to hack
The lessons of Unix can be applied elsewhere



Basics of the Unix philosophy
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected with other
programs.

[ ±¾Ìû×îºóÓÉ haoji ÓÚ 2008-5-29 15:23 ±à¼­ ]



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
2Â¥ ·¢±íÓÚ 2008-5-18 01:12 
Rule of Clarity: Clarity is better than cleverness.
Rule of Simplicity: Design for simplicity; add complexity only where
you must.
Rule of Transparency: Design for visibility to make inspection and
debugging easier.
Rule of Robustness: Robustness is the child of transparency and
simplicity.
Rule of Least Surprise: In interface design, always do the least
surprising thing.
Rule of Repair: Repair what you can — but when you must fail, fail
noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in
preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write
programs when you can.
Rule of Representation: Use smart data so program logic can be stupid
and robust.
Rule of Separation: Separate policy from mechanism; separate
interfaces from engines.
Rule of Optimization: Prototype before polishing. Get it working before
you optimize it.
Rule of Diversity: Distrust all claims for one true way.
Rule of Extensibility: Design for the future, because it will be here
sooner than you think.



The Unix philosophy in one lesson
Applying the Unix philosophy
Attitude matters too



2. History
Origins and history of Unix, 1969-1995
Genesis: 1969-1971
Exodus: 1971-1980
TCP/IP and the Unix Wars: 1980-1990
Blows against the empire: 1991-1995



Origins and history of the hackers, 1961-1995
At play in the groves of academe: 1961-1980



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
3Â¥ ·¢±íÓÚ 2008-5-18 01:13 
Internet fusion and the Free Software Movement: 1981-1991
Linux and the pragmatist reaction: 1991-1998



The open-source movement: 1998 and onward.
The lessons of Unix history



3. Contrasts
The elements of operating-system style
What is the unifying idea?
Cooperating processes
Internal boundaries
File attributes and record structures
Binary file formats
Preferred UI style
Who is the intended audience?
What are the entry barriers to development?



Operating-system comparisons
VMS
Mac OS
OS/2
Windows NT
BeOS
Linux



What goes around, comes around






II. Design
4. Modularity
Encapsulation and optimal module size
Compactness and orthogonality
Compactness
Orthogonality
The DRY rule
The value of detachment



Top-down, bottom-up, and glue layers
Case study: C considered as thin glue



Library layering
Case study: GIMP plugins



Unix and object-oriented languages



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
4Â¥ ·¢±íÓÚ 2008-5-18 01:13 
Coding for modularity



5. Textuality
The Importance of Being Textual
Case study: Unix password file format
Case study: .newsrc format
Case study: The PNG graphics file format



Data file metaformats
/etc/passwd style
RFC-822 format
Fortune-cookie format
XML
Windows INI format
Unix textual file format conventions



Application protocol design
Case study: SMTP, a simple socket protocol
Case study: POP3, the Post Office Protocol
Case study: IMAP, the Internet Message Access Protocol



Application protocol metaformats
The classical Internet application metaprotocol
HTTP as a universal application protocol
BEEP
XML-RPC. SOAP, and Jabber



Binary files as caches



6. Multiprogramming
Separating complexity control from performance tuning
Handing off tasks to specialist programs
Case study: the mutt mail user agent.



Pipes, redirection, and filters
Case study: Piping to a Pager
Case study: making word lists
Case study: pic2graph
Case study: bc(1) and dc(1)



Slave processes
Case study: scp(1) and ssh



Wrappers



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
5Â¥ ·¢±íÓÚ 2008-5-18 01:14 
Case study: backup scripts



Security wrappers and Bernstein chaining
Peer-to-peer inter-process communication
Signals
System daemons and conventional signals
Case study: fetchmail's use of signals
Temp files
Shared memory via mmap
Sockets
Obsolescent Unix IPC methods



Client-Server Partitioning for Complexity Control
Case study: PostgreSQL
Case study: Freeciv



Two traps to avoid
Remote procedure calls
Threads — threat or menace?
A fearful synergy






7. Transparency
Some case studies
Case study: audacity
Case study: fetchmail's -v option
Case study: kmail
Case study: sng
Case study: the terminfo database
Case study: Freeciv data files



Designing for transparency and discoverability
The Zen of transparency
Coding for transparency and discoverability.
Transparency and avoiding overprotectiveness.
Transparency and editable representations.
Transparency, fault diagnosis, and fault recovery



Designing for maintainability



8. Minilanguages
Taxonomy of languages
Applying minilanguages



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
6Â¥ ·¢±íÓÚ 2008-5-18 01:14 
Case study: sng
Case study: Glade
Case study: m4
Case study: XSLT
Case study: the DWB tools
Case study: fetchmailrc
Case study: awk
Case study: PostScript
Case study: bc and dc
Case study: Emacs Lisp
Case study: JavaScript



Designing minilanguages
Choosing the right complexity level
Extended and embedded languages
When you need a custom grammar
Macros — beware!
Language or application protocol?






9. Generation
Data-driven programming
Regular expressions
Case Study: ascii
Case Study: metaclass hacking in fetchmailconf



Ad-hoc code generation
Case study: generating code for a fixed screen display
Case study: generating HTML code for a tabular list



Special-purpose code generators
Yacc and Lex
Glade



Avoiding traps



10. Configuration
Run-control files
Case study: The .netrc file
Portability to other operating systems



Environment variables
Portability to other operating systems



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
7Â¥ ·¢±íÓÚ 2008-5-18 01:15 
Command-line options
The a to z of command-line options
Portability to other operating systems



How to choose among configuration-setting methods
Case study: fetchmail
Case study: the XFree86 server



On breaking these rules



11. Interfaces
Applying the Rule of Least Surprise
History of interface design on Unix
The right style for the right job
Tradeoffs between CLI and visual interfaces
Case study: Two ways to write a calculator program



Unix interface design patterns
The filter pattern
The cantrip pattern
The emitter pattern
The absorber pattern
The compiler pattern
The ed pattern
The rogue pattern
The ‘separated engine and interface’ pattern
The CLI server pattern
Language-based interface patterns



Applying Unix design patterns
The polyvalent-program pattern



The Web browser as universal front end
Silence is golden






III. Implementation
12. Languages
Unix's Cornucopia of Languages
Why Not C?
Interpreted Languages and Mixed Strategies
Language evaluations
C



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
8Â¥ ·¢±íÓÚ 2008-5-18 01:16 
C++
Shell
Perl
Tcl
Python
Java
Emacs Lisp



Trends for the Future
Choosing an X toolkit



13. Tools
A developer-friendly operating system
Choosing an editor
vi: lightweight but limited
Emacs: heavy metal editing
The benefits of knowing both
Is Emacs an argument against the Unix philosophy?



Make: automating your development recipes
Basic theory of make(1)
Make in non-C/C++ Development
Utility productions
Generating makefiles



Version-control systems
Why version control?
Version control by hand
Automated version control
Unix tools for version control



Run-time debugging
Profiling
Emacs as the universal front end
Emacs and make(1)
Emacs and run-time debugging
Emacs and version control
Emacs and Profiling
Like an IDE, only better...






14. Re-Use



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
9Â¥ ·¢±íÓÚ 2008-5-18 01:16 
The tale of J. Random Newbie
Transparency as the key to re-use
From re-use to open source
The best things in life are open
Where should I look?
What are the issues in using open-source software?
Licensing issues
What qualifies as open source
Standard open-source licenses
When you need a lawyer



Open-source software in the rest of this book






IV. Community
15. Portability
Evolution of C
Early history of C
C standards



Unix standards
Standards and the Unix wars
The ghost at the victory banquet
Unix standards in the open-source world



IETF and the RFC standards process
Specifications as DNA, code as RNA
Programming for Portability
Portability and choice of language
Avoiding system dependencies
Tools for portability



Portability, open standards and open source



16. Documentation
Documentation concepts
The Unix style
Technical background
Cultural style



The zoo of Unix documentation formats
troff and the DWB tools
TeX



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼
haoji
¾«Áéʹ




UID£º593238
×¢²á£º2007-7-28
×îºóµÇ¼£º 2008-06-28
Ìû×Ó£º3695
¾«»ª£º0

¿ÉÓûý·Ö£º2566
ÐÅÓþ»ý·Ö£º120
ר¼Ò»ý·Ö£º0 (±¾°æ)

״̬£º...ÀëÏß...

[¸öÈ˿ռä] [¶ÌÐÅ] [²©¿Í]


¶¥²¿
10Â¥ ·¢±íÓÚ 2008-5-18 01:17 
Texinfo
POD
HTML
DocBook



The present chaos and a possible way out
DocBook
Document Type Definitions
Other DTDs
The DocBook toolchain
Migration tools
Editing tools
Related standards and practices
SGML
XML-Docbook References



How to write Unix documentation



17. Open Source
Unix and open source
Best practices for working with open-source developers
Good patching practice
Good project- and archive- naming practice
Good development practice
Good distribution-making practice
Good communication practice



The logic of licenses: how to pick one
Why you should use a standard license
Varieties of Open-Source Licensing
X Consortium License
BSD Classic License
Artistic License
General Public License
Mozilla Public License






18. Futures
Essence and accident in Unix tradition
Problems in the design of Unix
A Unix file is just a big bag of bytes



Äú¶Ô±¾ÌùµÄ¿´·¨£ºÏÊ»¨[0] ³ôµ°[0]
CU¿ÉÓûý·Ö¶Ò»»Linux/Unix¾«Æ·Í¼Êé |¡¶Ubuntu±ê×¼½Ì³Ì¡·ÊéÆÀ»ñ½±Ãûµ¥¹«²¼

Ê×Ò³ » ÂÛ̳ » ITͼÊéÓëÆÀÂÛ »


 


Copyright © 2001-2008 ChinaUnix.net All Rights Reserved     ÁªÏµÎÒÃÇ£º

¸ÐлËùÓйØÐĺÍÖ§³Ö¹ýChinaUnixµÄÅóÓÑÃÇ    ×ªÔر¾Õ¾ÄÚÈÝÇë×¢Ã÷Ô­×÷ÕßÃû¼°³ö´¦

¾©ICPÖ¤041476ºÅ


Çå³ý Cookies - ChinaUnix - Archiver - WAP - TOP

Processed in 0.038718 second(s), 4 queries , Gzip enabled