The Linux Programming Interface

Boyee ZaZa 2013-05-27 0

堪比 APUE 的经典

berry 2015-03-05 0

内容翔实，比起以往的《Unix Programming Environment》，有过之而无不及

xiaxun 2016-10-13 0

内容非常全面，知识点讲解有深度，随书附赠的代码质量也很高

老梅 2012-07-21 0

好书。具体介绍了 Linux 底层的 C API. 缺点：大杂烩，会让菜鸟晕菜。

popshvt 2014-08-17 0

有apue其实够了，这本书的很多内容都重复了，很多资料其实有现成的文档如果你看英文版的话

bigship 2014-11-03 1

作为救火队员参与了此书的翻译，是本大部头，文字比较多。也可以重新回顾一下Linux的一些编程接口了，当做复习也不错。

史提夫孫 2012-08-21 0

The APUE for modern Linux

Godsoul 2011-12-11 0

非常好的linux编程手册，不用man的时候，就用这个查了！

iLRainyday 2014-01-20 2

必须六星！个人认为完全可以和APUE比肩，甚至说是beyond也不过分。有人说此书写的不够平易近人，我要说如果写成这样都读不明白的话，你应该首先考虑的是自己。

bigship 2014-11-03 1

作为救火队员参与了此书的翻译，是本大部头，文字比较多。也可以重新回顾一下Linux的一些编程接口了，当做复习也不错。

死亡的飞翔 2015-05-21 1

挺好的一本参考书，借此终于详详细细的了解了一把Linux提供的系统编程接口，不过细节还需在真用的时候manpage一下。

Boyee ZaZa 2013-05-27 0

堪比 APUE 的经典

berry 2015-03-05 0

内容翔实，比起以往的《Unix Programming Environment》，有过之而无不及

xiaxun 2016-10-13 0

内容非常全面，知识点讲解有深度，随书附赠的代码质量也很高

老梅 2012-07-21 0

好书。具体介绍了 Linux 底层的 C API. 缺点：大杂烩，会让菜鸟晕菜。

popshvt 2014-08-17 0

有apue其实够了，这本书的很多内容都重复了，很多资料其实有现成的文档如果你看英文版的话

史提夫孫 2012-08-21 0

The APUE for modern Linux

我想说两句

本书第6章 1-4节译文

孙嘻嘻 2011-05-27 0赞

译文如有不妥，或有任何反馈可给我发豆邮。

6进程

本章将研究进程结构，并会重点关注进程虚拟内存的布局及内容。同时，还会对进程的某些属性进行考察。后续章节会对进程属性做进一步的探究（例如第九章的进程凭证，第35章的进程优先权及进程调度）。第24章至27章将讨论如何创建进程、终止进程，以及进程如何执行新的程序。
6.1 进程和程序
进程（process）是一个可执行程序（program）的实例。本节将阐述进程定义，并澄清其与程序之间的区别。
        程序是包含了一系列信息的文件，这些信息描述了如何在运行时创建一个进程，其内容包括：
 二进制格式标识：每个程序文件都包含用于描述可执行文件格式的元信息（metainformation）。内核(kernel)利用此信息来解释文件中的其它信息。历史上，UNIX可执行文件曾有两种广泛使用的格式，分别为最初的a.out（汇编程序输出）和更加复杂的COFF(通用对象文件格式)。现在，大多数UNIX实现（包括Linux）采用可执行连接格式（ELF）,这一文件格式比老版本格式具有更多优点。
 机器语言指令：对程序算法进行编码。
 程序入口地址：标识程序开始执行时的起始指令位置。
 数据: 程序文件包含的变量初始值和程序使用的字面常量（literal constants）值（比如字符串）。
 符号表及重定位表：描述程序中函数和变量的位置及名称。这些表格有多种用途，其中包括调试和运行时的符号解析（动态链接）。
 共享库和动态链接信息：程序文件所包含的一些字段，列出了程序运行时需要使用的共享库，以及加载共享库的动态链接器的路径名。
 其他信息:程序文件还包含许多其他信息，用以描述如何创建进程。

可以用一个程序来创建许多进程，或者反过来说，许多进程运行的可以是同一程序。
        在此将本节开始时给出的进程定义重新改写为：进程是由内核定义的抽象的实体，并为该实体分配用以执行程序的各项系统资源。
        从内核角度看，进程由用户内存空间（user-space memory）和一系列内核数据结构组成，其中用户内存空间包含了程序代码及代码所使用的变量，而内核数据结构则用于维护进程状态信息。记录在内核数据结构中的信息包括许多与进程相关的标识号（IDs）、虚拟内存表、打开文件的描述符表、信号传递及处理的有关信息、进程资源使用及限制、当前工作目录和大量的其他信息。
6.2进程号和父进程号
每个进程都有一个进程号（PID）,进程号是一个正数，用以唯一标识系统中的某个进程。对各种系统调用而言，进程号有时可以作为传入参数，有时可以作为返回值。比如，系统调用kill()（第20.5节）允许调用者向拥有特定进程号的进程发送一个信号。当需要创建一个对某进程而言唯一的标识符时，进程号就会派上用场。常见的例子是：将进程号作为与进程相关文件名的一部分。
        系统调用getpid()返回调用进程的进程号。
英文汉译
Always successfully returns process ID of caller 调用总是成功并返回调用者的进程号
getpid()返回值的数据类型为pid_t，该类型是由SUSv3所规定的整数类型，专用于存储进程号。
        除了少数系统进程外，比如init进程(进程号为1)，程序与运行该程序进程的进程号之间没有固定关系。
        Linux内核限制进程号需小于等于32,767。新进程创建时，内核会按顺序将下一个可用的进程号分配给其使用。每当进程号达到32,767的限制时，内核将重置进程号计数器，以便从小整数开始分配。

一旦进程号达到32,767，会将进程号计数器重置为300，而不是1。之所以如此，是因为低数值的进程号为系统进程和守护进程所长期占用，在此范围内搜索尚未使用的进程号只会是浪费时间。
        在Linux2.4版本及更早版本中，进程号的上限，32,767，由内核常量PID_MAX所定义。在Linux 2.6版本中，情况有所改变。尽管进程号的默认上限仍是32,767，但可以通过Linux系统特有的/proc/sys/kernel/pid_max文件来进行调整（其值=最大进程号+1）。在32位平台中，pid_max文件的最大值为32,768，但在64位平台中，该文件的最大值可以高达到222（约400万），系统可能容纳的进程数量会非常庞大。

每个进程都有一个创建自己的父进程。使用系统调用getppid()可以检索到父进程的进程号。
英文汉译
Always successfully returns process ID of parent of caller 调用总是成功并返回调用者的父进程号
实际上，每个进程的父进程号属性反映了系统上所有进程间的树状关系。每个进程的父进程又有自己的父进程，以此类推，回溯到1号进程，init进程，即所有进程的始祖。（使用pstree(1)命令可以查看到这一“家族树”（family tree）。）
        如果子进程的父进程终止，则子进程就会变成”孤儿”，init进程随即将收养该进程，子进程后续对getppid()的调用将返回进程号1（参照第26.2节）。
        通过查看由Linux系统所特有的/proc/PID/status文件所提供的PPid字段，可以获知每个进程的父进程。
6.3进程内存布局
每个进程所分配的内存由很多部分组成，通常称之为“段”（segment）。这包括：
 文本段包含了进程运行的程序机器语言指令。文本段具有只读属性，以防止进程通过错误指针意外修改自身指令。因为多个进程可同时运行同一程序，所以又将文本段设为可共享，这样，一份程序代码的拷贝可以映射到所有这些进程的虚拟地址空间中。
 初始化数据段包含显式初始化的全局变量和静态变量。当程序加载到内存时，从可执行文件中读取这些变量的值。
 未初始化数据段包含了未进行显式初始化的全局变量和静态变量。程序启动之前，系统将本段内所有内存初始化为0。出于历史原因，此段常被称为BSS段，这源于老版本的汇编语言助记符” block started by symbol”。将经过初始化的全局变量和静态变量与未经初始化的全局变量和静态变量分开存放，其主要原因在于：程序在磁盘上存储时，没有必要为未经初始化的变量分配存储空间。相反，可执行文件只需记录未初始化数据段的位置及所需大小，直到运行时再由程序加载器来分配这一空间。
 栈（stack）是一个动态增长和收缩的段，由栈帧（stack frames）组成。系统会为每个当前调用的函数分配一个栈帧。栈帧中存储了函数的局部变量（所谓自动变量）、实参和返回值。第6.5节将深入讨论栈帧。
 堆（heap）是可在运行时（为变量）动态进行内存分配的一块区域。将堆顶端称作program break。
对于初始化和未初始化的数据段而言，不太常用、但表述更清晰的称谓分别是用户初始化数据段（user-initialized data segment）和零初始化数据段（zero-initialized data segment）。
        size(1)命令可显示二进制可执行文件的文本段、初始化数据段、非初始化数据段（bss）的段大小。

正文中使用的术语段（segment）不应与一些硬件体系架构——比如x86-32中使用的硬件分段（segmentation）相混淆。相反，本文中的段是对UNIX系统中进程虚拟内存的的逻辑划分。有时，会使用术语区（section）来替代段，因为在当下风行的可执行文件格式（ELF）规范中，采用的术语与“区”更趋一致。
        本书会在多处涉及这种情况：库函数返回的指针指向静态分配的内存。这意味着，该内存既可在初始化数据段中分配，也可在非初始化数据段中分配。（某些情况下，库函数转而会在堆上对内存做一次性动态分配，然而，这一实现细节与这里所要表达的意思无关。）库函数有时会通过静态分配的内存来返回信息，了解这一情况至关重要，因为这片内存的存在独立于函数调用，后续对同一函数的调用可能会将其覆盖（有时，后续对相关函数的调用也有相同的效应）。使用静态分配的内存会使函数不可重入（nonreentrant）。第21.1.2节和31.1节将深入讨论重入（reentrancy）问题。

程序清单6-1展示了不同类型的C语言变量，并以注释说明每种变量分属于哪个段。这些说明正确的前提是：假定使用了非优化的编译器，且在应用程序二进制接口（ABI）中，是通过栈来传递所有参数的。实际上，优化编译器会将频繁使用的变量分配于寄存器中，或者索性将变量彻底剔除（译注：例如：以寄存器取代变量）。此外，一些ABI需要通过寄存器，而不是栈，来传递函数实参和结果。尽管如此，本例只是意在展示C语言变量和进程各段间的映射关系。
程序清单 6-1:程序变量在进程内存各段中的位置

英文汉译
Uninitialized data segment 非初始化数据段
Initialized data segment 初始化数据段
Allocated in frame for square() 在square()函数的帧中分配空间
Return value passed via register 通过寄存器传递返回值
Allocated in frame for doCalc() 在doCalc()函数的帧中分配空间
Allocated in frame for main() 在main()函数的帧中分配空间
Points to memory in heap segment 指向堆段中内存
应用程序二进制接口（ABI）是一套规则，规定了二进制可执行文件在运行时应如何与某些服务（诸如内核或函数库所提供的服务）交换信息。ABI特别规定了：使用哪些寄存器和栈地址来交换信息、以及所交换值的含义，一旦针对某个特定ABI进行了编译，其二进制可执行文件应能在ABI相同的任何系统上运行。与之相反，标准化的API（如SUSv3）仅能通过编译源代码来保证应用程序的可移植性。
虽然SUSv3未作规定，但在大多数UNIX实现（包括Linux）中C语言编程环境提供了三个全局符号（symbol）：etext、edata和end。可在程序内使用这些符号以获取相应程序文本段、初始化数据段和非初始化数据段结尾处下一字节的地址。使用这些符号，必须显式声明如下：
英文汉译
For example, &etext gives the address of the end of the program text / start of initialized data 例如，&etext是指程序文本段结尾处下一个字节的地址/初始化数据开始的地址。（译注：此处已与作者沟通，原文有误）
图6-1展示了各种内存段在x86-32体系结构中的布局，该图的顶部标记为argv、 environ的空间用来存储程序命令行实参（通过C语言中main()函数的argv参数获得）和进程环境列表（稍后讨论），图中十六进制的地址会因内核配置和程序链接选项差异而有所不同。图中标灰的区域表示这些范围在进程虚拟地址空间中不可用，也就是说，没有为这些区域创建页表（page table）（参考以下关于虚拟内存管理的讨论）。
        第48.5节将更为详细地重新讨论进程内存布局的课题，还将论及共享内存和共享库在进程虚拟内存中的放置位置。
6.4虚拟内存管理
上述关于进程内存布局的讨论忽略了一个事实：这一布局存在于虚拟内存中。因为对虚拟内存的理解将有助于后续对诸如fork()系统调用、共享内存和映射文件之类主题的阐述，所以这里将探讨一些有关虚拟内存的详细内容。
        Linux，像多数现代内核一样，采用了虚拟内存管理技术。该技术利用了大多数程序的一个典型特征——即访问局部性（locality of reference.），以求高效使用CPU和RAM（物理内存）资源。大多数程序都展现了两种类型的局部性：
 空间局部性（Spatial locality）是指程序倾向于访问在最近访问过的内存地址附近的内存（由于指令是顺序执行的，且有时会按顺序处理数据结构）。
 时间局部性（Temporal locality）是指程序倾向于在不久的将来再次访问最近刚访问过的内存地址（由于循环）。
英文汉译
Virtual memory address（hexdecimal）虚拟内存地址（十六进制）
/proc/kallsyms provides addresses of
kernel symbols in this region ( /proc/ksyms in
kernel 2.4 and earlier) /proc/kallsyms文件提供了该区域中内核符号的地址（在内核2.4及更早版本中使用的是/proc/ksyms）
Top of stack 栈顶
Program break Program break
increasing virtual addesses 虚拟地址递增
Kernel(mapped into process virtual memory, but not accessible to program) 内核（映射到进程的虚拟内存中，但程序无法访问）
Stack (grows downwards) 栈（向下增长）
(unallocated memory) （未分配的内存）
Heap (grows upwards) 堆（向上增长）
Uninitialized data (bss) 未初始化数据（bss）
Initialized data 初始化数据
Text (program code) 文本（程序代码）
图6-1: 在Linux/x86-32中典型的进程内存结构
正是由于访问局部性特征，使得程序即便仅有部分地址空间存在于RAM中，依然可能得以执行。
        虚拟内存的规划之一是将每个程序使用的内存切割成小型的、固定大小的“页”（page）单元。相应地，将RAM划分成一系列与虚存页尺寸相同的页帧。任一时刻，每个程序仅有部分页需要驻留在物理内存页帧中；这些页构成了所谓驻留集（resident set）。程序未使用的页拷贝保存在交换区（swap area）内——这是磁盘空间中的保留区域，作为计算机RAM的补充——仅在需要时才会载入物理内存。若进程欲访问的页面目前并未驻留在物理内存中，将会发生页面错误（page fault），内核即刻挂起进程的执行，同时从磁盘中将该页面载入内存。

在x86-32中，页面大小为4096个字节。其他一些 Linux实现使用的页面比4096个字节更大。例如，Alpha使用的页面大小为8192个字节，IA-64使用的页面大小是可变的，默认为16,384个字节。程序可调用sysconf(_SC_PAGESIZE)来获取系统虚拟内存的页面大小，具体参见第11.2节的描述。

英文汉译
increasing virtual addesses 虚拟地址递增
Process virtual address space 进程虚拟地址空间
Page table 页表
Physical memory (RAM) (page frames) 物理内存(RAM)(页帧)

图6-2: 虚拟内存概览
为支持这一组织方式，内核需要为每个进程维护一张页表（page table）（见图6-2）。该页表描述了每页在进程虚拟地址空间（virtual address space）中的位置（可为进程所用的所有虚拟内存页面的集合）。页表中的每个条目要么指出一个虚拟页面在RAM中的所在位置，要么表明其当前驻留在磁盘上。
        在进程虚拟地址空间中，并非所有的地址范围都需要页表条目。通常情况下，由于可能存在大段的虚拟地址空间并未投入使用，故而也无必要为其维护相应的页表条目。若进程试图访问的地址并无页表条目与之对应，那么进程将收到一个SIGSEGV信号。
        由于内核能够为进程分配和释放页（和页表条目），所以进程的有效虚拟地址范围在其生命周期中可以发生变化。这可能会发生于如下场景：
 由于栈向下增长超出之前曾达到的位置；
 当在堆中分配或释放内存时，通过调用brk()、sbrk()或malloc函数族（第7章）来提升program break的位置。
 当调用shmat()连接System V共享内存区时，或者当调用shmdt()脱离共享内存区时（第48章）；
 当调用mmap()创建内存映射时，或者当调用munmap()解除内存映射时（第49章）。

虚拟内存的实现需要硬件中分页内存管理单元(PMMU)的支持。PMMU把要访问的每个虚拟内存地址转换成相应的物理内存地址，当特定虚拟内存地址所对应的页没有驻留于RAM中时，将以页面错误通知内核。

虚拟内存管理使进程的虚拟地址空间与RAM物理地址空间隔离开来，这带来许多优点：
 进程与进程、进程与内核相互隔离，所以一进程不能读取或修改另一进程或内核的内存。这是因为每个进程的页表条目指向RAM（或交换区）中截然不同的物理页面集合。
 适当情况下，两个或者更多进程能够共享内存。这是由于内核可以使不同进程的页表条目指向相同的RAM页。内存共享常发生于如下两种场景：
– 执行同一程序的多个进程，可共享一份（只读的）程序代码副本。当多个程序执行相同的程序文件（或加载相同的共享库）时，会隐式地实现这一类型的共享。
– 进程可以使用shmget()和mmap()系统调用显式地请求与其他进程共享内存区。这么做是出于进程间通信的目的。
 便于实现内存保护机制；也就是说，可以对页表条目进行标记，以表示相关页面内容是可读、可写、可执行亦或是这些保护措施的组合。多个进程共享RAM页面时，允许每个进程对内存采取不同的保护措施；例如，一进程可能以只读方式访问某页面，而另一进程则以读写方式访问同一页面。
 程序员和编译器、连接器之类的工具无需关注程序在RAM中的物理布局。
 因为需要驻留在内存中的仅是程序的一部分，所以程序的加载和运行都很快。而且，一个进程所占用的内存（即虚拟内存大小）能够超出RAM容量。
虚拟内存管理的最后一个优点是：由于每个进程使用的RAM减少了，RAM中同时可以容纳的进程数量就增多了。这增大了如下事件的概率：在任一时刻，CPU都可执行至少一个进程——因而往往也会提高CPU的利用率。

本书前言的译文

孙嘻嘻 2011-02-13 2赞

前言
主题
本书将描述Linux编程接口：由UNIX操作系统的开源实现——LINUX所提供的系统调用、库函数以及其它底层接口。运行于LINUX之上的每一程序都会直接或间接地使用这些接口。这些接口允许应用程序去执行诸多任务：文件I/O、创建/删除文件和目录、创建新进程、执行程序、设置计时器、在同一计算机上发起进程或线程间通信，以及为联网计算机间的进程建立通信等等。有时，人们也将这一系列的底层接口称为系统编程接口。
尽管本书着眼于LINUX，但对于标准和可移植性问题也倍加关注。对于LINUX所特有的技术细节，以及已由POSIX和SUS标准化的UNIX普遍特性，本书会在论述中清晰地加以区分。因此，本书亦提供了对UNIX/POSIX编程接口的全面描述。对于那些在其它UNIX系统环境中编程，或者编写跨平台可移植应用程序的程序员来说，本书同样具有实用价值。
本书的读者
本书主要针对以下读者：

本书第2章1-6节译文

孙嘻嘻 2011-05-27 1赞

译文如有不妥，或有任何反馈意见可发豆邮给我。

第2章基本概念
本章旨在向LINUX和UNIX“生手”们介绍一系列与LINUX系统编程有关的概念。
2.1 操作系统的核心——内核
术语“操作系统”通常包含两种不同涵义：
1、指完整的软件包，这包括用来管理计算机资源的核心层软件，以及附带的所有标准软件工具，诸如，命令行解释器、图形用户界面、文件操作工具和文本编辑器等。
2、在更狭义的范围内，是指管理和分配计算机资源（即CPU、RAM和设备）的核心层软件。
术语“内核”通常是第二种涵义，本书中的“操作系统”一词也是这层意思。
虽然在没有内核的情况下，计算机也能运行程序，但有了内核会极大简化其它程序的编写和使用，令程序员“功力”大进、游刃有余。这要归功于内核为管理计算机的有限资源所提供的软件层。
一般情况下，LINUX内核可执行文件采用/boot/vmlinuz或与之类似的路径名。而文件名的来历也颇有渊源。早期的UNIX实现称其内核为UNIX。在后续实现了虚拟内存机制的UNIX系统中，其内核名称变更为vmunix。对LINUX来说，文件名称中的系统名需要调整，而以“z”替换“linux”末尾的“x”，意在表明内核是经过压缩的可执行文件。
内核的职责
内核所能执行的主要任务有：
•进程调度：计算机均配有一个或多个CPU（中央处理单元），以执行程序指令。与其它UNIX系统一样，LINUX属于抢占式多任务操作系统。“多任务”意指多个进程（即运行中的程序）可同时驻留于内存，且每个进程都能获得对CPU的使用权。“抢占”则是指一组规则：这组规则控制着哪些进程获得对CPU的使用，以及每个进程能使用多长时间，这两者都由内核进程调度程序（而非进程本身）决定。
•内存管理：以一、二十年前的标准来看，如今计算机的内存容量可谓相当可观，但软件的规模也保持了相应地增长，故而物理内存（RAM）仍然属于有限资源，内核必须以公平、高效地方式在进程间共享这一资源。与大多数现代操作系统一样，LINUX也采用了虚拟内存管理机制（6.4节），这项技术主要具有以下两方面的优势：
——进程与进程之间、进程与内核之间彼此隔离，因此一个进程无法读取/修改内核或其他进程的内存内容。
——只需将进程的一部分保存在内存中，这不但降低了每个进程对内存的需求量，而且还能在RAM中同时加载更多的进程。这也大幅提升了如下事件的发生概率：在任一时刻，CPU都有至少一个进程可以执行——从而使得对CPU资源的利用更加充分。
•提供了文件系统：内核在磁盘之上提供有文件系统，允许对文件执行创建、获取、更新以及删除等操作。
•创建和终止进程：内核可将新程序载入内存，为其提供运行所需的资源（比如，CPU、内存以及对文件的访问等）。这样一个运行中的程序我们称之为“进程”。一旦进程执行完毕，内核还要确保释放其占用的资源，以供后续程序重新使用。
•对设备的访问：计算机外接设备（鼠标、键盘，磁盘和磁带驱动器等）可实现计算机与外部世界的通信，这一通信机制包括：输入、输出或是两者兼而有之。内核既为程序访问设备提供了简化版的标准接口，同时还要仲裁多个进程对每一设备的访问。
•联网：内核以用户进程的名义收发网络消息（数据包）。该任务包括将网络数据包路由至目标系统。
•提供系统调用应用编程接口（API）：进程可利用内核入口点（也称为系统调用）请求内核去执行各种任务。LINUX系统调用API是本书的主题。3.1节会详细描述进程在执行系统调用时所经历的步骤。
除了上述特性外，一般而言，诸如LINUX之类的多用户操作系统会为每个用户营造一种抽象：虚拟私有计算机（virtual private computer），这就是说，每个用户都可登录进系统、独立操作，而与其他用户大致无干。例如，每个用户都有属于自己的磁盘存储空间（主目录）。再者，用户能够运行程序，而每一程序都能从CPU资源中“分得一杯羹”、运转于自有的虚拟地址空间中。而且这些程序还能独立访问设备，并通过网络传递信息。内核负责解决（多进程）访问硬件资源时可能引发的冲突，用户和进程对此则往往一无所知。
内核态和用户态
现代处理器架构一般允许CPU至少在两种不同状态下运行，即：用户态和核心态（有时也称之为监管态[supervisor mode]）。执行硬件指令可使CPU在两种状态间来回切换。与之对应，可将虚拟内存区域划分（标记）为用户空间部分或内核空间部分。在用户态下运行时，CPU只能访问被标记为用户空间的内存；试图访问属于内核空间的内存会引发硬件异常。当运行于核心态时，CPU既能访问用户空间内存，也能访问内核空间内存。
仅当处理器在核心态运行时，才能执行某些特定操作。这样的例子包括：执行宕机（halt）指令去关闭系统、访问内存管理硬件，以及设备I/O操作的初始化等。实现者们利用这一硬件设计，将操作系统置于内核空间——这确保了用户进程既不能访问内核指令和数据结构，也无法执行不利于系统运行的操作。
以进程及内核视角检视系统
在完成诸多日常编程任务时，程序员们习惯于以面向进程（process-oriented）的思维方式来考虑编程问题。然而，在研究本书后续所涵盖的各种主题时，读者有必要转换视角——站在内核的角度上来看问题。为凸显二者间的差异，本书接下来会分别从进程和内核视角来检视系统。
一个运行系统通常会有多个进程并行其中。对进程来说，许多事件的发生都无法预期。执行中的进程不清楚自己对CPU的占用何时“到期”、系统随之又会调度哪个进程来使用CPU（以及以何种顺序来调度），也不知道自己何时会再次获得对CPU的使用。信号的传递和进程间通信事件的触发由内核统一协调，对进程而言，随时可能发生。诸如此类，进程都一无所知。进程不清楚自己在RAM中的位置，或者换种更通用的说法：进程内存空间的某块特定部分如今到底是驻留在内存中还是被保存在交换空间（磁盘空间中的保留区域，作为计算机RAM的补充）里，进程本身并不知晓。与之类似，进程也闹不清自己所访问的文件“居于”磁盘驱动器的何处；进程只是通过名称来引用文件而已。进程的运作方式堪称“与世隔绝”——进程间彼此不能直接通信。进程本身无法创建出新进程，哪怕“自行了断”都不行。最后还有一点，进程也不能与计算机外接的输入输出设备直接通信。
相形之下，内核则是运行系统的中枢所在，对于系统的一切无所不知、无所不能，为系统上所有进程的运行提供便利。由哪个进程来接掌对CPU的使用、何时“接任”、“任期”多久，都由内核说了算。在内核维护的数据结构中，包含了与所有正在运行的进程有关的信息；随着进程的创建、状态发生变化或者终结，内核会及时更新这些数据结构。内核所维护的底层数据结构可将程序使用的文件名转换为磁盘的物理位置。此外，每个进程的虚拟内存与计算机物理内存及磁盘交换区之间的映射关系，也在内核维护的数据结构之列。进程间的所有通信都要通过内核提供的通信机制来完成。响应进程发出的请求，内核会创建新的进程、终结现有进程。最后，由内核（特别是设备驱动程序）来执行与输入/输出设备之间的所有直接通信，按需与用户进程交互信息。
本书后续内容中会出现如下措辞，例如：“某进程可创建另一个进程”、“某进程可创建管道”、“某进程可将数据写入文件”，以及“调用exit()以终止某进程”。请务必牢记，以上所有动作都是由内核来居中“调停”，上面的说法不过是“某进程可以请求内核创建另一个进程”的缩略语，以此类推。
进阶阅读
涵盖操作系统概念和设计、尤其是对UNIX操作系统加以重点关注的现代教科书包括：[Tanenbaum, 2007]、[Tanenbaum & Woodhull,2006]以及[Vahalia, 1996]，最后一本包含了与虚拟内存架构有关的详细内容。[Goodheart & Cox, 1994]详细介绍了System V Release 4。[Maxwell, 1999]则是有选择性的针对Linux 2.2.5的部分内核源码进行了注释。[Lions, 1996]对第六版UNIX源码进行了详尽阐释，并一直是研究UNIX操作系统内幕的入门级经典。[Bovet & Cesati, 2005]描述了LINUX2.6内核的实现。
2.2 Shell
Shell是一种具有特殊用途的程序，主要用于读取用户输入的命令，并执行相应的程序以响应命令。有时，人们也称之为命令解释器。
术语登录shell（login shell）是指：用户刚登录系统时，由系统创建、用以运行shell的进程。尽管某些操作系统将命令解释器集成于内核中，而对UNIX系统而言，shell只是一个用户进程。shell的种类繁多，登入同一台计算机的不同用户可同时使用不同的shell（就单个用户来说，情况也一样）。纵观UNIX历史，出现过以下几种重要的shell：
•Bourne shell (sh)：这款由Steve Bourne编写的shell历史最为悠久，且应用广泛，曾是第七版UNIX的标配shell。Bourne shell包含了在其他shell中常见的许多特性：I/O重定向、管道、文件名生成（通配符）、变量、环境变量处理、命令替换、后台命令执行以及函数。对于所有问世于第七版UNIX之后的实现而言，除了可能提供有其他shell之外，都附带了Bourne shell。
•C shell (csh):由Bill Joy于加州大学伯克利分校编写而成。其命名则源于该脚本语言的流控制语法与C语言有着许多相似之处。C shell当时提供了若干极为实用的交互式特性，这些特性并不为Bourne shell所支持，其中包括：命令的历史记录、命令行编辑功能、任务控制和别名等。C shell与Bourne shell并不兼容。尽管C shell曾是BSD系统标配的交互式shell，但一般情况下，人们还是喜欢针对Bourne shell编写shell脚本（稍后介绍），以便其能够在所有UNIX实现上移植。
•Korn shell (ksh): AT&T贝尔实验室的David Korn编写了这款shell，作为Bourne shell的“继任者”。在保持与Bourne shell兼容的同时，Korn shell还吸收了那些与C shell相类似的交互式特性。
•Bourne again shell (bash):这款shell是GNU项目对Bourne shell的重新实现。Bash提供了与C shell和Korn shel所类似的交互式特性。Brian Fox 和Chet Ramey是bash的主要作者。bash或许是LINUX上应用最为广泛的shell了。（在LINUX上，Bourne shell,（sh）其实正是由bash仿真提供的。）
POSIX.2-1992基于当时的Korn shell版本定义了一个shell标准。如今，Korn shell和bash都符合POSIX规范，但两者都提供了大量对标准的扩展，其扩展之间存在许多差异。
设计shell的目的不仅仅是用于人机交互，对shell脚本（包含shell命令的文本文件）进行解释也是其用途之一。为实现这一目的，每款shell都内置有许多通常与编程语言相关的功能，其中包括：变量、循环和条件语句、I/O命令以及函数等。
尽管在语法方面有所差异，每款shell执行的任务都大致相同。除非指明是某款特定shell的操作，否则书中的“shell” 都会按所描述的方式运作。本书绝大多数需要用到shell的示例都会使用bash，若无其他说明，读者可假定这些示例也能以相同方式在其他类Bourne的shell上运行。
2.3 用户和组
    系统会对每个用户的身份做唯一标识，用户可隶属于多个组。
用户
系统的每个用户都拥有唯一的登录名（用户名）和与之相对应的整数型用户ID (UID)。系统密码文件/etc/passwd为每个用户都定义有一行记录，除了上述两项信息外，该记录还包含如下信息：
•组ID: 用户所属第一个组的整数型组ID。
•主目录：用户登录后所居于的初始目录。
•登录shell：执行以解释用户命令的程序名称。
该记录还能以加密形式保存用户密码。然而，出于安全考虑，用户密码往往存储于单独的shadow密码文件中，仅供特权用户阅读。
组
出于管理目的，尤其是为了控制对文件和其它资源的访问，将多个用户分组是非常实用的做法。例如，某项目的开发团队人员需要共享同一组文件，就可以将他们编为同一组的成员。在早期的UNIX实现中，一个用户只能隶属于一个组。BSD率先允许一个用户同时属于多个组，这一理念后来被其它UNIX实现纷纷效仿，并最终成为POSIX.1-1990标准。每个用户组都对应着系统组文件/etc/group中的一行记录，该记录包含如下信息：
•组名:组名称（具有唯一性）。
•组ID (GID)：与组相关的整数型ID。
•用户列表：隶属于该组的用户登录名列表（通过密码文件记录的group ID字段未能标识出的该组其他成员，也在此列），以逗号分隔。
超级用户
超级用户在系统中享有特权。超级用户帐号的用户ID为0，通常登录名为root。在一般的UNIX系统上，超级用户凌驾于系统的权限检查之上。因此，无论对文件施以何种访问权限限制，超级用户都可以访问系统中的任何文件，也能发送信号干预系统运行的所有用户进程。系统管理员可以使用超级用户账号来执行各种系统管理任务。
2.4 单根目录层级、目录、链接及文件
    内核维护着一套单根目录结构，以放置系统的所有文件。（这与微软windows之类的操作系统形成了鲜明对照，windows系统的每个磁盘设备都有各自的目录层级。）这一目录层级的根基就是名为“/”的根目录。所有的文件和目录都是根目录的“子孙”。图1-2所示为这种文件层级结构的示例。
图2-1 Linux单根目录层级的一部分
文件类型
在文件系统内，会对文件类型进行标记，以表明其种类。其中一种用来表示普通数据文件，人们常称之为“普通文件”或“纯文本文件”，以示与其他种类的文件有所区别。其他文件类型包括：设备、管道、套接字、目录以及符号链接。
术语“文件”常用来指代任意类型的文件，不仅仅指普通文件。
路径和链接
目录是一种特殊类型的文件，内容采用表格形式，数据项包括文件名以及对相应文件的引用。这一“文件名+引用”的组合被称为链接。每个文件都可以有多条链接，因而也可以有多个名称，在相同或不同的目录中出现。
目录可包含指向文件或其他目录的链接。路径间的链接建立起如图2-1所示的目录层级。
每个目录至少包含两条记录：.和..，前者是指向目录自身的链接，后者是指向其上级目录——父目录的链接。除根目录外，每个目录都有父目录。对于根目录而言，..是指向根目录自身的链接（因此，/..等于/）。
符号链接
类似于普通链接，符号链接给文件起了一个“别号”（alternative name）。在目录列表中，普通链接是内容为“文件名+指针”的一条记录，而符号链接则是经过特殊标记的文件，内容包含了另一文件的名称。（换言之，一个符号链接对应着目录中内容为“文件名+指针”的一条记录，指针指向的文件内容（译注：及该文件所属数据块存储的内容）为另一个文件名的字符串。）所谓“另一文件”通常被称为符号链接的目标，人们一般会说：符号链接“指向”或“引用”目标文件。在多数情况下，只要系统调用用到了路径名，内核会自动解除（换言之，按照）该路径名中符号链接的引用，以符号链接所指向的文件名来替换符号链接。若符号链接的目标文件自身也是一个符号链接，那么上述过程会以递归方式重复下去。（为了应对可能出现的循环引用，内核对解除引用的次数作了限制。）如果符号链接指向的文件并不存在，那么可将该链接视为空链接（dangling link）。
通常，人们会分别使用硬链接（hard link）或软链接（soft link）这样的术语来指代正常链接和符号链接。之所以存在这两种不同类型的链接，将在第十八章做出解释。
文件名
    在大多数Linux文件系统上，文件名最长可达255个字符。文件名可以包含除“/”和空字符()外的所有字符。但是，只建议使用字母、数字、点(“.”)、下划线（“_”）以及连字符（“-”）。SUSv3将这一65个字符的集合——[-._a-zA-Z0-9]称为可移植文件名字符集（portable filename character set）。
对于可移植文件名字符集以外的字符，由于其可能会在shell、正则表达式或其他场景中具有特殊含义，故而应避免在文件名中使用。如在上述环境中出现了包含特殊含义字符的文件名，则需要进行转义，即对此类字符进行特殊标记（一般会在特殊字符前插入一个“”），以指明不应以特殊含义对其进行解释。若场境不支持转义机制，则不能使用此类文件名。
此外，还应避免以连字符（“-”）作为文件名的起始字符，因为一旦在shell命令中使用这种文件名，会被误认为命令行选项开关。
路径名
路径名是由一系列文件名组成的字符串，彼此以“/”分隔，首字符可以为“/”（非强制）。（译注：此处“文件”的含义中包括了目录——如前文所述：“目录是一种特殊类型的文件”）除却最后一个文件名外，该系列文件名均为目录名称（或为指向目录的符号链接）。路径名的尾部（译注：即最后一个文件名）可标识任意类型的文件，包括目录在内。有时将该字符串中最后一个“/”字符之前的部分称为路径名的目录部分，将其之后的部分称为路径名的文件部分或基础部分。
路径名应按从左至右的顺序阅读，路径名中每个文件名之前的部分，即为该文件所处目录。可在路径名中任意位置后引入字符串".."（译注：需以“/”分隔），用以指代路径名中当前位置的父目录。
路径名描述了单根目录层级下的文件位置，又可分为绝对路径名和相对路径名：
•绝对路径名以“/”开始，指明文件相对于根目录的位置。图2-1中的/home/mtk/.bashrc、/usr/include以及/（根路径的路径名）都是绝对路径名的例子。
•相对路径名定义了相对于进程当前工作目录（见下文）的文件位置，与绝对路径名相比，相对路径名缺少了起始的“/”。如图2-1所示，在目录usr下，可使用相对路径名include/sys/types.h来引用文件types.h；在目录avr下，可使用相对路径名../mtk/.bashrc来访问文件.bashrc。
当前工作目录
每个进程都有一个当前工作目录（有时简称为进程工作目录或当前目录）。这就是单根目录层级下进程的“当前位置”，也是进程解释相对路径名的参照点。
进程的当前工作目录继承自其父进程。对登录shell来说，其初始当前工作目录，是依据密码文件中该用户记录的主目录字段来设置。可使用cd命令来改变shell的当前工作目录。
文件的所有权和权限
每个文件都有一个与之相关的用户ID和组ID，分别定义文件的属主和属组。系统根据文件的所有权来判定用户对文件的访问权限。
为了访问文件，系统把用户分为三类：文件的属主（有时，也称为文件的用户）、（与文件组（group）ID相匹配的）属组成员用户、以及其他用户。可为以上三类用户分别设置三种权限（共计9种权限位）：只允许查看文件内容的读权限；允许修改文件内容的写权限；允许执行文件的执行权限——这里的文件要么指程序，要么是交由某种解释程序（通常指shell的一种，但也有例外）处理的脚本。
也可针对目录进行上述权限设置，但意义稍有不同：读权限允许列出目录内容（即该目录下的文件名）；写权限允许对目录内容进行更改（比如，添加、修改或删除文件名）；执行（有时也称为搜索）权限允许对目录中的文件进行访问（但需受文件自身访问权限的约束）。
2.5 文件I/O模型
UNIX系统I/O模型最为显著的特性之一是其I/O通用性概念。也就是说，同一套系统调用（open()、read()、write()、close()等）所执行的I/O操作，可施之于所有文件类型，包括设备文件在内。（应用程序发起的I/O请求，内核会将其转化为相应的文件系统操作、或者设备驱动程序操作，以此来执行针对目标文件或设备的I/O操作。）因此，采用这些系统调用的程序能够处理任何类型的文件。
就本质而言，内核只提供一种文件类型：字节流序列，在处理磁盘文件、磁盘或磁带设备时，可通过lseek（）系统调用来随机访问。
许多应用程序和函数库都将新行符（十进制ASCII码为10，有时亦称其为换行）视为文本中一行的结束和另一行的开始。UNIX系统没有文件结束符的概念；读取文件时如无数据返回，便会认定抵达文件末尾。
文件描述符
I/O系统调用使用文件描述符——（往往是数值很小的）非负整数——来指代打开的文件。获取文件描述符的常用手法是：调用open()，在参数中指定I/O操作目标文件的路径名。
通常，由shell启动的进程会继承三个已打开的文件描述符：描述符0为标准输入，指代为进程提供输入的文件；描述符1为标准输出，指代供进程写入输出的文件；描述符2为标准错误，指代供进程写入错误消息或异常通告的文件。在交互式shell或程序中，上述三者一般都指向终端。在stdio函数库中，这几种描述符分别与文件流stdin、stdout和stderr相对应。
stdio函数库
    C编程语言在执行文件I/O操作时，往往会调用C语言标准库的I/O函数。也将这样一组I/O函数称为stdio函数库，其中包括：fopen(), fclose(), scanf(), printf(), fgets(), fputs()等。stdio函数位于I/O系统调用层(open(), close(), read(), write()等)之上。

本书假定读者已经了解了C语言的标准I/O (stdio)函数，因此也不会介绍这方面的内容。更多与stdio函数库有关的信息请参考[Kernighan & Ritchie, 1988], [Harbison & Steele，2002], [Plauger, 1992], 和[Stevens & Rago, 2005]。
2.6 程序
程序通常以两种面目示人。其一为源码形式，由使用编程语言（比如，C语言）写成的一系列语句组成，是人类可以阅读的文本文件。要想执行程序，则需将源码转换为第二种形式——计算机可以理解的二进制机器语言指令。（这与脚本形成了鲜明对照，脚本是包含命令的文本文件，可以由shell或其它命令解释器之类的程序直接处理。）一般认为，术语“程序”的上述两种含义几近相同，因为经过编译和链接处理，会将源码转换为语义相同的二进制机器码。
过滤器
从stdin读取输入、加以转换，再将转换后的数据输出到stdout——常常将拥有上述行为的程序称为过滤器，cat，grep，tr，sort，wc，sed，awk均在其列。
命令行参数
C语言程序可以访问命令行参数——即程序运行时在命令行中输入的内容。要访问命令行参数，程序的main()函数需做如下声明：
int main(int argc, char *argv[])
argc变量包含命令行参数的总个数，argv指针数组的成员指针则逐一指向每个命令行参数字符串。首个字符串，argv[0]，标识程序名本身。

据说已出电子版

simple 2011-01-28 0赞

自己去搜吧，就不提供链接了。这书看着一时半会国内出版社没引进的意思

ps：豆瓣提醒我评论太短了，于是乎我又得加上这么几句废话。

“为了鼓励有益的分享, 少于50字的评论将在前页论坛里发表。”

对此书“赞誉”的翻译

孙嘻嘻 2011-02-07 4赞

我是此书中文译本的译者之一。此书并非像amazon.com上说的那般神。首先，作者的表达能力就非常够呛。其次，本书的大批技术审校者母语都非英语。
一本描写技术细节的书，如果作者的写作能力不过关，其结果会如何呢？

以下是我们翻译的一干技术审校者对本书的“赞誉”，我可以这么说，在译文的文字表达方面，我们已经替这一干"title"众多的审校者遮了很多丑了。语文不行是这些国外技术作者的致命伤！

编写LINUX软件时，本书是我案头唯一的必备参考书。
——google软件工程师 MARTIN LANDERS
本书描述精到、示例周详，涵盖了LINUX底层API编程的详尽内容及个中细微之处——无论读者水平如何，都能从本书中受益。
——《Understanding the Linux Virtual Memory Manager》作者 MEL GORMAN
Michael Kerrisk的这本LINUX编程巨著，不但论及LINUX编程、其与各种标准之间的联系，而且还就作者所知，重点介绍了已获修正的LINUX内核BUG以及改进颇多的LINUX手册页。凭借以上三个方面，足可让LINUX编程更易上手。本书对各项主题的深入探讨足以使其成为必备的参考书籍———无论读者在LINUX编程方面造诣如何。
——NOVELL公司，OPENSUSE项目经理，ANDREAS JAEGER
Michael用他坚韧不拔的毅力为Linux程序员奉献了这本论述严谨，表述清晰、简洁的权威参考书。虽然本书是针对Linux程序员而著，但对任何在UNIX/POSIX环境中编程的程序员来说都极具价值。
——《Programming with POSIX Threads》作者和POSIX /UNIX标准撰写者，DAVID BUTENHOF
本书在重点关注Linux系统的同时，对于UNIX系统和网络编程也阐述透彻，浅显易懂。无论是初涉UNIX编程的新丁，还是UNIX编程经验丰富的老手（想要了解大行其道的GNU/Linux系统有何新意），我都向他们力荐此书。
——网络安全研究员，IETF参与者，IETF RFC作者 FERNANDO GONT
本书以百科全书般的叙述风格对LINUX接口编程作了既深且广的覆盖，还提供了大量教科书风格的编程示例和练习。本书所包含的各项主题——从原理到可以实际运行的代码，都描述清晰且易于理解。本书正是专业人士、学生以及教育工作者所期盼的Linux/UNIX参考书。
——OTAGO大学计算机科学副教授，ANTHONY ROBINS
无论从精确性、质量还是详细程度来说，本书都令我印象深刻。身为Linux系统调用的行家，Michael Kerrisk与我们分享了他对LINUX API的认知和理解。
——《Programmation système en C sous Linux》作者，CHRISTOPHE BLAESS。
对于治学严谨的专业LINUX/UNIX系统程序员而言，本书实为必备参考书籍。本书涵盖了所有关键API的使用——同时兼顾LINUX和UNIX系统接口，描述清晰，示例具体；除此之外，还强调了遵从诸如SUS和POSIX 1003.1等标准的重要性和益处。
——THE OPEN GROUP 标准部总监，POSIX 1003.1工作组主席ANDREW JOSEY
由手册页的维护者亲自操刀、站在系统程序员的立场写出一本百科全书式的LINUX系统编程巨著——还有比这更完美的吗？《LINUX编程接口》全面而又详实。我坚信本书将在我的书架上牢牢占据一席之地。
——《POSIX.4 Programmer’s Guide: Programming for the Real World》作者 BILL GALLMEISTER
本书是最新最全的LINUX/UNIX系统编程参考书。无论读者是LINUX系统编程新兵，还是关注LINUX编程和程序移植性的UNIX系统编程老将，又或者只是在寻找一本LINUX编程接口方面的优秀参考书，Michael Kerrisk的这本大作都笃定是其案头良伴。
——CORPULS.COM首席软件架构师（嵌入式）LOÏC DOMAIGNÉ。

很不错的 Linux 编程参考书

clan 2011-02-16 0赞

粗略的扫了一遍，许多2.6最新的接口都有详细的介绍，对 Linux 编程来说可以取代 APUE 作为案头参考书了。

前面有人提到到语文的问题，我觉得对技术书籍来说只要不是太晦涩就不是大的问题吧。

可以替换AUPE了

toby 2015-01-04 0赞

花了几天时间，也只算是把这本书的内容大致过了一遍，还有很多细节的东西没有弄清楚，特别是信号、权限控制等等。UNIX真是一个复杂的系统！
这本书号称超越AUPE，读起来确实不那枯燥，特别是有很多特性如何选择的最佳实践，这是最实用的地方！有些Linux上特有的特性如epoll，AUPE上也没有。
翻译还可以，只是可能是很多人合译的原因，感觉有的章节译得好，有的章节不那么好。

好的技术书籍也可以像词典

史提夫孫 2012-08-21 1赞

就像搞编辑的案头应该放一本《新华字典》、搞数学的案头应该放一本《数学手册》一样，搞Linux开发的案头就应该放一本APUE。或者，你可以考虑再放一本《The Linux Programming Interface》。

也许用其它任何一种标准来衡量，此书都难称上品，但作为工具书，我非常愿意给它五星。如果脑袋是主机，那工具书就是外置存储。工具书的目的不是像教科书那样帮助读者建立概念或者提高技能，而是罗列细节。语言简练，条理清晰，代码示例简单明了，这些基本要求都做到了。值得一提的是此书向APUE致敬的插图，简洁细致，别具一格，绝非Word框图货色。西谚云“一图胜千言”，此之谓也。当然，最重要的一点是，全，要啥有啥。这点其实蛮不容易的。全书64章，多数人恐怕一辈子也没机会全部涉猎（那得多骨灰级啊……），因而此书的全面难能可贵，也是这本书最大的价值。

另外，好像有人说这本书的英文不够好？至少我读到的部分都很好，或者说足够好了。对于绝大多数国人（当然，不包括替作者“遮了很多丑”的某些译者）来说，绝对不用担心你的程序会因此而崩溃或者你的英文水平会因此而降低。

中文版《Linux/UNIX系统编程手册》（上、下册）1月10日左右上市

出版圈郭志敏 2013-12-30 1赞

本书的中文书名：Linux/UNIX系统编程手册

Linux/UNIX系统编程接口权威巨著，无出其右；
涵盖500多个系统调用和库函数；示例清晰完整，解释巨细靡遗；
涵盖当前UNIX标准（POSI X.1-2001/SUS v3和POSI X.1-2008/SUS v4）；
众多业内专家人士联袂推荐；
Linux/UNIX开发人员的案头必备，注定成为新的经典；

下周二主发，2014年1月10日之前上市

翻译略有瑕疵，但在linux编程方面是不可多得的好书

lifayi2008 2014-10-27 1赞

本书既可以用来全面熟悉Linux/Unix系统编程，又可以作为手册时常查阅，阅读时最好有C基础和linux的使用经验

有同学说本书内容全面细致，但是缺乏由浅入深的特性，个人认为这样的书很难对初学者表现的很友好，包括APUE也是这样，读起来还不如这本更顺畅

2015-09-12
一年内利用空闲时间把本书读了三遍，代码也都敲过一遍，零碎的东西还是没记住，不过好再把握住几个大的概念：文件I/O，缓冲，权限管理，信号，进程/线程，作业控制，进程间通信，内存映射，socket，io多路复用；接下来就是找点小型开源项目自己来实现一下，把编程中常见的坑都踩一踩。估计这两本书要伴随我的整个编程生涯了

我觉得挺不错的 && 关于孙嘻嘻对本书的评价

qwerty 2011-06-11 13

虽然我没有本书纸质版, 本书的电子版倒是看了两三章了, 个人感觉还是挺不错的.
先不说国外有没有托, 起码amazon上面一堆的5星还是能说明本书有一定的阅读价值. 像孙嘻嘻这样直接给1星我个人是不认可的. 哪怕你是本书的译者.
在我看来, 有能力去看原版的读者, 英语一般就不差, 过于拘泥于英语水平实在没有必要, 起码对比起国内一堆堆最为中国人自己都难以理解译作, 我觉得看这本书真的毫无压力, 更何况写得更恶心更难以理解的英文论文都啃不知多少了.
我觉之前有人说能作为LINUX的APUE还是可以理解的, 说得是起到APUE作为参考的作用, 毕竟这本书完全面向LINUX, 而APUE是unix, linux均有. 当然, 没有说这本书写得和APUE一样好, 只是从作用上来说.
Richard写的书哪本不是经典, 要不是这家伙热爱开飞机和跳伞死的早, 他的书没有了更新, 我估计现在关于网络编程和*nix的书一定会大量减少.
所以我觉得孙嘻嘻就不用吹毛求疵了, 你这么有空上豆瓣这种主流并不讨论技术的平台来踩你翻译这本书, 还不如专心译好这本书吧.
你把这本书踩的一无是处也不见的到时买中文版的人就会增多吧.
anyway, 如果你能在我存够钱买原版前把这本书译好, 并且译得不错, 我还是会毫不犹豫去买你的中文版, 并上来豆瓣给你的中文版一个5星的.

最近半年的学习有感

乐一乐lyl 2013-03-17 5

这本书出来时，有人在cu推荐了，我下载回来了电子版，据说是和apue不分伯仲的好书，那个时候，我一点都不会写程序，对c语言的理解也是仅仅限于理论知识熟悉一点，想要写一个简单程序，对我来说都是一个不可完成的任务。
一方面我知道自己的现状，想要让自己通过学习实践去提升技能；另一方面我又太懒总看书不想动手实践。悟性太差，不知道如何利用手上已有的知识组合起来，写些小玩意儿练习练习。虽说如此，还是断断续续的在读这本书，按顺序大概看了十五六章，发现自己还是不会写程序，这种状况很让人沮丧，我把自己的现状在irc里面说了一下，有个网友推荐了《understanding unix/linux programming》给我，我结合起来看，
感觉自己似乎焕发了第二春，uulp里面的实践方向，tlpi的理论知识，两者的结合起来，让我开始能上手写些小玩意儿了，这种感觉真不错。

对此书“赞誉”的翻译

孙嘻嘻 2011-02-07 4

我是此书中文译本的译者之一。此书并非像amazon.com上说的那般神。首先，作者的表达能力就非常够呛。其次，本书的大批技术审校者母语都非英语。
一本描写技术细节的书，如果作者的写作能力不过关，其结果会如何呢？

以下是我们翻译的一干技术审校者对本书的“赞誉”，我可以这么说，在译文的文字表达方面，我们已经替这一干"title"众多的审校者遮了很多丑了。语文不行是这些国外技术作者的致命伤！

编写LINUX软件时，本书是我案头唯一的必备参考书。
——google软件工程师 MARTIN LANDERS
本书描述精到、示例周详，涵盖了LINUX底层API编程的详尽内容及个中细微之处——无论读者水平如何，都能从本书中受益。
——《Understanding the Linux Virtual Memory Manager》作者 MEL GORMAN
Michael Kerrisk的这本LINUX编程巨著，不但论及LINUX编程、其与各种标准之间的联系，而且还就作者所知，重点介绍了已获修正的LINUX内核BUG以及改进颇多的LINUX手册页。凭借以上三个方面，足可让LINUX编程更易上手。本书对各项主题的深入探讨足以使其成为必备的参考书籍———无论读者在LINUX编程方面造诣如何。
——NOVELL公司，OPENSUSE项目经理，ANDREAS JAEGER
Michael用他坚韧不拔的毅力为Linux程序员奉献了这本论述严谨，表述清晰、简洁的权威参考书。虽然本书是针对Linux程序员而著，但对任何在UNIX/POSIX环境中编程的程序员来说都极具价值。
——《Programming with POSIX Threads》作者和POSIX /UNIX标准撰写者，DAVID BUTENHOF
本书在重点关注Linux系统的同时，对于UNIX系统和网络编程也阐述透彻，浅显易懂。无论是初涉UNIX编程的新丁，还是UNIX编程经验丰富的老手（想要了解大行其道的GNU/Linux系统有何新意），我都向他们力荐此书。
——网络安全研究员，IETF参与者，IETF RFC作者 FERNANDO GONT
本书以百科全书般的叙述风格对LINUX接口编程作了既深且广的覆盖，还提供了大量教科书风格的编程示例和练习。本书所包含的各项主题——从原理到可以实际运行的代码，都描述清晰且易于理解。本书正是专业人士、学生以及教育工作者所期盼的Linux/UNIX参考书。
——OTAGO大学计算机科学副教授，ANTHONY ROBINS
无论从精确性、质量还是详细程度来说，本书都令我印象深刻。身为Linux系统调用的行家，Michael Kerrisk与我们分享了他对LINUX API的认知和理解。
——《Programmation système en C sous Linux》作者，CHRISTOPHE BLAESS。
对于治学严谨的专业LINUX/UNIX系统程序员而言，本书实为必备参考书籍。本书涵盖了所有关键API的使用——同时兼顾LINUX和UNIX系统接口，描述清晰，示例具体；除此之外，还强调了遵从诸如SUS和POSIX 1003.1等标准的重要性和益处。
——THE OPEN GROUP 标准部总监，POSIX 1003.1工作组主席ANDREW JOSEY
由手册页的维护者亲自操刀、站在系统程序员的立场写出一本百科全书式的LINUX系统编程巨著——还有比这更完美的吗？《LINUX编程接口》全面而又详实。我坚信本书将在我的书架上牢牢占据一席之地。
——《POSIX.4 Programmer’s Guide: Programming for the Real World》作者 BILL GALLMEISTER
本书是最新最全的LINUX/UNIX系统编程参考书。无论读者是LINUX系统编程新兵，还是关注LINUX编程和程序移植性的UNIX系统编程老将，又或者只是在寻找一本LINUX编程接口方面的优秀参考书，Michael Kerrisk的这本大作都笃定是其案头良伴。
——CORPULS.COM首席软件架构师（嵌入式）LOÏC DOMAIGNÉ。

本书前言的译文

孙嘻嘻 2011-02-13 2

前言
主题
本书将描述Linux编程接口：由UNIX操作系统的开源实现——LINUX所提供的系统调用、库函数以及其它底层接口。运行于LINUX之上的每一程序都会直接或间接地使用这些接口。这些接口允许应用程序去执行诸多任务：文件I/O、创建/删除文件和目录、创建新进程、执行程序、设置计时器、在同一计算机上发起进程或线程间通信，以及为联网计算机间的进程建立通信等等。有时，人们也将这一系列的底层接口称为系统编程接口。
尽管本书着眼于LINUX，但对于标准和可移植性问题也倍加关注。对于LINUX所特有的技术细节，以及已由POSIX和SUS标准化的UNIX普遍特性，本书会在论述中清晰地加以区分。因此，本书亦提供了对UNIX/POSIX编程接口的全面描述。对于那些在其它UNIX系统环境中编程，或者编写跨平台可移植应用程序的程序员来说，本书同样具有实用价值。
本书的读者
本书主要针对以下读者：

本书第2章1-6节译文

孙嘻嘻 2011-05-27 1

译文如有不妥，或有任何反馈意见可发豆邮给我。

第2章基本概念
本章旨在向LINUX和UNIX“生手”们介绍一系列与LINUX系统编程有关的概念。
2.1 操作系统的核心——内核
术语“操作系统”通常包含两种不同涵义：
1、指完整的软件包，这包括用来管理计算机资源的核心层软件，以及附带的所有标准软件工具，诸如，命令行解释器、图形用户界面、文件操作工具和文本编辑器等。
2、在更狭义的范围内，是指管理和分配计算机资源（即CPU、RAM和设备）的核心层软件。
术语“内核”通常是第二种涵义，本书中的“操作系统”一词也是这层意思。
虽然在没有内核的情况下，计算机也能运行程序，但有了内核会极大简化其它程序的编写和使用，令程序员“功力”大进、游刃有余。这要归功于内核为管理计算机的有限资源所提供的软件层。
一般情况下，LINUX内核可执行文件采用/boot/vmlinuz或与之类似的路径名。而文件名的来历也颇有渊源。早期的UNIX实现称其内核为UNIX。在后续实现了虚拟内存机制的UNIX系统中，其内核名称变更为vmunix。对LINUX来说，文件名称中的系统名需要调整，而以“z”替换“linux”末尾的“x”，意在表明内核是经过压缩的可执行文件。
内核的职责
内核所能执行的主要任务有：
•进程调度：计算机均配有一个或多个CPU（中央处理单元），以执行程序指令。与其它UNIX系统一样，LINUX属于抢占式多任务操作系统。“多任务”意指多个进程（即运行中的程序）可同时驻留于内存，且每个进程都能获得对CPU的使用权。“抢占”则是指一组规则：这组规则控制着哪些进程获得对CPU的使用，以及每个进程能使用多长时间，这两者都由内核进程调度程序（而非进程本身）决定。
•内存管理：以一、二十年前的标准来看，如今计算机的内存容量可谓相当可观，但软件的规模也保持了相应地增长，故而物理内存（RAM）仍然属于有限资源，内核必须以公平、高效地方式在进程间共享这一资源。与大多数现代操作系统一样，LINUX也采用了虚拟内存管理机制（6.4节），这项技术主要具有以下两方面的优势：
——进程与进程之间、进程与内核之间彼此隔离，因此一个进程无法读取/修改内核或其他进程的内存内容。
——只需将进程的一部分保存在内存中，这不但降低了每个进程对内存的需求量，而且还能在RAM中同时加载更多的进程。这也大幅提升了如下事件的发生概率：在任一时刻，CPU都有至少一个进程可以执行——从而使得对CPU资源的利用更加充分。
•提供了文件系统：内核在磁盘之上提供有文件系统，允许对文件执行创建、获取、更新以及删除等操作。
•创建和终止进程：内核可将新程序载入内存，为其提供运行所需的资源（比如，CPU、内存以及对文件的访问等）。这样一个运行中的程序我们称之为“进程”。一旦进程执行完毕，内核还要确保释放其占用的资源，以供后续程序重新使用。
•对设备的访问：计算机外接设备（鼠标、键盘，磁盘和磁带驱动器等）可实现计算机与外部世界的通信，这一通信机制包括：输入、输出或是两者兼而有之。内核既为程序访问设备提供了简化版的标准接口，同时还要仲裁多个进程对每一设备的访问。
•联网：内核以用户进程的名义收发网络消息（数据包）。该任务包括将网络数据包路由至目标系统。
•提供系统调用应用编程接口（API）：进程可利用内核入口点（也称为系统调用）请求内核去执行各种任务。LINUX系统调用API是本书的主题。3.1节会详细描述进程在执行系统调用时所经历的步骤。
除了上述特性外，一般而言，诸如LINUX之类的多用户操作系统会为每个用户营造一种抽象：虚拟私有计算机（virtual private computer），这就是说，每个用户都可登录进系统、独立操作，而与其他用户大致无干。例如，每个用户都有属于自己的磁盘存储空间（主目录）。再者，用户能够运行程序，而每一程序都能从CPU资源中“分得一杯羹”、运转于自有的虚拟地址空间中。而且这些程序还能独立访问设备，并通过网络传递信息。内核负责解决（多进程）访问硬件资源时可能引发的冲突，用户和进程对此则往往一无所知。
内核态和用户态
现代处理器架构一般允许CPU至少在两种不同状态下运行，即：用户态和核心态（有时也称之为监管态[supervisor mode]）。执行硬件指令可使CPU在两种状态间来回切换。与之对应，可将虚拟内存区域划分（标记）为用户空间部分或内核空间部分。在用户态下运行时，CPU只能访问被标记为用户空间的内存；试图访问属于内核空间的内存会引发硬件异常。当运行于核心态时，CPU既能访问用户空间内存，也能访问内核空间内存。
仅当处理器在核心态运行时，才能执行某些特定操作。这样的例子包括：执行宕机（halt）指令去关闭系统、访问内存管理硬件，以及设备I/O操作的初始化等。实现者们利用这一硬件设计，将操作系统置于内核空间——这确保了用户进程既不能访问内核指令和数据结构，也无法执行不利于系统运行的操作。
以进程及内核视角检视系统
在完成诸多日常编程任务时，程序员们习惯于以面向进程（process-oriented）的思维方式来考虑编程问题。然而，在研究本书后续所涵盖的各种主题时，读者有必要转换视角——站在内核的角度上来看问题。为凸显二者间的差异，本书接下来会分别从进程和内核视角来检视系统。
一个运行系统通常会有多个进程并行其中。对进程来说，许多事件的发生都无法预期。执行中的进程不清楚自己对CPU的占用何时“到期”、系统随之又会调度哪个进程来使用CPU（以及以何种顺序来调度），也不知道自己何时会再次获得对CPU的使用。信号的传递和进程间通信事件的触发由内核统一协调，对进程而言，随时可能发生。诸如此类，进程都一无所知。进程不清楚自己在RAM中的位置，或者换种更通用的说法：进程内存空间的某块特定部分如今到底是驻留在内存中还是被保存在交换空间（磁盘空间中的保留区域，作为计算机RAM的补充）里，进程本身并不知晓。与之类似，进程也闹不清自己所访问的文件“居于”磁盘驱动器的何处；进程只是通过名称来引用文件而已。进程的运作方式堪称“与世隔绝”——进程间彼此不能直接通信。进程本身无法创建出新进程，哪怕“自行了断”都不行。最后还有一点，进程也不能与计算机外接的输入输出设备直接通信。
相形之下，内核则是运行系统的中枢所在，对于系统的一切无所不知、无所不能，为系统上所有进程的运行提供便利。由哪个进程来接掌对CPU的使用、何时“接任”、“任期”多久，都由内核说了算。在内核维护的数据结构中，包含了与所有正在运行的进程有关的信息；随着进程的创建、状态发生变化或者终结，内核会及时更新这些数据结构。内核所维护的底层数据结构可将程序使用的文件名转换为磁盘的物理位置。此外，每个进程的虚拟内存与计算机物理内存及磁盘交换区之间的映射关系，也在内核维护的数据结构之列。进程间的所有通信都要通过内核提供的通信机制来完成。响应进程发出的请求，内核会创建新的进程、终结现有进程。最后，由内核（特别是设备驱动程序）来执行与输入/输出设备之间的所有直接通信，按需与用户进程交互信息。
本书后续内容中会出现如下措辞，例如：“某进程可创建另一个进程”、“某进程可创建管道”、“某进程可将数据写入文件”，以及“调用exit()以终止某进程”。请务必牢记，以上所有动作都是由内核来居中“调停”，上面的说法不过是“某进程可以请求内核创建另一个进程”的缩略语，以此类推。
进阶阅读
涵盖操作系统概念和设计、尤其是对UNIX操作系统加以重点关注的现代教科书包括：[Tanenbaum, 2007]、[Tanenbaum & Woodhull,2006]以及[Vahalia, 1996]，最后一本包含了与虚拟内存架构有关的详细内容。[Goodheart & Cox, 1994]详细介绍了System V Release 4。[Maxwell, 1999]则是有选择性的针对Linux 2.2.5的部分内核源码进行了注释。[Lions, 1996]对第六版UNIX源码进行了详尽阐释，并一直是研究UNIX操作系统内幕的入门级经典。[Bovet & Cesati, 2005]描述了LINUX2.6内核的实现。
2.2 Shell
Shell是一种具有特殊用途的程序，主要用于读取用户输入的命令，并执行相应的程序以响应命令。有时，人们也称之为命令解释器。
术语登录shell（login shell）是指：用户刚登录系统时，由系统创建、用以运行shell的进程。尽管某些操作系统将命令解释器集成于内核中，而对UNIX系统而言，shell只是一个用户进程。shell的种类繁多，登入同一台计算机的不同用户可同时使用不同的shell（就单个用户来说，情况也一样）。纵观UNIX历史，出现过以下几种重要的shell：
•Bourne shell (sh)：这款由Steve Bourne编写的shell历史最为悠久，且应用广泛，曾是第七版UNIX的标配shell。Bourne shell包含了在其他shell中常见的许多特性：I/O重定向、管道、文件名生成（通配符）、变量、环境变量处理、命令替换、后台命令执行以及函数。对于所有问世于第七版UNIX之后的实现而言，除了可能提供有其他shell之外，都附带了Bourne shell。
•C shell (csh):由Bill Joy于加州大学伯克利分校编写而成。其命名则源于该脚本语言的流控制语法与C语言有着许多相似之处。C shell当时提供了若干极为实用的交互式特性，这些特性并不为Bourne shell所支持，其中包括：命令的历史记录、命令行编辑功能、任务控制和别名等。C shell与Bourne shell并不兼容。尽管C shell曾是BSD系统标配的交互式shell，但一般情况下，人们还是喜欢针对Bourne shell编写shell脚本（稍后介绍），以便其能够在所有UNIX实现上移植。
•Korn shell (ksh): AT&T贝尔实验室的David Korn编写了这款shell，作为Bourne shell的“继任者”。在保持与Bourne shell兼容的同时，Korn shell还吸收了那些与C shell相类似的交互式特性。
•Bourne again shell (bash):这款shell是GNU项目对Bourne shell的重新实现。Bash提供了与C shell和Korn shel所类似的交互式特性。Brian Fox 和Chet Ramey是bash的主要作者。bash或许是LINUX上应用最为广泛的shell了。（在LINUX上，Bourne shell,（sh）其实正是由bash仿真提供的。）
POSIX.2-1992基于当时的Korn shell版本定义了一个shell标准。如今，Korn shell和bash都符合POSIX规范，但两者都提供了大量对标准的扩展，其扩展之间存在许多差异。
设计shell的目的不仅仅是用于人机交互，对shell脚本（包含shell命令的文本文件）进行解释也是其用途之一。为实现这一目的，每款shell都内置有许多通常与编程语言相关的功能，其中包括：变量、循环和条件语句、I/O命令以及函数等。
尽管在语法方面有所差异，每款shell执行的任务都大致相同。除非指明是某款特定shell的操作，否则书中的“shell” 都会按所描述的方式运作。本书绝大多数需要用到shell的示例都会使用bash，若无其他说明，读者可假定这些示例也能以相同方式在其他类Bourne的shell上运行。
2.3 用户和组
    系统会对每个用户的身份做唯一标识，用户可隶属于多个组。
用户
系统的每个用户都拥有唯一的登录名（用户名）和与之相对应的整数型用户ID (UID)。系统密码文件/etc/passwd为每个用户都定义有一行记录，除了上述两项信息外，该记录还包含如下信息：
•组ID: 用户所属第一个组的整数型组ID。
•主目录：用户登录后所居于的初始目录。
•登录shell：执行以解释用户命令的程序名称。
该记录还能以加密形式保存用户密码。然而，出于安全考虑，用户密码往往存储于单独的shadow密码文件中，仅供特权用户阅读。
组
出于管理目的，尤其是为了控制对文件和其它资源的访问，将多个用户分组是非常实用的做法。例如，某项目的开发团队人员需要共享同一组文件，就可以将他们编为同一组的成员。在早期的UNIX实现中，一个用户只能隶属于一个组。BSD率先允许一个用户同时属于多个组，这一理念后来被其它UNIX实现纷纷效仿，并最终成为POSIX.1-1990标准。每个用户组都对应着系统组文件/etc/group中的一行记录，该记录包含如下信息：
•组名:组名称（具有唯一性）。
•组ID (GID)：与组相关的整数型ID。
•用户列表：隶属于该组的用户登录名列表（通过密码文件记录的group ID字段未能标识出的该组其他成员，也在此列），以逗号分隔。
超级用户
超级用户在系统中享有特权。超级用户帐号的用户ID为0，通常登录名为root。在一般的UNIX系统上，超级用户凌驾于系统的权限检查之上。因此，无论对文件施以何种访问权限限制，超级用户都可以访问系统中的任何文件，也能发送信号干预系统运行的所有用户进程。系统管理员可以使用超级用户账号来执行各种系统管理任务。
2.4 单根目录层级、目录、链接及文件
    内核维护着一套单根目录结构，以放置系统的所有文件。（这与微软windows之类的操作系统形成了鲜明对照，windows系统的每个磁盘设备都有各自的目录层级。）这一目录层级的根基就是名为“/”的根目录。所有的文件和目录都是根目录的“子孙”。图1-2所示为这种文件层级结构的示例。
图2-1 Linux单根目录层级的一部分
文件类型
在文件系统内，会对文件类型进行标记，以表明其种类。其中一种用来表示普通数据文件，人们常称之为“普通文件”或“纯文本文件”，以示与其他种类的文件有所区别。其他文件类型包括：设备、管道、套接字、目录以及符号链接。
术语“文件”常用来指代任意类型的文件，不仅仅指普通文件。
路径和链接
目录是一种特殊类型的文件，内容采用表格形式，数据项包括文件名以及对相应文件的引用。这一“文件名+引用”的组合被称为链接。每个文件都可以有多条链接，因而也可以有多个名称，在相同或不同的目录中出现。
目录可包含指向文件或其他目录的链接。路径间的链接建立起如图2-1所示的目录层级。
每个目录至少包含两条记录：.和..，前者是指向目录自身的链接，后者是指向其上级目录——父目录的链接。除根目录外，每个目录都有父目录。对于根目录而言，..是指向根目录自身的链接（因此，/..等于/）。
符号链接
类似于普通链接，符号链接给文件起了一个“别号”（alternative name）。在目录列表中，普通链接是内容为“文件名+指针”的一条记录，而符号链接则是经过特殊标记的文件，内容包含了另一文件的名称。（换言之，一个符号链接对应着目录中内容为“文件名+指针”的一条记录，指针指向的文件内容（译注：及该文件所属数据块存储的内容）为另一个文件名的字符串。）所谓“另一文件”通常被称为符号链接的目标，人们一般会说：符号链接“指向”或“引用”目标文件。在多数情况下，只要系统调用用到了路径名，内核会自动解除（换言之，按照）该路径名中符号链接的引用，以符号链接所指向的文件名来替换符号链接。若符号链接的目标文件自身也是一个符号链接，那么上述过程会以递归方式重复下去。（为了应对可能出现的循环引用，内核对解除引用的次数作了限制。）如果符号链接指向的文件并不存在，那么可将该链接视为空链接（dangling link）。
通常，人们会分别使用硬链接（hard link）或软链接（soft link）这样的术语来指代正常链接和符号链接。之所以存在这两种不同类型的链接，将在第十八章做出解释。
文件名
    在大多数Linux文件系统上，文件名最长可达255个字符。文件名可以包含除“/”和空字符()外的所有字符。但是，只建议使用字母、数字、点(“.”)、下划线（“_”）以及连字符（“-”）。SUSv3将这一65个字符的集合——[-._a-zA-Z0-9]称为可移植文件名字符集（portable filename character set）。
对于可移植文件名字符集以外的字符，由于其可能会在shell、正则表达式或其他场景中具有特殊含义，故而应避免在文件名中使用。如在上述环境中出现了包含特殊含义字符的文件名，则需要进行转义，即对此类字符进行特殊标记（一般会在特殊字符前插入一个“”），以指明不应以特殊含义对其进行解释。若场境不支持转义机制，则不能使用此类文件名。
此外，还应避免以连字符（“-”）作为文件名的起始字符，因为一旦在shell命令中使用这种文件名，会被误认为命令行选项开关。
路径名
路径名是由一系列文件名组成的字符串，彼此以“/”分隔，首字符可以为“/”（非强制）。（译注：此处“文件”的含义中包括了目录——如前文所述：“目录是一种特殊类型的文件”）除却最后一个文件名外，该系列文件名均为目录名称（或为指向目录的符号链接）。路径名的尾部（译注：即最后一个文件名）可标识任意类型的文件，包括目录在内。有时将该字符串中最后一个“/”字符之前的部分称为路径名的目录部分，将其之后的部分称为路径名的文件部分或基础部分。
路径名应按从左至右的顺序阅读，路径名中每个文件名之前的部分，即为该文件所处目录。可在路径名中任意位置后引入字符串".."（译注：需以“/”分隔），用以指代路径名中当前位置的父目录。
路径名描述了单根目录层级下的文件位置，又可分为绝对路径名和相对路径名：
•绝对路径名以“/”开始，指明文件相对于根目录的位置。图2-1中的/home/mtk/.bashrc、/usr/include以及/（根路径的路径名）都是绝对路径名的例子。
•相对路径名定义了相对于进程当前工作目录（见下文）的文件位置，与绝对路径名相比，相对路径名缺少了起始的“/”。如图2-1所示，在目录usr下，可使用相对路径名include/sys/types.h来引用文件types.h；在目录avr下，可使用相对路径名../mtk/.bashrc来访问文件.bashrc。
当前工作目录
每个进程都有一个当前工作目录（有时简称为进程工作目录或当前目录）。这就是单根目录层级下进程的“当前位置”，也是进程解释相对路径名的参照点。
进程的当前工作目录继承自其父进程。对登录shell来说，其初始当前工作目录，是依据密码文件中该用户记录的主目录字段来设置。可使用cd命令来改变shell的当前工作目录。
文件的所有权和权限
每个文件都有一个与之相关的用户ID和组ID，分别定义文件的属主和属组。系统根据文件的所有权来判定用户对文件的访问权限。
为了访问文件，系统把用户分为三类：文件的属主（有时，也称为文件的用户）、（与文件组（group）ID相匹配的）属组成员用户、以及其他用户。可为以上三类用户分别设置三种权限（共计9种权限位）：只允许查看文件内容的读权限；允许修改文件内容的写权限；允许执行文件的执行权限——这里的文件要么指程序，要么是交由某种解释程序（通常指shell的一种，但也有例外）处理的脚本。
也可针对目录进行上述权限设置，但意义稍有不同：读权限允许列出目录内容（即该目录下的文件名）；写权限允许对目录内容进行更改（比如，添加、修改或删除文件名）；执行（有时也称为搜索）权限允许对目录中的文件进行访问（但需受文件自身访问权限的约束）。
2.5 文件I/O模型
UNIX系统I/O模型最为显著的特性之一是其I/O通用性概念。也就是说，同一套系统调用（open()、read()、write()、close()等）所执行的I/O操作，可施之于所有文件类型，包括设备文件在内。（应用程序发起的I/O请求，内核会将其转化为相应的文件系统操作、或者设备驱动程序操作，以此来执行针对目标文件或设备的I/O操作。）因此，采用这些系统调用的程序能够处理任何类型的文件。
就本质而言，内核只提供一种文件类型：字节流序列，在处理磁盘文件、磁盘或磁带设备时，可通过lseek（）系统调用来随机访问。
许多应用程序和函数库都将新行符（十进制ASCII码为10，有时亦称其为换行）视为文本中一行的结束和另一行的开始。UNIX系统没有文件结束符的概念；读取文件时如无数据返回，便会认定抵达文件末尾。
文件描述符
I/O系统调用使用文件描述符——（往往是数值很小的）非负整数——来指代打开的文件。获取文件描述符的常用手法是：调用open()，在参数中指定I/O操作目标文件的路径名。
通常，由shell启动的进程会继承三个已打开的文件描述符：描述符0为标准输入，指代为进程提供输入的文件；描述符1为标准输出，指代供进程写入输出的文件；描述符2为标准错误，指代供进程写入错误消息或异常通告的文件。在交互式shell或程序中，上述三者一般都指向终端。在stdio函数库中，这几种描述符分别与文件流stdin、stdout和stderr相对应。
stdio函数库
    C编程语言在执行文件I/O操作时，往往会调用C语言标准库的I/O函数。也将这样一组I/O函数称为stdio函数库，其中包括：fopen(), fclose(), scanf(), printf(), fgets(), fputs()等。stdio函数位于I/O系统调用层(open(), close(), read(), write()等)之上。

本书假定读者已经了解了C语言的标准I/O (stdio)函数，因此也不会介绍这方面的内容。更多与stdio函数库有关的信息请参考[Kernighan & Ritchie, 1988], [Harbison & Steele，2002], [Plauger, 1992], 和[Stevens & Rago, 2005]。
2.6 程序
程序通常以两种面目示人。其一为源码形式，由使用编程语言（比如，C语言）写成的一系列语句组成，是人类可以阅读的文本文件。要想执行程序，则需将源码转换为第二种形式——计算机可以理解的二进制机器语言指令。（这与脚本形成了鲜明对照，脚本是包含命令的文本文件，可以由shell或其它命令解释器之类的程序直接处理。）一般认为，术语“程序”的上述两种含义几近相同，因为经过编译和链接处理，会将源码转换为语义相同的二进制机器码。
过滤器
从stdin读取输入、加以转换，再将转换后的数据输出到stdout——常常将拥有上述行为的程序称为过滤器，cat，grep，tr，sort，wc，sed，awk均在其列。
命令行参数
C语言程序可以访问命令行参数——即程序运行时在命令行中输入的内容。要访问命令行参数，程序的main()函数需做如下声明：
int main(int argc, char *argv[])
argc变量包含命令行参数的总个数，argv指针数组的成员指针则逐一指向每个命令行参数字符串。首个字符串，argv[0]，标识程序名本身。

好的技术书籍也可以像词典

史提夫孫 2012-08-21 1

就像搞编辑的案头应该放一本《新华字典》、搞数学的案头应该放一本《数学手册》一样，搞Linux开发的案头就应该放一本APUE。或者，你可以考虑再放一本《The Linux Programming Interface》。

也许用其它任何一种标准来衡量，此书都难称上品，但作为工具书，我非常愿意给它五星。如果脑袋是主机，那工具书就是外置存储。工具书的目的不是像教科书那样帮助读者建立概念或者提高技能，而是罗列细节。语言简练，条理清晰，代码示例简单明了，这些基本要求都做到了。值得一提的是此书向APUE致敬的插图，简洁细致，别具一格，绝非Word框图货色。西谚云“一图胜千言”，此之谓也。当然，最重要的一点是，全，要啥有啥。这点其实蛮不容易的。全书64章，多数人恐怕一辈子也没机会全部涉猎（那得多骨灰级啊……），因而此书的全面难能可贵，也是这本书最大的价值。

另外，好像有人说这本书的英文不够好？至少我读到的部分都很好，或者说足够好了。对于绝大多数国人（当然，不包括替作者“遮了很多丑”的某些译者）来说，绝对不用担心你的程序会因此而崩溃或者你的英文水平会因此而降低。

中文版《Linux/UNIX系统编程手册》（上、下册）1月10日左右上市

出版圈郭志敏 2013-12-30 1

本书的中文书名：Linux/UNIX系统编程手册

Linux/UNIX系统编程接口权威巨著，无出其右；
涵盖500多个系统调用和库函数；示例清晰完整，解释巨细靡遗；
涵盖当前UNIX标准（POSI X.1-2001/SUS v3和POSI X.1-2008/SUS v4）；
众多业内专家人士联袂推荐；
Linux/UNIX开发人员的案头必备，注定成为新的经典；

下周二主发，2014年1月10日之前上市

翻译略有瑕疵，但在linux编程方面是不可多得的好书

lifayi2008 2014-10-27 1

本书既可以用来全面熟悉Linux/Unix系统编程，又可以作为手册时常查阅，阅读时最好有C基础和linux的使用经验

有同学说本书内容全面细致，但是缺乏由浅入深的特性，个人认为这样的书很难对初学者表现的很友好，包括APUE也是这样，读起来还不如这本更顺畅

2015-09-12
一年内利用空闲时间把本书读了三遍，代码也都敲过一遍，零碎的东西还是没记住，不过好再把握住几个大的概念：文件I/O，缓冲，权限管理，信号，进程/线程，作业控制，进程间通信，内存映射，socket，io多路复用；接下来就是找点小型开源项目自己来实现一下，把编程中常见的坑都踩一踩。估计这两本书要伴随我的整个编程生涯了

翻译给不给力啊

雨过白鹭洲 2011-08-29 1

孙同学，请问你们几个人翻译本书？

有没有大致的翻译出版时间计划？

我看英文版都快看了30章。。。不过看英文版的问题在于看完不多久就全忘了

你老挑语言上的毛病，没啥必要，真要说起来APUE的原版我也看过，感觉英文也差不多。至少从我做技术的人角度上来看，没啥差别。。。

Linux 编程堪称完美的书

Scofield 2013-03-24 1

老实说，这本书还真是我见过的 Linux system programming 方面最完美的书（包括APUE），以前读国内的书，总觉得很多东西没讲，尤其是 why，在想有没有一本书即讲 what 有讲 why，还特别全的，于是就发现 APUE 就是这么一本书，后来觉得 APUE 也有很多东西是点到即止，比如说内存这一块，于是想有没有一本更全面的书呢，TLPI 就是这样一本，堪称完美。我觉得 Amazon 上5星是实至名归，并不含托

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

The Linux Programming Interface

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读