How to run a shell program

1
PIPES
2
Introduction

• We can think of pipes as a special file that can
  store a limited amount of data in a
  first-in-first-out (FIFO) manner
• The include file ltlimits.hgt or ltsys/param.hgt
  contains a defined constant PIPE_BUF that
  specifies the maximum number of bytes a pipe may
  hold
• One process will write to the pipe (as if it were
  a file), while another process will read from the
  pipe
• The system provides the synchronization between
  writing and reading processes

3
Introduction (continue.)

• By default, if a writing process attempts to
  write to a full pipe, the system will
  automatically block the process until the pipe is
  able to receive the data
• Likewise, if a read is attempted on an empty
  pipe, the process will block until data is
  available
• In addition, the process will block if a
  specified pipe has been opened for reading, but
  another process has not opened the pipe for
  writing
• Data is written to the pipe using the unbuffered
  I/O write system call

4
write system call
5
Introduction (continue.)

• writes to a pipe are similar to those for a file
  except that
• Each file write request is always appended to the
  end of the pipe
• Write requests of PIPE_BUF size or less are
  guaranteed not to be interleaved with other write
  requests to the same pipe
• When the O_NONOCK and O_NDELAY flags are clear a
  write request may cause the process to block. The
  defined constants O_NONOCK and O_NDELAY are found
  in the header file ltsys/fcntl.hgt and can be set
  with the fcntl system call. By default, these
  values are considered to be cleared, thus rite
  will block if

6
Introduction (continue.)

• these is busy and writes will be delayed (written
  to an internal buffer which is written out to
  disk by the kernel at a later time as). Once the
  write has completed it will return the number of
  bytes successfully written
• When the O_NONOCK and O_NDELAY flags are set, and
  the request to write PIPE_BUF bytes or less is
  not successful, the value returned by the write
  system call can be summarized as

7
Introduction (continue.)

• If both O_NONBLOCK and O_NDELAY flags are set,
  write will be not block the process
• If a write is made to a pipe that is not open
  for reading by any process, a SIGPIPE signal will
  be generated and the value and the value in errno
  will be set to EPIPE (broken pipe). The default
  action (if not caught) for the SIGPIPE signal is
  termination

8
read system call
9
Introduction (continue.)

• In other aspects, reads performed on a pipe are
  similar to those on a file except that
• All reads are initiated from the current position
  (i.e., no seeking is performed)
• If both O_NONBLOCK and O_NDELAY flags are clear,
  then a read system call will block (by default)
  until data is written to the pipe or the pipe is
  closed
• If the pipe is open for writing by another
  process, but the pipe is empty, then a read (in
  combination with the flags O_NDELAY and
  O_NONBLOCK) will return the values

10
Introduction (continue.)

• If the pipe is not opened for writing by another
  process, read will return a 0 (indicating the
  end-of-file condition). Note that this is the
  same value that is returned when the O_NDELAY
  flag has been set and the pipe is open but empty

11
Unnamed Pipes

• An unnamed pipe is constructed with the pipe
  system call

12
pipe system call
13
Unnamed Pipes (continue.)

• If successful, the pipe system call will return
  two integer file descriptors, filedes0 and
  filedes1
• The file descriptors reference two data streams
• In current versions of UNIX the file descriptors
  returned by pipe are full duplex (bi-directional)
  and are both opened for reading/writing
• In a full duplex setting if the process writes to
  filedes0 then filedes1 is used for reading,
  otherwise the process writes to filedes1 and
  filedes0 is used for reading

14
Unnamed Pipes (continue.)

• In a half duplex setting filedes1 is always
  used for writing and filedes0 for reading an
  attempt to write to filedes0 will produce an
  error (i.e., bad file descriptor)
• Data in a pipe is read on a first-in-first-out
  basis
• To view how to use pipe to send data from a
  parent to a child, click here

a.out this_is_a_message Message received by
child this_is_a_message Message sent by parent
this_is_a_message
15
Unnamed Pipes (continue.)

• While the closing of the unused pipe file
  descriptors is not required, it is a good
  practice
• The dup system call duplicates an original open
  file descriptor
• The new descriptor, fildes, references the system
  file table entry for the next available
  non-negative file descriptor.
• The new descriptor will
• Share the same file pointer(offset)
• Have the same access mode as the original and
• Will be set to remain open across an exec call

16
dup system call
17
Unnamed Pipes (continue.)

• A code sequence of
• int f_des2
• pipe(f_des)
• close( fileno(stdo) )
• dup(f_des1)
• .
• .
• .
• declares and generates a pipe
• the file descriptor for standard output is closed
• the following dup system call would return the
  next lowest available file descriptor, which in
  this case should be the previously closed
  standard output file descriptor (i.e. 1)

18
Unnamed Pipes (continue.)

• Any data written to standard output in following
  statements would be now written to the pipe
• As there are two steps to this process, there is
  an outside chance that the sequence will be
  interrupted and the descriptor returned by dup
  will not be the one that was just closed

19
dup2 system call
20
Unnamed Pipes (continue.)

• The dup2 library function will close and
  duplicate the file descriptor as a single atomic
  action
• When dup2 is called, the file descriptor
  referenced by fildes will be a duplicate off the
  file descriptor referenced by fildes2
• If the referenced by fildes2 is open, it will be
  closed before the duplication is performed
• To view a lastsort command pipeline, click here

21
Unnamed Pipes (continue.)

• To summarize, the steps involved for
  communication via unnamed pipes are
• Create the pipe(s) needed
• Generate the process(es)
• Close/duplicate the file descriptors to properly
  associate the ends of the pipe
• Close the unneeded ends of the pipe
• Perform the communication activities
• Close any remaining open file descriptors
• If appropriate, wait for child processes to
  terminate

22
popen system call
23
close system call
24
Unnamed Pipes (continue.)

• When successful, the popen call returns a pointer
  to a file
• The arguments for popen are a pointer to the
  shell command that will be executed and an I/O
  mode type determines how the process will handle
  the file pointer returned by the popen call
• When popen is invoked, it will
• Generate a child process
• The child process execs a Bourne shell, which
  will execute the shell command passed to it
• Input to, and output from, the child process is
  accomplished via a pipe

25
Unnamed Pipes (continue.)

• If the I/O mode type for popen is specified as
  w, the parent process can write to the standard
  input of the shell command
• If the I/O type is r, using the popen file
  pointer, the parent process can read from the
  standard shell command (run by the child process)
• The pclose call is used to close a data stream
  opened with a popen call
• To view how to use the popen and pclose, click
  here

26
Named Pipes

• UNIX provides for a second type of pipe called a
  named pipe or FIFO
• Named pipe have a directory entry
• Unrelated processes can use the pipe file
• Named pipes can be created
• At the shell level, or
• Within a program

27
Named Pipes at the shell level

• mknod is a utility command designed to generate a
  special files
• The syntax for the mknod command is
• mknod PIPE p
• PIPE name for the FIFO
• p notifies that a FIFO file is to be created
• The default file permissions for a FIFO are
  assigned using the standard umask arrangement
• As soon as all the processes that are using a
  named pipe are done with, it file reverts to 0

28
Named Pipes at the programming level

• The system call to generate a FIFO in a program
  has the same name as the system command
  equivalent, i.e., mknod

29
mknod system call
30
Named Pipes at the programminglevel

• Most often the mode for the file is created by
  or-ing a symbolic constant indicating file type
  with the file access permissions

31
Named Pipes at the programming level (continue.)

• When generating a FIFO, the dev argument should
  be left as 0

32
mkfifo function

• In many versions of UNIX, there is a C library
  function called mkfifo that simplifies the
  generation of a FIFO
• The mode argument for mkfifo refers only to the
  file access permissions for the FIFO, as the file
  type, by default, is set to S_IFIFO

33
mkfifo system call
34
Client-server process relationships
private
read
write
Server
write
write
private
read
private
read
read
p u b l i c
write
write
Client
Client
35
Named Pipes (continue.)

• To view the client process, click here
• To view the server process, click here

server 9002 client /tmp/PUBLIC No such
file or directory
36
MESSAGE QUEUES
37
Introduction

• To increase the flexibility and range of
  interprocess communication, supplementary
  communication facilities were added
• Message queues
• Semaphores
• Shared memory
• An IPC facility must be generated before it can
  be used. Each IPC facility has a
• Creator,
• Owner, and
• Access permissions

38
Introduction (continue.)

• Information on IPCs can be obtained with the ipcs
  command

ipcs -b IPC status from ltrunning systemgt as of
Thu Mar 8 230441 EST 2001 T ID
KEY MODE OWNER GROUP
QBYTES Message Queues T ID KEY
MODE OWNER GROUP SEGSZ Shared
Memory m 0 0x50000378 --rw-r--r--
root root 4 T ID KEY
MODE OWNER GROUP NSEMS Semaphores s
0 0x187cf --ra-ra-ra- root
root 1 s 2 0 --ra-------
sbenayed 400 3 s 3 0
--ra------- sbenayed 400 3
39
Introduction (continue.)

• The mode for an IPC contains an extra two leading
  characters that denote the IPCs current state
• An IPC facility can be removed
• by its owner by using the appropriate system call
  within a program, or
• By using the system level command, ipcrm
• example

ipcrm -q 50
40
ipcs mode indicators
41
Introduction (continue.)

• Users should make a conscientious effort to
  remove unneeded IPCs

42
IPC System Calls A Synopsis
43
IPC System Calls A Synopsis (continue)

• The IPC identifier is an index into a system
  table containing IPC permission structure
  information
• The IPC permission structure is defined in the
  header file ltsys/ipc.hgt as
• struct ipc_perm
• uid_t uid /owners user ID/
• gid_t gid /owners group ID/
• uid_t cuid /creators user ID/
• gid_t cgid /creators group ID/
• mode_t mode /access modes/
• ulong seq /slot usage sequence number/
• key_t key /key/
• long pad4/reserves area/

44
IPC System Calls A Synopsis (continue)

• All programs that make use of the IPC facilities
  should include the ltsys/types.hgt files
• By calling ftock with the same arguments,
  unrelated processes can be assured of producing
  the same key value and thus reference the same
  IPC facility.

45
ftock system call
46
IPC System Calls A Synopsis (continue)

• path, is reference to an existing accessible
  file. Often the value . is used for this
  argument
• id, is an integer value mos commonly represented
  by a single character
• To view how to use ftock, click here

a.out id a key 610D4B68 MSB a id b
key 620D4B68 MSB b id c key 630D4B68
MSB c id d key 640D4B68 MSB d
47
IPC System Calls A Synopsis (continue)

• The key value for the get system calls may also
  be set to the defined constant IPC_PRIVATE
• An IPC facility created with IPC_PRIVATE is
  normally shared between related processes (such
  as parent/child or child/parent) or in
  client-server settings
• When performing an exec the associated IPC
  identifier is passed to the child process by way
  of the environment, or as a command line
  parameter
• When specifying IPCCREAT, if the facility is
  already present, and it was not created using
  IPC_PRIVATE, its IPC identifier is returned

48
IPC System Calls A Synopsis (continue)

• IPC_CREATIPC_EXCEL causes the get system call to
  act in no clobber manner. That is, should there
  already be an IPC present for the specified key
  value, the get system call will fail otherwise,
  the facility is created

49
IPC System Calls A Synopsis (continue)
50
IPC System Calls A Synopsis (continue)
51
IPC System Calls A Synopsis (continue)

• The values the command may take are represented
  by the following defined constants
• IPC_STAT-Return the referenced IPC facility
  status information. When specified IPC_STAT, the
  ctl system call must pass a pointer to an
  allocated structure of the appropriate type to
  store the returned information
• IPC_SET-Change the owner, group or mode for the
  IPC facility. In addition, as with IPC_STAT, a
  pointer to a structure of the appropriate type
  (with the changed member information) must be
  passed
• IPC_RMID-Destroy the contents of the IPC facility
  and remove it from the system

52
IPC System Calls A Synopsis (continue)

• A process can specify IPC_SET or IPC_RMID if it
  is the owner or creator of the IPC

53
References

• INTERPROCES COMMUNICATIONS IN UNIX BY J. GRAY
• UNIX SYSTEM PROGRAMMING BY K.HAVILAND, D. GRAY
  AND B. SALAMA