Serial Notes for Linux Programming Interface

Note:

These serial notes about Linux Programming Interface could not be wrote in Chinese for I can't install the Chinese input software on Linux properly, especially on Kali.

So I offer these information in English. Sorry for any inconvenience to your reading.

The term operating system is commonly used with two different meanings:

1.To denote the entire package consisting of the central software managing a computer’s resources and all of the accompanying standard software tools, such as command-line interpreters, graphical user interfaces, file utilities, and editors.

2.More narrowly, to refer to the central software that manages and allocates computer resources (i.e., the CPU, RAM, and devices).

The term kernel is often used as a synonym for the second meaning, and it is with this meaning of the term operating system that we are concerned in this book.

Kernel mode and user mode

Modern processor architectures typically allow the CPU to operate in at least two different modes: user mode and kernel mode (sometimes also referred to as supervisor mode).

Linux is capital sensitive but not windows.

Programs

Programs normally exist in two forms. The first form is source code, human-readable text consisting of a series of statements written in a programming language such

as C. To be executed, source code must be converted to the second form: binary machine-language instructions that the computer can understand. (This contrasts with a script, which is a text file containing commands to be directly processed by a program such
as a shell or other command interpreter.) The two meanings of the term program are normally considered synonymous, since the step of compiling and linking converts source code into semantically equivalent binary machine code.

File ownership

The st_uid and st_gid fields identify, respectively, the owner (user ID) and group (group ID) to which the file belongs.

Link count

The st_nlink field is the number of (hard) links to the file. We describe links in detail in Chapter 18.

File type and permissions

The bits of this field are laid out as shown in Figure 15-1.


File Timestamps

The st_atime, st_mtime, and st_ctime fields of the stat structure contain file timestamps. These fields record, respectively, the times of last file access, last file modification,

and last file status change (i.e., last change to the file’s i-node information). Time-stamps are recorded in seconds since the Epoch (1 January 1970; see Section 10.1).

Most native Linux and UNIX file systems support all of the timestamp fields, but some non-UNIX file systems may not.

Ownership of New Files

When a new file is created, its user ID is taken from the effective user ID of the process. The group ID of the new file may be taken from either the effective group ID of the process (equivalent to the System V default behavior) or the group ID of the parent
directory (the BSD behavior). The latter possibility is useful for creating project directories in which all files belong to a particular group and are accessible to the members of that group. Which of the two values is used as the new file’s group ID is determined
by various factors, including the type of file system on which the new file is created. We begin by describing the rules followed by ext2 and a few other file systems.

The use of chown() is demonstrated in Listing 15-2, a program that allows the user to change the owner and group of an arbitrary number of files, specified as command-line arguments. (This program uses the userIdFromName() and groupIdFromName() functions
from Listing 8-1, on page 159, to convert user and group names  into corresponding numeric IDs.)

The file permissions mask divides the world into three categories:

Owner (also known as user): The permissions granted to the owner of the file.

The term user is used by commands such as chmod(1), which uses the abbreviation u to refer to this permission category.

Group: The permissions granted to users who are members of the file’s group.

Other: The permissions granted to everyone else.

Three permissions may be granted to each user category:

Read: The contents of the file may be read.

Write: The contents of the file may be changed.

Execute: The file may be executed (i.e., it is a program or a script). In order to

execute a script file (e.g., a bash script), both read and execute permissions are

required.

The permissions and ownership of a file can be viewed using the command ls –l, as

in the following example:

$ ls -l myscript.sh

-rwxr-x--- 1 mtk users 1667 Jan 15 09:22 myscript.sh

Directories have the same permission scheme as files. However, the three permissions are interpreted differently:

Read: The contents (i.e., the list of filenames) of the directory may be listed (e.g., by ls).

If experimenting to verify the operation of the directory read permission bit, be aware that some Linux distributions alias the ls command to include flags (e.g., –F) that require access to i-node information for files in the directory, and this requires execute
permission on the directory. To ensure that we are using an unadulterated ls, we can specify the full pathname of the command ( /bin/ls ).

Write: Files may be created in and removed from the directory. Note that it is not necessary to have any permission on a file itself in order to be able to delete it.

Execute: Files within the directory may be accessed. Execute permission on a directory is sometimes called search permission.

#include <unistd.h>

int access(const char * pathname , int mode );

Returns 0 if all permissions are granted, otherwise –1





#include <dirent.h>

DIR *opendir(const char * dirpath );

Returns directory stream handle, or NULL on error

#include <dirent.h>

DIR *fdopendir(int fd );

Returns directory stream handle, or NULL on error

#include <dirent.h>

struct dirent *readdir(DIR * dirp );

Returns pointer to a statically allocated structure describing next directory entry, or NULL on end-of-directory or error

We have omitted various nonstandard fields in the Linux dirent structure from the above definition, since their use renders an application nonportable. The most interesting of these nonstandard fields is d_type, which is also present on BSD derivatives,
but not on other UNIX implementations. This field holds a value indicating the type of the file named in d_name, such as DT_REG (regular file), DT_DIR (directory), DT_LNK (symbolic link), or DT_FIFO (FIFO). (These names are analogous to the macros in Table
15-1, on page 282.) Using the information in this field saves the cost of calling lstat() in order to discover the file type. Note, however, that, at the time of writing, this field is fully supported only on Btrfs, ext2, ext3, and ext4.

File Tree Walking: nftw()

The nftw() function allows a program to recursively walk through an entire directory subtree performing some operation (i.e., calling some programmer-defined function) for each file in the subtree.

The nftw() function is an enhancement of the older ftw() function, which performs a similar task. New applications should use nftw() (new ftw) because it provides more functionality, and predictable handling of symbolic links (SUSv3 permits ftw() either
to follow or not follow symbolic links). SUSv3 specifies both nftw() and ftw(), but the latter function is marked obsolete in SUSv4.

The GNU C library also provides the BSD-derived fts API (fts_open(), fts_read(), fts_children(), fts_set(), and fts_close()). These functions perform a similar task to ftw() and nftw(), but offer greater flexibility to an application walking the tree. However,
this API is not standardized and is provided on few UNIX implementations other than BSD descendants, so we omit discussion of it here.

The nftw() function walks through the directory tree specified by dirpath and calls the programmer-defined function func once for each file in the directory tree.

#define _XOPEN_SOURCE 500

#include <ftw.h>

int nftw(const char * dirpath ,

int (* func ) (const char * pathname , const struct stat * statbuf , int typeflag , struct FTW * ftwbuf ), int nopenfd , int flags );

Returns 0 after successful walk of entire tree, or –1 on error, or the first nonzero value returned by a call to func

FTW_CHDIR

Do a chdir() into each directory before processing its contents. This is useful if func is designed to do some work in the directory in which the file specified by its pathname argument resides.

FTW_DEPTH

Do a postorder traversal of the directory tree. This means that nftw() calls func on all of the files (and subdirectories) within a directory before executing func on the directory itself. (The name of this flag is somewhat misleading—nftw() always does a depth-first,
rather than a breadth-first, traversal of the directory tree. All that this flag does is convert the traversal from preorder to postorder.)

FTW_MOUNT

Don’t cross over into another file system. Thus, if one of the subdirectories of the tree is a mount point, it is not traversed.

FTW_PHYS

By default, nftw() dereferences symbolic links. This flag tells it not to do so. Instead, a symbolic link is passed to func with a typeflag value of FTW_SL , as described below.