Download Notes to he followed and more Lecture notes Information Systems in PDF only on Docsity!
R N S INSTITUTE OF TECHNOLOGY
CHANNASANDRA, BANGALORE - 98
UNIX SYSTEM PROGRAMMING
NOTES FOR 6TH^ SEMESTER INFORMATION SCIENCE
SUBJECT CODE: 10CS
PREPARED BY
RAJKUMAR
Assistant Professor
Department of Information Science
DIVYA K
1RN09IS
Information Science and Engineering
Divya.1rn09is016@gmail.com
Text Books: 1 Terrence Chan: Unix System Programming Using C++, Prentice Hall India, 1999.
2 W. Richard Stevens, Stephen A. Rago: Advanced Programming in the UNIX Environment, 2nd Edition, Pearson Education / PHI, 2005 Notes have been circulated on self risk nobody can be held responsible if anything is wrong or is improper information or insufficient information provided in it.
Contents: UNIT 1, UNIT 2, UNIT 3, UNIT 4, UNIT 5, UNIT 6, UNIT 7
Powered By:
www.vtuplanet.com
UNIT 1
INTRODUCTION
UNIX AND ANSI STANDARDS
UNIX is a computer operating system originally developed in 1969 by a group of AT&T employees at Bell Labs, including Ken Thompson, Dennis Ritchie, Douglas McElroy and Joe Ossanna. Today UNIX systems are split into various branches, developed over time by AT&T as well as various commercial vendors and non-profit organizations.
The ANSI C Standard
In 1989, American National Standard Institute (ANSI) proposed C programming language standard X3.159-1989 to standardise the language constructs and libraries. This is termed as ANSI C standard. This attempt to unify the implementation of the C language supported on all computer system. The major differences between ANSI C and K&R C [Kernighan and Ritchie] are as follows: Function prototyping Support of the const and volatile data type qualifiers. Support wide characters and internationalization. Permit function pointers to be used without dereferencing. Function prototyping ANSI C adopts C++ function prototype technique where function definition and declaration include function names, arguments’ data types, and return value data types. This enables ANSI C compilers to check for function calls in user programs that pass invalid number of arguments or incompatible arguments’ data type. These fix a major weakness of K&R C compilers: invalid function calls in user programs often pass compilation but cause programs to crash when they are executed. Eg: unsigned long foo(char * fmt, double data) { /body of foo/ }**
External declaration of this function foo is unsigned long foo(char * fmt, double data);
eg: int printf(const char fmt,...........);*
specify variable number of arguments
Support of the const and volatile data type qualifiers.
The const keyword declares that some data cannot be changed. Eg: int printf(const char fmt,...........);* Declares a fmt argument that is of a const char * data type, meaning that the function printf cannot modify data in any character array that is passed as an actual argument value to fmt. Volatile keyword specifies that the values of some variables may change asynchronously, giving an hint to the compiler’s optimization algorithm not to remove any “redundant” statements that involve “volatile” objects. eg : char get_io() { volatile char io_port = 0x7777; char ch = io_port; /read first byte of data/ ch = io_port; /read second byte of data/ }*
If io_port variable is not declared to be volatile when the program is compiled, the compiler may eliminate second ch = *io_port statement, as it is considered redundant with respect to the previous statement.
Finally, ANSI C defines a set of standard library function & associated headers. These headers are the subset of the C libraries available on most system that implement K&R C.
The ANSI/ISO C++ Standard
These compilers support C++ classes, derived classes, virtual functions, operator overloading. Furthermore, they
should also support template classes, template functions, exception handling and the iostream library classes.
Differences between ANSI C and C++
ANSI C C++
Uses K&R C default function declaration for any functions that are referred before their declaration in the program.
Requires that all functions must be declared / defined before they can be referenced.
int foo(); ANSI C treats this as old C function declaration & interprets it as declared in following manner. int foo(........); meaning that foo may be called with any number of arguments.
int foo(); C++ treats this as int foo(void); Meaning that foo may not accept any arguments.
Does not employ type_safe linkage technique and does not catch user errors.
Encrypts external function names for type_safe linkage. Thus reports any user errors.
The POSIX standards
POSIX or “Portable Operating System Interface” is the name of a family of related standards specified by the IEEE to define the application-programming interface (API), along with shell and utilities interface for the software compatible with variants of the UNIX operating system. Because many versions of UNIX exist today and each of them provides its own set of API functions, it is difficult for system developers to create applications that can be easily ported to different versions of UNIX. Some of the subgroups of POSIX are POSIX.1, POSIX.1b & POSIX.1c are concerned with the development of set of standards for system developers. POSIX. This committee proposes a standard for a base operating system API; this standard specifies APIs for the manipulating of files and processes. It is formally known as IEEE standard 1003.1-1990 and it was also adopted by the ISO as the international standard ISO/IEC 9945:1:1990. POSIX.1b This committee proposes a set of standard APIs for a real time OS interface; these include IPC (inter- process communication). This standard is formally known as IEEE standard 1003.4-1993. POSIX.1c This standard specifies multi-threaded programming interface. This is the newest POSIX standard. These standards are proposed for a generic OS that is not necessarily be UNIX system. E.g.: VMS from Digital Equipment Corporation, OS/2 from IBM, & Windows NT from Microsoft Corporation are POSIX-compliant, yet they are not UNIX systems. To ensure a user program conforms to POSIX.1 standard, the user should either define the manifested constant _POSIX_SOURCE at the beginning of each source module of the program (before inclusion of any header) as; #define _POSIX_SOURCE Or specify the -D_POSIX_SOURCE option to a C++ compiler (CC) in a compilation; *% CC -D_POSIX_SOURCE .C POSIX.1b defines different manifested constant to check conformance of user program to that standard. The new macro is _POSIX_C_SOURCE and its value indicates POSIX version to which a user program conforms. Its value can be:
_POSIX_C_SOURCE VALUES MEANING
198808L First version of POSIX.1 compliance
199009L Second version of POSIX.1 compliance
199309L POSIX.1 and POSIX.1b compliance
_POSIX_C_SOURCE may be used in place of _POSIX_SOURCE. However, some systems that support POSIX.1 only may not accept the _POSIX_C_SOURCE definition. There is also a _POSIX_VERSION constant defined in <unistd.h> header. It contains the POSIX version to which the system conforms.
Program to check and display _POSIX_VERSION constant of the system on which it is run
#define _POSIX_SOURCE #define _POSIX_C_SOURCE 199309L #include<iostream.h> #include<unistd.h> int main() { #ifdef _POSIX_VERSION cout<<“System conforms to POSIX”<<“_POSIX_VERSION<<endl; #else cout<<“_POSIX_VERSION undefined\n”; #endif return 0; }
The POSIX Environment
Although POSIX was developed on UNIX, a POSIX complaint system is not necessarily a UNIX system. A few UNIX conventions have different meanings according to the POSIX standards. Most C and C++ header files are stored under the /usr/include directory in any UNIX system and each of them is referenced by
#include<header-file-name>
This method is adopted in POSIX. There need not be a physical file of that name existing on a POSIX conforming system.
The POSIX Feature Test Macros
POSIX.1 defines a set of feature test macro’s which if defined on a system, means that the system has implemented the corresponding features. All these test macros are defined in <unistd.h> header.
Feature test macro Effects if defined
_POSIX_JOB_CONTROL The system supports the BSD style job control.
_POSIX_SAVED_IDS Each process running on the system keeps the saved set UID and the set- GID, so that they can change its effective user-ID and group-ID to those values via seteuid and setegid API's.
_POSIX_CHOWN_RESTRICTED If the defined value is - 1, users may change ownership of files owned by them, otherwise only users with special privilege may change ownership of any file on the system.
_POSIX_NO_TRUNC If the defined value is -1, any long pathname passed to an API is silently truncated to NAME_MAX bytes, otherwise error is generated.
_POSIX_VDISABLE If defined value is - 1, there is no disabling character for special characters for all terminal device files. Otherwise the value is the disabling character value.
simultaneously. _POSIX_ARG_MAX 4096 Maximum size, in bytes of arguments that may be passed to an exec function. _POSIX_NGROUP_MAX 0 Maximum number of supplemental groups to which a process may belong _POSIX_PATH_MAX 255 Maximum number of characters allowed in a path name
_POSIX_NAME_MAX 14 Maximum number of characters allowed in a file name _POSIX_LINK_MAX 8 Maximum number of links a file may have _POSIX_PIPE_BUF 512 Maximum size of a block of data that may be atomically read from or written to a pipe _POSIX_MAX_INPUT 255 Maximum capacity of a terminal’s input queue (bytes)
_POSIX_MAX_CANON 255 Maximum size of a terminal’s canonical input queue _POSIX_SSIZE_MAX 32767 Maximum value that can be stored in a ssize_t-typed object
_POSIX_TZNAME_MAX 3 Maximum number of characters in a time zone name
The following is a list of POSIX.1b – defined constants:
Compile time limit Min. Value Meaning
_POSIX_AIO_MAX 1 Number of simultaneous asynchronous I/O.
_POSIX_AIO_LISTIO_MAX 2 Maximum number of operations in one listio.
_POSIX_TIMER_MAX 32 Maximum number of timers that can be used simultaneously by a process.
_POSIX_DELAYTIMER_MAX 32 Maximum number of overruns allowed per timer.
_POSIX_MQ_OPEN_MAX 2 Maximum number of message queues that may be accessed simultaneously per process
_POSIX_MQ_PRIO_MAX 2 Maximum number of message priorities that can be assigned to the messages
_POSIX_RTSIG_MAX 8 Maximum number of real time signals.
_POSIX_SIGQUEUE_MAX 32 Maximum number of real time signals that a process may queue at any time.
_POSIX_SEM_NSEMS_MAX 256 Maximum number of semaphores that may be used simultaneously per process.
_POSIX_SEM_VALUE_MAX 32767 Maximum value that may be assigned to a semaphore.
Prototypes:
#include<unistd.h>
*long sysconf(const int limit_name); long pathconf(const char pathname, int flimit_name); long fpathconf(const int fd, int flimit_name);
The limit_name argument value is a manifested constant as defined in the <unistd.h> header. The possible values
and the corresponding data returned by the sysconf function are:
Limit value Sysconf return data
_SC ___ ARG_MAX Maximum size of argument values (in bytes) that may be passed to an exec API call _SC_CHILD_MAX Maximum number of child processes that may be owned by a process simultaneously _SC_OPEN_MAX Maximum number of opened files per process
_SC_NGROUPS_MAX Maximum number of supplemental groups per process
_SC_CLK_TCK The number of clock ticks per second
_SC_JOB_CONTROL The _POSIX_JOB_CONTROL value
_SC_SAVED_IDS The _POSIX_SAVED_IDS value
_SC_VERSION The _POSIX_VERSION value
___ SC_TIMERS The _POSIX_TIMERS value
_SC_DELAYTIMERS_MAX Maximum number of overruns allowed per timer
_SC_RTSIG_MAX Maximum number of real time signals.
_SC_MQ_OPEN_MAX Maximum number of messages queues per process.
_SC_MQ_PRIO_MAX Maximum priority value assignable to a message
_SC_SEM_MSEMS_MAX Maximum number of semaphores per process
_SC_SEM_VALUE_MAX Maximum value assignable to a semaphore.
_SC_SIGQUEUE_MAX Maximum number of real time signals that a process may queue at any one time
_SC_AIO_LISTIO_MAX Maximum number of operations in one listio.
_SC_AIO_MAX Number of simultaneous asynchronous I/O.
All constants used as a sysconf argument value have the _SC prefix. Similarly the flimit_name argument value is a
manifested constant defined by the <unistd.h> header. These constants all have the PC prefix.
Following is the list of some of the constants and their corresponding return values from either pathconf or
fpathconf functions for a named file object.
Limit value Pathconf return data
_PC_CHOWN_RESTRICTED The _POSIX_CHOWN_RESTRICTED value
_PC_NO_TRUNC Returns the _POSIX_NO_TRUNC value
_PC_VDISABLE Returns the _POSIX_VDISABLE value _PC_PATH_MAX Maximum length of a pathname (in bytes)
_PC_NAME_MAX Maximum length of a filename (in bytes)
_PC_LINK_MAX Maximum number of links a file may have _PC_PIPE_BUF Maximum size of a block of data that may be read from or written to a pipe
_PC_MAX_CANON maximum size of a terminal’s canonical input queue
_PC_MAX_INPUT Maximum capacity of a terminal’s input queue.
These variables may be used at compile time, such as the following:
char pathname [ _POSIX_PATH_MAX + 1 ]; for (int i=0; i < _POSIX_OPEN_MAX; i++) close(i); //close all file descriptors
The following test_config.C illustrates the use of sysconf, pathcong and fpathconf:
#define _POSIX_SOURCE #define _POSIX_C_SOURCE 199309L #include<stdio.h> #include<iostream.h> #include<unistd.h>
int main() { int res; if((res=sysconf(_SC_OPEN_MAX))==-1) perror(“sysconf”); else cout<<”OPEN_MAX:”<<res<<endl;
Some commonly used POSIX.1 and UNIX API’s are declared in <unistd.h> header. Most of POSIX.1, POSIX>1b and UNIX API object code is stored in the libc.a and lib.so libraries.
API Common Characteristics
Many APIs returns an integer value which indicates the termination status of their execution API return -1 to indicate the execution has failed , and the global variable errno is set with an error code. a user process may call perror function to print a diagnostic message of the failure to the std o/p, or it may call strerror function and gives it errno as the actual argument value; the strerror function returns a diagnostic message string and the user process may print that message in its preferred way the possible error status codes that may be assigned to errno by any API are defined in the <errno.h> header.
Following is a list of commonly occur error status codes and their meanings:
Error status code Meaning
EACCESS A process does not have access permission to perform an operation via a API. EPERM A API was aborted because the calling process does not have the superuser privilege.
ENOENT An invalid filename was specified to an API. BADF A API was called with invalid file descriptor.
EINTR A API execution was aborted due to a signal interruption EAGAIN A API was aborted because some system resource it requested was temporarily unavailable. The API should be called again later.
ENOMEM A API was aborted because it could not allocate dynamic memory. EIO I/O error occurred in a API execution.
EPIPE A API attempted to write data to a pipe which has no reader. EFAULT A API was passed an invalid address in one of its argument.
ENOEXEC A API could not execute a program via one of the exec API ECHILD A process does not have any child process which it can wait on.
UNIT 2
UNIX FILES
Files are the building blocks of any operating system. When you execute a command in UNIX, the UNIX kernel fetches the corresponding executable file from a file system, loads its instruction text to memory, and creates a process to execute the command on your behalf. In the course of execution, a process may read from or write to files. All these operations involve files. Thus, the design of an operating system always begins with an efficient file management system.
File Types
A file in a UNIX or POSIX system may be one of the following types:
regular file directory file FIFO file Character device file Block device file
Regular file A regular file may be either a text file or a binary file These files may be read or written to by users with the appropriate access permission Regular files may be created, browsed through and modified by various means such as text editors or compilers, and they can be removed by specific system commands Directory file It is like a folder that contains other files, including sub-directory files. It provides a means for users to organise their files into some hierarchical structure based on file relationship or uses. Ex: /bin directory contains all system executable programs, such as cat, rm, sort A directory may be created in UNIX by the mkdir command o Ex: mkdir /usr/foo/xyz A directory may be removed via the rmdir command o Ex: rmdir /usr/foo/xyz The content of directory may be displayed by the ls command Device file
Block device file Character device file It represents a physical device that transmits data a block at a time.
It represents a physical device that transmits data in a character-based manner. Ex: hard disk drives and floppy disk drives Ex: line printers, modems, and consoles
A physical device may have both block and character device files representing it for different access methods. An application program may perform read and write operations on a device file and the OS will automatically invoke an appropriate device driver function to perform the actual data transfer between the physical device and the application An application program in turn may choose to transfer data by either a character-based(via character device file) or block-based(via block device file) A device file is created in UNIX via the mknod command o Ex: mknod /dev/cdsk c 115 5
Here , c - character device file 115 - major device number 5 - minor device number
The following files are commonly defined in most UNIX systems FILE (^) Use
/etc Stores system administrative files and programs
/etc/passwd Stores all user information’s
/etc/shadow Stores user passwords
/etc/group Stores all group information
/bin Stores all the system programs like cat, rm, cp,etc.
/dev Stores all character device and block device files
/usr/include Stores all standard header files.
/usr/lib Stores standard libraries
/tmp Stores temporary files created by program
The UNIX and POSIX File Attributes
The general file attributes for each file in a file system are:
- File type - specifies what type of file it is.
- Access permission - the file access permission for owner, group and others.
- Hard link count - number of hard link of the file
- Uid - the file owner user id.
- Gid - the file group id.
- File size - the file size in bytes.
- Inode no - the system inode no of the file.
- File system id - the file system id where the file is stored.
- Last access time - the time, the file was last accessed.
- Last modified time - the file, the file was last modified.
- Last change time - the time, the file was last changed.
In addition to the above attributes, UNIX systems also store the major and minor device numbers for each device file. All the above attributes are assigned by the kernel to a file when it is created. The attributes that are constant for any file are:
File type File inode number File system ID Major and minor device number
The other attributes are changed by the following UNIX commands or system calls
Unix Command
System Call
Attributes changed
chmod chmod Changes access permission, last change time chown chown Changes UID, last change time
chgrp chown Changes GID, ast change time touch utime Changes last access time, modification time ln link Increases hard link count
rm unlink Decreases hard link count. If the hard link count is zero, the file will be removed from the file system
vi, emac Changes the file size, last access time, last modification time
Inodes in UNIX System V
In UNIX system V, a file system has an inode table, which keeps tracks of all files. Each entry of the inode table is an inode record which contains all the attributes of a file, including inode # and the physical disk address where data of the file is stored For any operation, if a kernel needs to access information of a file with an inode # 15, it will scan the inode table to find an entry, which contains an inode # 15 in order to access the necessary data. An inode # is unique within a file system. A file inode record is identified by a file system ID and an inode #. Generally an OS does not keep the name of a file in its record, because the mapping of the filenames to inode# is done via directory files i.e. a directory file contains a list of names of their respective inode # for all file stored in that directory. Ex: a sample directory file content Inode number File name 115 89 .. 201 xyz 346 a.out 201 xyz_ln To access a file, for example /usr/divya, the UNIX kernel always knows the “/” (root) directory inode # of any process. It will scan the “/” directory file to find the inode number of the usr file. Once it gets the usr file inode #, it accesses the contents of usr file. It then looks for the inode # of divya file. Whenever a new file is created in a directory, the UNIX kernel allocates a new entry in the inode table to store the information of the new file It will assign a unique inode # to the file and add the new file name and inode # to the directory file that contains it.
Application Program Interface to Files
The general interfaces to the files on UNIX and POSIX system are Files are identified by pathnames. Files should be created before they can be used. The various commands and system calls to create files are listed below. File type commands system call Regular file vi,pico,emac open,creat Directory file mkdir mkdir,mknod FIFO file mkfifo mkfifo,mknod Device file mknod mknod Symbolic link file ln – s symlink For any application to access files, first it should be opened, generally we use open system call to open a file, and the returned value is an integer which is termed as file descriptor. There are certain limits of a process to open files. A maximum number of OPEN-MAX files can be opened .The value is defined in <limits.h> header The data transfer function on any opened file is carried out by read and write system call. File hard links can be increased by link system call, and decreased by unlink system call. File attributes can be changed by chown , chmod and link system calls. File attributes can be queried (found out or retrieved) by stat and fstat system call. UNIX and POSIX.1 defines a structure of data type stat i.e. defined in <sys/stat.h> header file. This contains the user accessible attribute of a file. The definition of the structure can differ among implementation, but it could look like struct stat { dev_t st_dev; /* file system ID / ino_t st_ino; / file inode number / mode_t st_ mode; / contains file type and permission / nlink_t st_nlink; / hard link count / uid_t st_uid; / file user ID / gid_t st_gid; / file group ID */
descriptor). Whenever the process wants to read or write data from the file, it should use the file descriptor as one of its argument.
The following events will occur whenever a process calls the close function to close the files that are opened.
- The kernel sets the corresponding file descriptor table entry to be unused.
- It decrements the rc in the corresponding file table entry by 1, if rc not equal to 0 go to step 6.
- The file table entry is marked as unused.
- The rc in the corresponding file inode table entry is decremented by 1, if rc value not equal to 0 go to step 6.
- If the hard link count of the inode is not zero, it returns to the caller with a success status otherwise it marks the inode table entry as unused and de-allocates all the physical dusk storage of the file.
- It returns to the process with a 0 (success) status.
Relationship of C Stream Pointers and File Descriptors
The major difference between the stream pointer and the file descriptors are as follows:
The file descriptor associated with a stream pointer can be extracted by fileno macro, which is declared in the
<stdio.h> header.
int fileno ( **FILE *** stream_pointer);
To convert a file descriptor to a stream pointer, we can use fdopen C library function
FILE _fdopen_* ( int file_descriptor, **char *** open_mode);
The following lists some C library functions and the underlying UNIX APIs theyuse to perform their functions:
C library function UNIX system call used fopen open fread, fgetc, fscanf, fgets read fwrite, fputc, fprintf, fputs write fseek, fputc, fprintf, fputs lseek fclose close
Directory Files
It is a record-oriented file Each record contains the information of a file residing in that directory The record data type is struct dirent in UNIX System V and POSIX.1 and struct direct in BSD UNIX. The record content is implementation-dependent They all contain 2 essential member fields o File name
o Inode number Usage is to map file names to corresponding inode number Directory function Purpose opendir Opens a directory file readdir Reads next record from the file closedir Closes a directory file rewinddir Sets file pointer to beginning of file
Hard and Symbolic Links
A hard link is a UNIX pathname for a file. Generally most of the UNIX files will be having only one hard link. In order to create a hard link, we use the command ln. Example : Consider a file /usr/ divya/old, to this we can create a hard link by ln /usr/ divya/old /usr/ divya/new after this we can refer the file by either /usr/ divya/old or /usr/ divya/new Symbolic link can be creates by the same command ln but with option – s Example: ln – s /usr/divya/old /usr/divya/new ln command differs from the cp (copy) command in that cp creates a duplicated copy of a file to another file with a different pathname, whereas ln command creates a new directory to reference a file. Let’s visualize the content of a directory file after the execution of command ln. Case 1: for hardlink file ln /usr/divya/abc /usr/raj/xyz The content of the directory files /usr/divya and /usr/raj are
Both /urs/divya/abc and /usr/raj/xyz refer to the same inode number 201, thus type is no new file created.
Case 2: For the same operation, if ln – s command is used then a new inode will be created.
ln – s /usr/divya/abc /usr/raj/xyz
The content of the directory files divya and raj will be
If cp command was used then the data contents will be identical and the 2 files will be separate objects in the file system, whereas in ln – s the data will contain only the path name.
Limitations of hard link:
- User cannot create hard links for directories, unless he has super-user privileges.
- User cannot create hard link on a file system that references files on a different file system, because inode number is unique to a file system.
Differences between hard link and symbolic link are listed below:
UNIT 3
UNIX FILE APIs
General file API’s
Files in a UNIX and POSIX system may be any one of the following types: Regular file Directory File FIFO file Block device file character device file Symbolic link file. There are special API’s to create these types of files. There is a set of Generic API’s that can be used to manipulate and create more than one type of files. These API’s are:
open This is used to establish a connection between a process and a file i.e. it is used to open an existing file for data transfer function or else it may be also be used to create a new file. The returned value of the open system call is the file descriptor (row number of the file table), which contains the inode information. The prototype of open function is #include<sys/types.h> #include<sys/fcntl.h> int open ( **const char *** pathname, int accessmode, mode_t permission);
If successful, open returns a nonnegative integer representing the open file descriptor. If unsuccessful, open returns – 1. The first argument is the name of the file to be created or opened. This may be an absolute pathname or relative pathname. If the given pathname is symbolic link, the open function will resolve the symbolic link reference to a non symbolic link file to which it refers. The second argument is access modes, which is an integer value that specifies how actually the file should be accessed by the calling process. Generally the access modes are specified in <fcntl.h>. Various access modes are: O_RDONLY - open for reading file only O_WRONLY - open for writing file only O_RDWR - opens for reading and writing file.
There are other access modes, which are termed as access modifier flags, and one or more of the following can be specified by bitwise-ORing them with one of the above access mode flags to alter the access mechanism of the file.
O_APPEND - Append data to the end of file. O_CREAT - Create the file if it doesn’t exist O_EXCL - Generate an error if O_CREAT is also specified and the file already exists. O_TRUNC - If file exists discard the file content and set the file size to zero bytes. O_NONBLOCK - Specify subsequent read or write on the file should be non-blocking. O_NOCTTY - Specify not to use terminal device file as the calling process control terminal.
To illustrate the use of the above flags, the following example statement opens a file called /usr/divya/usp for read and write in append mode: int fd=open(“/usr/divya/usp”,O_RDWR | O_APPEND,0); If the file is opened in read only, then no other modifier flags can be used. If a file is opened in write only or read write, then we are allowed to use any modifier flags along with them. The third argument is used only when a new file is being created. The symbolic names for file permission are given in the table in the previous page.
creat This system call is used to create new regular files. The prototype of creat is #include <sys/types.h> #include<unistd.h> int creat ( **const char *** pathname, mode_t mode);
Returns: file descriptor opened for write-only if OK, -1 on error. The first argument pathname specifies name of the file to be created. The second argument mode_t, specifies permission of a file to be accessed by owner group and others. The creat function can be implemented using open function as: #define creat(path_name, mode) open (pathname, O_WRONLY | O_CREAT | O_TRUNC, mode);
read The read function fetches a fixed size of block of data from a file referenced by a given file descriptor. The prototype of read function is: #include<sys/types.h> #include<unistd.h> size_t read ( int fdesc, **void *** buf, size_t nbyte);
If successful, read returns the number of bytes actually read. If unsuccessful, read returns – 1. The first argument is an integer, fdesc that refers to an opened file. The second argument, buf is the address of a buffer holding any data read. The third argument specifies how many bytes of data are to be read from the file. The size_t data type is defined in the <sys/types.h> header and should be the same as unsigned int. There are several cases in which the number of bytes actually read is less than the amount requested: o When reading from a regular file, if the end of file is reached before the requested number of bytes has been read. For example, if 30 bytes remain until the end of file and we try to read 100 bytes, read returns 30. The next time we call read, it will return 0 (end of file). o When reading from a terminal device. Normally, up to one line is read at a time. o When reading from a network. Buffering within the network may cause less than the requested amount to be returned. o When reading from a pipe or FIFO. If the pipe contains fewer bytes than requested, read will return only what is available.
write The write system call is used to write data into a file. The write function puts data to a file in the form of fixed block size referred by a given file descriptor.
