同步阅读进度，多语言翻译，过滤屏幕蓝光，评论分享，更多完整功能，更好读书体验，试试 阅读 ‧ 电子书库
Table of Contents
The Art of Unix ProgrammingEric Steven RaymondDedicationAppendix燗.燝lossary of AbbreviationsAppendix燘.燫eferencesBibliographyAppendix燙.燙ontributorsEvolution of CEarly History of CC StandardsCulture? What Culture?The Durability of UnixThe Case against Learning Unix CultureWhat Unix Gets WrongWhat Unix Gets RightOpen-Source SoftwareCross-Platform Portability and Open StandardsThe Internet and the World Wide WebThe Open-Source CommunityFlexibility All the Way DownUnix Is Fun to HackThe Lessons of Unix Can Be Applied ElsewhereBasics of the Unix PhilosophyRule of Modularity: Write simple parts connected by clean interfaces.Rule of Clarity: Clarity is better than cleverness.Rule of Composition: Design programs to be connected with other programs.Rule of Separation: Separate policy from mechanism; separate interfaces from engines.Rule of Simplicity: Design for simplicity; add complexity only where you must.Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.Rule of Transparency: Design for visibility to make inspection and debugging easier.Rule of Robustness: Robustness is the child of爐ransparency and simplicity.Rule of Representation: Fold knowledge into data, so爌rogram logic can be stupid and robust.Rule of Least Surprise: In interface design, always do the爈east surprising thing.Rule of Silence: When a program has nothing surprising to say, it should say nothing.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 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 LessonApplying the Unix PhilosophyAttitude Matters TooOrigins and History of Unix, 1969-1995Genesis: 1969–1971Exodus: 1971–1980TCP/IP and the Unix Wars: 1980-1990Blows against the Empire: 1991-1995The Open-Source Movement: 1998 and OnwardThe Lessons of Unix HistoryThe Elements of Operating-System StyleWhat Is the Operating System's Unifying Idea?Multitasking CapabilityCooperating ProcessesInternal BoundariesFile Attributes and Record StructuresBinary File FormatsPreferred User Interface StyleIntended AudienceEntry Barriers to DevelopmentOperating-System ComparisonsVMSMacOSOS/2Windows NTBeOSMVSVM/CMSLinuxWhat Goes Around, Comes AroundEncapsulation and Optimal Module SizeCompactness and OrthogonalityCompactnessOrthogonalityThe SPOT RuleCompactness and the Strong Single CenterThe Value of DetachmentSoftware Is a Many-Layered ThingTop-Down versus Bottom-UpGlue LayersCase Study: C Considered as Thin GlueLibrariesCase Study: GIMP PluginsCoding for ModularityThe Importance of Being TextualCase Study: Unix Password File FormatCase Study: .newsrc FormatCase Study: The PNG Graphics File FormatData File MetaformatsDSV StyleRFC 822 FormatCookie-Jar FormatRecord-Jar FormatXMLWindows INI FormatUnix Textual File Format ConventionsThe Pros and Cons of File CompressionApplication Protocol DesignCase Study: SMTP, the Simple Mail Transfer ProtocolCase Study: POP3, the Post Office ProtocolCase Study: IMAP, the Internet Message Access ProtocolApplication Protocol MetaformatsThe Classical Internet Application MetaprotocolHTTP as a Universal Application ProtocolCase Study: The CDDB/freedb.org DatabaseCase Study: Internet Printing ProtocolBEEP: Blocks Extensible Exchange ProtocolXML-RPC, SOAP, and JabberStudying CasesCase Study: audacityCase Study: fetchmail's -v optionCase Study: GCCCase Study: kmailCase Study: SNGCase Study: The Terminfo DatabaseCase Study: Freeciv Data FilesDesigning for Transparency and DiscoverabilityThe Zen of TransparencyCoding for Transparency and DiscoverabilityTransparency and Avoiding OverprotectivenessTransparency and Editable RepresentationsTransparency, Fault Diagnosis, and Fault RecoveryDesigning for MaintainabilitySeparating Complexity Control from Performance TuningTaxonomy of Unix IPC MethodsHanding off Tasks to Specialist ProgramsCase Study: The mutt Mail User AgentPipes, Redirection, and FiltersCase Study: Piping to a PagerCase Study: Making Word ListsCase Study: pic2graphCase Study: bc(1) and dc(1)Anti-Case Study: Why Isn't fetchmail a Pipeline?WrappersCase Study: Backup ScriptsSecurity Wrappers and Bernstein ChainingSlave ProcessesCase Study: scp and sshPeer-to-Peer Inter-Process CommunicationTempfilesSignalsSystem Daemons and Conventional SignalsCase Study: fetchmail's Use of SignalsSocketsCase Study: PostgreSQLCase Study: FreecivShared MemoryProblems and Methods to AvoidObsolescent Unix IPC MethodsSystem V IPCStreamsRemote Procedure CallsThreads — Threat or Menace?Process Partitioning at the Design LevelUnderstanding the Taxonomy of LanguagesApplying MinilanguagesCase Study: sngCase Study: Regular ExpressionsCase Study: GladeCase Study: m4Case Study: XSLTCase Study: The Documenter's Workbench ToolsCase Study: fetchmail Run-Control SyntaxCase Study: awkCase Study: PostScriptCase Study: bc and dcCase Study: Emacs LispCase Study: JavaScriptDesigning MinilanguagesChoosing the Right Complexity LevelExtending and Embedding LanguagesWriting a Custom GrammarMacros — Beware!Language or Application Protocol?Data-Driven ProgrammingCase Study: asciiCase Study: Statistical Spam FilteringCase Study: Metaclass Hacking in fetchmailconfAd-hoc Code GenerationCase Study: Generating Code for the ascii DisplaysCase Study: Generating HTML Code for a Tabular ListWhat Should Be Configurable?Where Configurations LiveRun-Control FilesCase Study: The .netrc FilePortability to Other Operating SystemsEnvironment VariablesSystem Environment VariablesUser Environment VariablesWhen to Use Environment VariablesPortability to Other Operating SystemsCommand-Line OptionsThe -a to -z of Command-Line OptionsPortability to Other Operating SystemsHow to Choose among the MethodsCase Study: fetchmailCase Study: The XFree86 ServerOn Breaking These RulesApplying the Rule of Least SurpriseHistory of Interface Design on UnixEvaluating Interface DesignsTradeoffs between CLI and Visual InterfacesCase Study: Two Ways to Write a Calculator ProgramTransparency, Expressiveness, and ConfigurabilityUnix Interface Design PatternsThe Filter PatternThe Cantrip PatternThe Source PatternThe Sink PatternThe Compiler PatternThe ed patternThe Roguelike PatternThe ‘Separated Engine and Interface’ PatternConfigurator/Actor PairSpooler/Daemon PairDriver/Engine PairClient/Server PairThe CLI Server PatternLanguage-Based Interface PatternsApplying Unix Interface-Design PatternsThe Polyvalent-Program PatternThe Web Browser as a Universal Front EndSilence Is GoldenDon't Just Do Something, Stand There!Measure before OptimizingNonlocality Considered HarmfulThroughput vs. LatencyBatching OperationsOverlapping OperationsCaching Operation ResultsSpeaking of ComplexityThe Three Sources of ComplexityTradeoffs between Interface and Implementation ComplexityEssential, Optional, and Accidental ComplexityMapping ComplexityWhen Simplicity Is Not EnoughA Tale of Five EditorsedviSamEmacsWilyThe Right Size for an EditorIdentifying the Complexity ProblemsCompromise Doesn't WorkIs Emacs an Argument against the Unix Tradition?The Right Size of SoftwareUnix's Cornucopia of LanguagesInterpreted Languages and Mixed StrategiesLanguage EvaluationsCC Case Study: fetchmailC++C++ Case Study: The Qt ToolkitShellCase Study: xmltoCase Study: Sorcery LinuxPerlA Small Perl Case Study: blqA Large Perl Case Study: keeperTclCase Study: TkManMoodss: A Large Tcl Case StudyPythonA Small Python Case Study: imgsizerA Medium-Sized Python Case Study: fetchmailconfA Large Python Case Study: PILJavaCase Study: FreeNetEmacs LispTrends for the FutureChoosing an X ToolkitA Developer-Friendly Operating SystemChoosing an EditorUseful Things to Know about viUseful Things to Know about EmacsThe Antireligious Choice: Using BothSpecial-Purpose Code Generatorsyacc and lexCase Study: The fetchmailrc GrammarCase Study: Glademake: Automating Your RecipesBasic Theory of makemake in Non-C/C++ DevelopmentCase Study: make for Document-File TranslationUtility ProductionsGenerating MakefilesmakedependImakeautoconfautomakeVersion-Control SystemsWhy Version Control?Version Control by HandAutomated Version ControlUnix Tools for Version ControlSource Code Control System (SCCS)Revision Control System (RCS)Concurrent Version System (CVS)Other Version-Control SystemsRuntime DebuggingProfilingCombining Tools with EmacsEmacs and makeEmacs and Runtime DebuggingEmacs and Version ControlEmacs and ProfilingLike an IDE, Only BetterThe Tale of J. Random NewbieTransparency as the Key to ReuseFrom Reuse to Open SourceThe Best Things in Life Are OpenWhere to Look?Issues in Using Open-Source SoftwareLicensing IssuesWhat Qualifies as Open SourceStandard Open-Source LicensesWhen You Need a LawyerUnix StandardsStandards and the Unix WarsThe Ghost at the Victory BanquetUnix Standards in the Open-Source WorldSpecifications as DNA, Code as RNAProgramming for PortabilityPortability and Choice of LanguageC PortabilityC++ PortabilityShell PortabilityPerl PortabilityPython PortabilityTcl PortabilityJava PortabilityEmacs Lisp PortabilityAvoiding System DependenciesTools for PortabilityInternationalizationPortability, Open Standards, and Open SourceDocumentation ConceptsThe Unix StyleThe Large-Document BiasCultural StyleThe Zoo of Unix Documentation Formatstroff and the Documenter's Workbench ToolsTeXTexinfoPODHTMLDocBookThe Present Chaos and a Possible Way OutDocBookDocument Type DefinitionsOther DTDsThe DocBook ToolchainMigration ToolsEditing ToolsRelated Standards and PracticesSGMLXML-DocBook ReferencesBest Practices for Writing Unix DocumentationUnix and Open SourceBest Practices for Working with Open-Source DevelopersGood Patching PracticeDo send patches, don't send whole archives or files.Send patches against the current version of the code.Don't include patches for generated files.Don't send patch bands that just tweak RCS or SCCS $-symbols.Do use -c or -u format, don't use the default (-e) format.Do include documentation with your patch.Do include an explanation with your patch.Do include useful comments in your code.Don't take it personally if your patch is rejectedGood Project- and Archive-Naming PracticeUse GNU-style names with a stem and major.minor.patch numbering.But respect local conventions where appropriate.Try hard to choose a name prefix that is unique and easy to type.Good Development PracticeDon't rely on proprietary code.Use GNU Autotools.Test your code before release.Sanity-check your code before release.Spell-check your documentation and READMEs before release.Recommended C/C++ Portability PracticesGood Distribution-Making PracticeMake sure tarballs always unpack into a single new directory.Include a README.Respect and follow standard file-naming practices.Design for upgradability.Under Linux, provide RPMs.Provide checksums.Good Communication PracticeAnnounce to Freshmeat.Announce to a relevant topic newsgroup.Have a website.Host project mailing lists.Release to major archives.The Logic of Licenses: How to Pick OneWhy You Should Use a Standard LicenseVarieties of Open-Source LicensingMIT or X Consortium LicenseBSD Classic LicenseArtistic LicenseGeneral Public LicenseMozilla Public LicenseEssence and Accident in Unix TraditionProblems in the Design of UnixA Unix File Is Just a Big Bag of BytesUnix Support for GUIs Is WeakFile Deletion Is ForeverUnix Assumes a Static File SystemThe Design of Job Control Was Badly BotchedThe Unix API Doesn't Use Exceptionsioctl(2) and fcntl(2) Are an EmbarrassmentThe Unix Security Model May Be Too PrimitiveUnix Has Too Many Different Kinds of NamesFile Systems Might Be Considered HarmfulTowards a Global Internet Address SpaceProblems in the Environment of UnixProblems in the Culture of UnixReasons to BelieveCommunityChapter�燙omplexityAs Simple As Possible, but燦o燬implerChapter�燙onfigurationStarting on the Right FootContextChapter�ContrastsComparing the Unix Philosophy with OthersInternet FAQ Archives - Online EducationInternet FAQ ArchivesSearch the FAQ ArchivesOther InformationPopular Usenet FAQsInternet RFC/STD/FYI/BCP ArchivesContacting FAQ Maintainers; RFC AuthorsUsing this siteFrequently-Asked QuestionsIt's all about freedom......and it's all about me.DesignChapter�燚ocumentationExplaining Your Code to燼燱eb-Centric WorldMaster Foo and the End UserChapter�燜uturesDangers and OpportunitiesChapter�GenerationPushing the Specification Level UpwardsMaster Foo Discourses on the Graphical User InterfaceOrigins and History of the Hackers, 1961-1995At Play in the Groves of Academe: 1961-1980Internet Fusion and the Free Software Movement: 1981-1991Linux and the Pragmatist Reaction: 1991-1998Chapter�HistoryA Tale of Two CulturesIETF and the RFC Standards ProcessImplementationChapter�營nterfacesUser-Interface Design Patterns in爐he燯nix EnvironmentEditor's IntroductionChapter�燣anguagesTo C or Not To C?Master Foo and the MethodologistChapter�MinilanguagesFinding a Notation That SingsChapter�ModularityKeeping It Clean, Keeping It SimpleChapter�MultiprogrammingSeparating Processes to燬eparate FunctionChapter�燨pen SourceProgramming in the New Unix燙ommunityChapter�燨ptimizationChapter�PhilosophyPhilosophy MattersPlan 9: The Way the Future WasChapter�燩ortabilitySoftware Portability and燢eeping燯p燬tandardsWho Should Read This BookHow to Use This BookRelated ReferencesConventions Used in This BookOur Case StudiesAuthor's AcknowledgementsPrefaceChapter�燫euseOn Not Reinventing the WheelMaster Foo and the Script KiddieMaster Foo and the Ten Thousand LinesChapter�TextualityGood Protocols Make Good燩racticeChapter�燭oolsThe Tactics of DevelopmentChapter�TransparencyLet There Be LightMaster Foo Discourses on the Two PathsUnix and Object-Oriented LanguagesAppendix燚.燫ootless RootThe Unix Koans of Master FooMaster Foo Discourses on the Unix-NatureWhy Not C?Master Foo and the Unix Zealot请支持我们，让我们可以支付服务器费用。
使用微信支付打赏