The DefiniTive Guide To Linux The Linux Programming
The definitive guide to Linuxand UNIX system programming fffRead and write files efficientlyUse signals, clocks, and timersCreate processes and execute programsfffffWrite secure programsWrite multithreaded programs using POSIX threadsBuild and use shared librariesPerform interprocess communication using pipes,message queues, shared memory, and semaphoresWrite network applications with the sockets APIWhile The Linux Programming Interface covers a wealthof Linux-specific features, including epoll, inotify, andthe /proc file system, its emphasis on UNIX standards(POSIX.1-2001/SUSv3 and POSIX.1-2008/SUSv4)makes it equally valuable to programmers working onother UNIX platforms.The Linux Programming Interface is the most comprehensive single-volume work on the Linux and UNIXprogramming interface, and a book that’s destined tobecome a new classic.About the AuthorMichael Kerrisk (http://man7.org/) has been using and programming UNIX systemsfor more than 20 years, and has taught many week-long courses on UNIX systemprogramming. Since 2004, he has maintained the man-pages project, whichproduces the manual pages describing the Linux kernel and glibc programmingAPIs. He has written or cowritten more than 250 of the manual pages and is activelyinvolved in the testing and design review of new Linux kernel-userspace interfaces.Michael lives with his family in Munich, Germany.Covers current UNIX standards (POSIX.1-2001/SUSv3 and POSIX.1-2008/SUSv4)T H E F I N E ST I N G E E K E N T E RTA I N M E N T w w w.nostarch.com 99.95 ( 114.95 CDN )KerriskShelve In: linux/programmingISBN: 978-1-59327-220-35 999 59 781593 272203This logo applies only to the text stock.689145 72200The LinuxProgrammingInterfaceThe Linux Programming Interface is the definitive guideto the Linux and UNIX programming interface—theinterface employed by nearly every application thatruns on a Linux or UNIX system.In this authoritative work, Linux programmingexpert Michael Kerrisk provides detailed descriptionsof the system calls and library functions that you needin order to master the craft of system programming,and accompanies his explanations with clear, completeexample programs.You’ll find descriptions of over 500 system callsand library functions, and more than 200 example programs, 88 tables, and 115 diagrams. You’ll learn how to:0The LinuxProgrammingInterfaceA Linux and UNIX System Programming Handbook Michael Kerrisk
FILE I/O: THE UNIVERSALI/O MODELWe now start to look in earnest at the system call API. Files are a good place tostart, since they are central to the UNIX philosophy. The focus of this chapter is thesystem calls used for performing file input and output.We introduce the concept of a file descriptor, and then look at the system callsthat constitute the so-called universal I/O model. These are the system calls thatopen and close a file, and read and write data.We focus on I/O on disk files. However, much of the material covered here isrelevant for later chapters, since the same system calls are used for performing I/Oon all types of files, such as pipes and terminals.Chapter 5 extends the discussion in this chapter with further details on file I/O.One other aspect of file I/O, buffering, is complex enough to deserve its own chapter.Chapter 13 covers I/O buffering in the kernel and in the stdio library.4.1OverviewAll system calls for performing I/O refer to open files using a file descriptor, a (usuallysmall) nonnegative integer. File descriptors are used to refer to all types of openfiles, including pipes, FIFOs, sockets, terminals, devices, and regular files. Eachprocess has its own set of file descriptors.By convention, most programs expect to be able to use the three standard filedescriptors listed in Table 4-1. These three descriptors are opened on the program’sThe Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpi
behalf by the shell, before the program is started. Or, more precisely, the programinherits copies of the shell’s file descriptors, and the shell normally operates withthese three file descriptors always open. (In an interactive shell, these three filedescriptors normally refer to the terminal under which the shell is running.) If I/Oredirections are specified on a command line, then the shell ensures that the filedescriptors are suitably modified before starting the program.Table 4-1: Standard file descriptorsFile descriptor Purpose012POSIX name stdio streamstandard inputSTDIN FILENOstandard output STDOUT FILENOSTDERR FILENOstandard errorstdinstdoutstderrWhen referring to these file descriptors in a program, we can use either the numbers(0, 1, or 2) or, preferably, the POSIX standard names defined in unistd.h .Although the variables stdin, stdout, and stderr initially refer to the process’sstandard input, output, and error, they can be changed to refer to any file byusing the freopen() library function. As part of its operation, freopen() maychange the file descriptor underlying the reopened stream. In other words,after an freopen() on stdout, for example, it is no longer safe to assume that theunderlying file descriptor is still 1.The following are the four key system calls for performing file I/O (programminglanguages and software packages typically employ these calls only indirectly, via I/Olibraries):zzzzfd open(pathname, flags, mode) opens the file identified by pathname, returninga file descriptor used to refer to the open file in subsequent calls. If the filedoesn’t exist, open() may create it, depending on the settings of the flags bitmask argument. The flags argument also specifies whether the file is to beopened for reading, writing, or both. The mode argument specifies the permissions to be placed on the file if it is created by this call. If the open() call is notbeing used to create a file, this argument is ignored and can be omitted.numread read(fd, buffer, count) reads at most count bytes from the open filereferred to by fd and stores them in buffer. The read() call returns the number ofbytes actually read. If no further bytes could be read (i.e., end-of-file wasencountered), read() returns 0.numwritten write(fd, buffer, count) writes up to count bytes from buffer to theopen file referred to by fd. The write() call returns the number of bytes actuallywritten, which may be less than count.status close(fd) is called after all I/O has been completed, in order to releasethe file descriptor fd and its associated kernel resources.Before we launch into the details of these system calls, we provide a short demonstration of their use in Listing 4-1. This program is a simple version of the cp(1)command. It copies the contents of the existing file named in its first commandline argument to the new file named in its second command-line argument.70Chapter 4The Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpi
We can use the program in Listing 4-1 as follows: ./copy oldfile newfileListing 4-1: Using I/O system ��––––––––––– fileio/copy.c#include sys/stat.h #include fcntl.h #include "tlpi hdr.h"#ifndef BUF SIZE#define BUF SIZE 1024#endif/* Allow "cc -D" to override definition */intmain(int argc, char *argv[]){int inputFd, outputFd, openFlags;mode t filePerms;ssize t numRead;char buf[BUF SIZE];if (argc ! 3 strcmp(argv[1], "--help") 0)usageErr("%s old-file new-file\n", argv[0]);/* Open input and output files */inputFd open(argv[1], O RDONLY);if (inputFd -1)errExit("opening file %s", argv[1]);openFlags O CREAT O WRONLY O TRUNC;filePerms S IRUSR S IWUSR S IRGRP S IWGRP S IROTH S IWOTH;/* rw-rw-rw- */outputFd open(argv[2], openFlags, filePerms);if (outputFd -1)errExit("opening file %s", argv[2]);/* Transfer data until we encounter end of input or an error */while ((numRead read(inputFd, buf, BUF SIZE)) 0)if (write(outputFd, buf, numRead) ! numRead)fatal("couldn't write whole buffer");if (numRead -1)errExit("read");if (close(inputFd) -1)errExit("close input");if (close(outputFd) -1)errExit("close output");exit(EXIT �––––––––––––– fileio/copy.cThe Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpiFi le I/O : The Uni versal I/O Model71
4.2Universality of I/OOne of the distinguishing features of the UNIX I/O model is the concept ofuniversality of I/O. This means that the same four system calls—open(), read(), write(),and close()—are used to perform I/O on all types of files, including devices such asterminals. Consequently, if we write a program using only these system calls, thatprogram will work on any type of file. For example, the following are all valid usesof the program in Listing 4-1: ./copy./copy./copy./copytest test.olda.txt /dev/tty/dev/tty b.txt/dev/pts/16 /dev/ttyCopy a regular fileCopy a regular file to this terminalCopy input from this terminal to a regular fileCopy input from another terminalUniversality of I/O is achieved by ensuring that each file system and device driverimplements the same set of I/O system calls. Because details specific to the file system or device are handled within the kernel, we can generally ignore device-specificfactors when writing application programs. When access to specific features of afile system or device is required, a program can use the catchall ioctl() system call(Section 4.8), which provides an interface to features that fall outside the universalI/O model.4.3Opening a File: open()The open() system call either opens an existing file or creates and opens a new file.#include sys/stat.h #include fcntl.h int open(const char *pathname, int flags, . /* mode t mode */);Returns file descriptor on success, or –1 on errorThe file to be opened is identified by the pathname argument. If pathname is a symbolic link, it is dereferenced. On success, open() returns a file descriptor that is usedto refer to the file in subsequent system calls. If an error occurs, open() returns –1and errno is set accordingly.The flags argument is a bit mask that specifies the access mode for the file, usingone of the constants shown in Table 4-2.Early UNIX implementations used the numbers 0, 1, and 2 instead of thenames shown in Table 4-2. Most modern UNIX implementations define theseconstants to have those values. Thus, we can see that O RDWR is not equivalent toO RDONLY O WRONLY; the latter combination is a logical error.When open() is used to create a new file, the mode bit-mask argument specifies thepermissions to be placed on the file. (The mode t data type used to type mode is aninteger type specified in SUSv3.) If the open() call doesn’t specify O CREAT, mode canbe omitted.72Chapter 4The Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpi
Table 4-2: File access modesAccess modeDescriptionO RDONLYOpen the file for reading onlyOpen the file for writing onlyOpen the file for both reading and writingO WRONLYO RDWRWe describe file permissions in detail in Section 15.4. Later, we’ll see that the permissions actually placed on a new file depend not just on the mode argument, butalso on the process umask (Section 15.4.6) and the (optionally present) defaultaccess control list (Section 17.6) of the parent directory. In the meantime, we’ll justnote that the mode argument can be specified as a number (typically in octal) or,preferably, by ORing ( ) together zero or more of the bit-mask constants listed inTable 15-4, on page 295.Listing 4-2 shows examples of the use of open(), some of which employ additional flags bits that we describe shortly.Listing 4-2: Examples of the use of open()/* Open existing file for reading */fd open("startup", O RDONLY);if (fd -1)errExit("open");/* Open new or existing file for reading and writing, truncating to zerobytes; file permissions read write for owner, nothing for all others */fd open("myfile", O RDWR O CREAT O TRUNC, S IRUSR S IWUSR);if (fd -1)errExit("open");/* Open new or existing file for writing; writes should alwaysappend to end of file */fd open("w.log", O WRONLY O CREAT O TRUNC O APPEND,S IRUSR S IWUSR);if (fd -1)errExit("open");File descriptor number returned by open()SUSv3 specifies that if open() succeeds, it is guaranteed to use the lowest-numberedunused file descriptor for the process. We can use this feature to ensure that a fileis opened using a particular file descriptor. For example, the following sequenceensures that a file is opened using standard input (file descriptor 0).The Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpiFi le I/O : The Uni versal I/O Model73
if (close(STDIN FILENO) -1)errExit("close");/* Close file descriptor 0 */fd open(pathname, O RDONLY);if (fd -1)errExit("open");Since file descriptor 0 is unused, open() is guaranteed to open the file using thatdescriptor. In Section 5.5, we look at the use of dup2() and fcntl() to achieve a similarresult, but with more flexible control over the file descriptor used. In that section,we also show an example of why it can be useful to control the file descriptor onwhich a file is opened.4.3.1The open() flags ArgumentIn some of the example open() calls shown in Listing 4-2, we included other bits(O CREAT, O TRUNC, and O APPEND) in flags in addition to the file access mode. We nowconsider the flags argument in more detail. Table 4-3 summarizes the full set of constants that can be bit-wise ORed ( ) in flags. The final column indicates which ofthese constants are standardized in SUSv3 or SUSv4.Table 4-3: Values for the flags argument of open()FlagPurposeO RDONLYOpen for reading onlyOpen for writing onlyOpen for reading and writingSet the close-on-exec flag (since Linux 2.6.23)Create file if it doesn’t already existFile I/O bypasses buffer cacheFail if pathname is not a directoryWith O CREAT: create file exclusivelyUsed on 32-bit systems to open large filesDon’t update file last access time on read() (since Linux 2.6.8)Don’t let pathname become the controlling terminalv3v3v3v4v3Don’t dereference symbolic linksTruncate existing file to zero lengthWrites are always appended to end of fileGenerate a signal when I/O is possibleProvide synchronized I/O data integrity (since Linux 2.6.33)Open in nonblocking modeMake file writes synchronousv4v3v3O WRONLYO RDWRO CLOEXECO CREATO DIRECTO DIRECTORYO EXCLO LARGEFILEO NOATIMEO NOCTTYO NOFOLLOWO TRUNCO APPENDO ASYNCO DSYNCO NONBLOCKO SYNC74Chapter 4SUS?The Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpiv4v3v3v3v3v3
The constants in Table 4-3 are divided into the following groups:zzzFile access mode flags: These are the O RDONLY, O WRONLY, and O RDWR flags describedearlier. They can be retrieved using the fcntl() F GETFL operation (Section 5.3).File creation flags: These are the flags shown in the second part of Table 4-3.They control various aspects of the behavior of the open() call, as well asoptions for subsequent I/O operations. These flags can’t be retrieved orchanged.Open file status flags: These are the remaining flags in Table 4-3. They can beretrieved and modified using the fcntl() F GETFL and F SETFL operations (Section 5.3). These flags are sometimes simply called the file status flags.Since kernel 2.6.22, the Linux-specific files in the directory /proc/PID/fdinfocan be read to obtain information about the file descriptors of any process onthe system. There is one file in this directory for each of the process’s open filedescriptors, with a name that matches the number of the descriptor. The posfield in this file shows the current file offset (Section 4.7). The flags field is anoctal number that shows the file access mode flags and open file status flags.(To decode this number, we need to look at the numeric values of these flagsin the C library header files.)Details for the flags constants are as follows:O APPENDWrites are always appended to the end of the file. We discuss the significance of this flag in Section 5.1.O ASYNCGenerate a signal when I/O becomes possible on the file descriptorreturned by open(). This feature, termed signal-driven I/O, is available onlyfor certain file types, such as terminals, FIFOs, and sockets. (The O ASYNCflag is not specified in SUSv3; however, it, or the older synonym, FASYNC, isfound on most UNIX implementations.) On Linux, specifying the O ASYNCflag when calling open() has no effect. To enable signal-driven I/O, we mustinstead set this flag using the fcntl() F SETFL operation (Section 5.3). (Several other UNIX implementations behave similarly.) Refer to Section 63.3for more information about the O ASYNC flag.O CLOEXEC (since Linux 2.6.23)Enable the close-on-exec flag (FD CLOEXEC) for the new file descriptor. Wedescribe the FD CLOEXEC flag in Section 27.4. Using the O CLOEXEC flag allows aprogram to avoid additional fcntl() F SETFD and F SETFD operations to set theclose-on-exec flag. It is also necessary in multithreaded programs to avoidthe race conditions that could occur using the latter technique. Theseraces can occur when one thread opens a file descriptor and then tries tomark it close-on-exec at the same time as another thread does a fork() andthen an exec() of an arbitrary program. (Suppose that the second threadmanages to both fork() and exec() between the time the first thread opensthe file descriptor and uses fcntl() to set the close-on-exec flag.) Such racesThe Linux Programming Interface 2010 by Michael Kerriskhttp://www.nostarch.com/tlpiFi le I/O : The Uni versal I/O Model75
could result in open file descriptors being unintentionally passed to unsafeprograms. (We say more about race conditions in Section 5.1.)O CREATIf the file doesn’t already exist, it is created as a new, empty file. This flag iseffective even if the file is being opened only for reading. If we specifyO CREAT, then we must supply a mode argument in the open() call; otherwise,the permissions of the new file will be set to some random value from thestack.O DIRECTAllow file I/O to bypass the buffer cache. This feature is described in Section 13.6. The GNU SOURCE feature test macro must be defined in order tomake this constant definition available from fcntl.h .O DIRECTORYReturn an error (errno equals ENOTDIR) if pathname is not a directory. Thisflag is an extension designed specifically for implementing opendir() (Section 18.8). The GNU SOURCE feature test macro must be defined in order tomake this constant definition available from fcntl.h .O DSYNC (since Linux 2.6.33)Perform file writes according to the requirements of synchronized I/Odata integrity completion. See the discussion of kernel I/O buffering inSection 13.3.O EXCLThis flag is used in conjunction with O CREAT to indicate that if the filealready exists, it should not be opened; instead, open() should fail, witherrno set to EEXIST. In other words, this flag allows the caller to ensure that itis the process creating the file. The check for existence and the creation ofthe file are performed atomically. We discuss the concept of atomicity inSection 5.1. When both O CREAT and O EXCL are specified in flags, open() fails(with the error EEXIST) if pathname is a symbolic link. SUSv3 requires thisbehavior so that a privileged application can create a file in a known location without there being a possibility that a symbolic link would cause thefile to be created in a different location (e.g., a system directory), whichwould have security implications.O LARGEFILEOpen the file with large file support. This flag is used on 32-bit systems inorder to work with large files. Although it is not specified in SUSv3, theO LARGEFILE flag is found on several other UNIX implementations. On 64bit Linux implementations such as Alpha and IA-64, this flag has no effect.See Section 5.10 for more information.O NOATIME (since Linux 2.6.8)Don’t update the file last access time (the st a
The Linux Programming Interface is the definitive guide to the Linux and UNIX programming interface—the interface employed by nearly every application that runs on a Linux or UNIX system. In this authoritative work, Linux programm
May 02, 2018 · D. Program Evaluation ͟The organization has provided a description of the framework for how each program will be evaluated. The framework should include all the elements below: ͟The evaluation methods are cost-effective for the organization ͟Quantitative and qualitative data is being collected (at Basics tier, data collection must have begun)
Silat is a combative art of self-defense and survival rooted from Matay archipelago. It was traced at thé early of Langkasuka Kingdom (2nd century CE) till thé reign of Melaka (Malaysia) Sultanate era (13th century). Silat has now evolved to become part of social culture and tradition with thé appearance of a fine physical and spiritual .
On an exceptional basis, Member States may request UNESCO to provide thé candidates with access to thé platform so they can complète thé form by themselves. Thèse requests must be addressed to esd rize unesco. or by 15 A ril 2021 UNESCO will provide thé nomineewith accessto thé platform via their émail address.
̶The leading indicator of employee engagement is based on the quality of the relationship between employee and supervisor Empower your managers! ̶Help them understand the impact on the organization ̶Share important changes, plan options, tasks, and deadlines ̶Provide key messages and talking points ̶Prepare them to answer employee questions
Dr. Sunita Bharatwal** Dr. Pawan Garga*** Abstract Customer satisfaction is derived from thè functionalities and values, a product or Service can provide. The current study aims to segregate thè dimensions of ordine Service quality and gather insights on its impact on web shopping. The trends of purchases have
Linux in a Nutshell Linux Network Administrator’s Guide Linux Pocket Guide Linux Security Cookbook Linux Server Hacks Linux Server Security Running Linux SELinux Understanding Linux Network Internals Linux Books Resource Center linux.oreilly.comis a complete catalog of O’Reilly’s books on Linux and Unix and related technologies .
Chính Văn.- Còn đức Thế tôn thì tuệ giác cực kỳ trong sạch 8: hiện hành bất nhị 9, đạt đến vô tướng 10, đứng vào chỗ đứng của các đức Thế tôn 11, thể hiện tính bình đẳng của các Ngài, đến chỗ không còn chướng ngại 12, giáo pháp không thể khuynh đảo, tâm thức không bị cản trở, cái được
Other Linux resources from O’Reilly Related titles Building Embedded Linux Systems Linux Device Drivers Linux in a Nutshell Linux Pocket Guide Running Linux Understanding Linux Network Internals Understanding the Linux Kernel Linux Books Resource Center linu
