module Shell_sys:Calls external programs, creates pipelines, etc. (full interface)sig
..end
Nevertheless, shell
often seems to work in a multi-threaded environment.
However, strange things can happen when two threads start new processes
at the same time, because they overwrite the global signal mask. As
a minimum precaution you should ensure that only one thread uses shell
at any time. Anyway, you have been warned.
exception Fatal_error of exn
x
into Fatal_error x
.type
environment
val create_env : unit -> environment
val current_env : unit -> environment
val copy_env : environment -> environment
val set_env : environment -> string array -> unit
val get_env : environment -> string array
val iter_env : f:(string -> unit) -> environment -> unit
f s
for every string s
.val set_env_var : environment -> string -> string -> unit
set_env_var env varname varval
: Sets the value of the variable
varname
in the environment env
to varval
.val get_env_var : environment -> string -> string
val iter_env_vars : f:(string -> string -> unit) -> environment -> unit
f name value
for every variable with name
and value
.type
command
val command : ?cmdname:string ->
?arguments:string array ->
?chdir:string ->
?environment:environment ->
?descriptors:Unix.file_descr list ->
?assignments:(Unix.file_descr * Unix.file_descr) list ->
filename:string -> unit -> command
cmdname
: The name of the command passed in argv[0]
. By
default, this argument is derived from filename
.arguments
: The arguments of the command (starting with the
first real argument, skipping cmdname
). By default []
.chdir
: Before the command is executed it is changed to
this directory.environment
: The environment of the command. By default, the
current environmentdescriptors
: The list of file descriptors to share with the
current process. In the subprocess only those descriptors remain open
that are either mentioned in descriptors
, or that are the final target
of assignments. By default, [stdin; stdout; stderr]
.
Note that only the final targets of assignments remain open in the
subprocess (unless they are also listed in descriptors
). If there
are cascaded assignments like (fd1, fd2); (fd2, fd3)
the intermediate
descriptors like fd2
are not considered as final targets; only fd3
would be a final target in this example.
assignments
: A list of descriptor pairs (fd_from,fd_to)
.
The descriptor fd_from
in the current process will be assigned
to fd_to
in the subprocess started for the command.
The list of assignments is executed sequentially, so
later assignments must take the effect of previous assignments
into account. For example, to make stderr of the subprocess write
to stdout of the parent process, pass [(stdout; stderr)]
. filename
: The name of the executable to start. The executable
file is not searched, use Shell_sys.lookup_executable
for this
purpose.exception Executable_not_found of string
val lookup_executable : ?path:string list -> string -> string
path
: The search path. By default, the contents of the
variable PATH of the current environment, split by ':', are
usedval get_cmdname : command -> string
val get_arguments : command -> string array
val get_chdir : command -> string option
chdir
parameter of the commandval get_environment : command -> environment
val get_descriptors : command -> Unix.file_descr list
val get_assignments : command -> (Unix.file_descr * Unix.file_descr) list
(fd_from,fd_to)
val get_filename : command -> string
val set_cmdname : command -> string -> unit
val set_arguments : command -> string array -> unit
val set_chdir : command -> string option -> unit
chdir
parameter of the commandval set_environment : command -> environment -> unit
val set_descriptors : command -> Unix.file_descr list -> unit
val set_assignments : command -> (Unix.file_descr * Unix.file_descr) list -> unit
(fd_from,fd_to)
val set_filename : command -> string -> unit
val copy_command : command -> command
val is_executable : command -> bool
true
if there is an executable file for the command, and
it is permitted to run this file (as stated by the file permissions).
false
means that the command can definitely not be executed. However,
even if the function returns true
there may be still reasons that
execution will fail.
type
process
type
group_action =
| |
New_bg_group |
(* | Start process in new background process group | *) |
| |
New_fg_group |
(* | Start process in new foreground process group | *) |
| |
Join_group of |
(* | Started process joins this existing process group | *) |
| |
Current_group |
(* | Started process remains in the current group | *) |
val run : ?group:group_action ->
?pipe_assignments:(Unix.file_descr * Unix.file_descr) list ->
command -> process
exec
system call has been successfully performed; errors that
occur until exec
are caught and reported as exception (even errors
in the fresh subprocess).
On error, one can assume that the process state has been cleaned up: any forked child process has terminated; any modifications of the global process state has been restored.
File descriptor assignments: First, the assignments in pipe_assignments
are performed, then the assignments contained in the command. The
pipe_assignments
are interpreted as parallel assignment, not
as sequential assignment.
Note: For users without very special needs, it is recommended to run jobs instead of processes. See below for the job API.
group
: Determines in which process group the new process will
run. By default Current_group
.pipe_assignments
: A list of descriptor pairs (fd_from,fd_to)
.
The descriptor fd_from
in the current process will be assigned
to fd_to
in the started subprocess. In order to
take effect, fd_to
must also be passed in the descriptors
property of the started command.
Furthermore, fd_from
may or may not be member of descriptors
;
in the first case it will remain open, in the latter case it will
be closed. The list of assignments is executed in parallel. For
example, to swap the roles of stdout and stderr, pass the list
[(stdout,stderr); (stderr,stdout)]
.val process_id : process -> int
val status : process -> Unix.process_status
wait
(below): If the process
has terminated, the status of the process is returned.
If the process is still running, Not_found
will be raised.
Note: This function does not call Unix.waitpid
to get the status
and to release the process ID. This is done by wait
below.
val command_of_process : process -> command
type
process_event =
| |
File_read of |
(* | Data can be read from the fd | *) |
| |
File_write of |
(* | Data can be written to the fd | *) |
| |
File_except of |
(* | OOB data can be read from the fd | *) |
| |
Process_event of |
(* | The process has changed its status | *) |
| |
Signal |
(* | A signal happened | *) |
wait
val wait : ?wnohang:bool ->
?wuntraced:bool ->
?restart:bool ->
?check_interval:float ->
?read:Unix.file_descr list ->
?write:Unix.file_descr list ->
?except:Unix.file_descr list ->
process list -> process_event list
read
,
write
, and except
, and waits until events for these resources
have happened, and reports these. It is allowed that the list of
processes includes stopped and terminated processes.
The function returns immediately with [] if it is no longer possible that any event can happen.
The passed file descriptors must be open.
The function reports events under these conditions:
Process_event
.wuntraced = true
. This is also
recorded as Process_event
.read
list delivers data. This is a
File_read
event.write
list accepts data. This is a
File_write
event.except
list delivers data. This is a
File_except
event.wait
invocation.wait
does not restart automatically on a signal, the function
will raise Unix.Unix_error(Unix.EINTR,_,_)
when the signal condition
is caught.check_interval
seconds it is checked whether there are
process events. File descriptor events are reported without delay.
wnohang
: If true
, it is immediately checked whether file or
process events have happend, and if so, the event list is returned.
When there are no events to report, the empty list is immediately
returned. Default: false
wuntraced
: Whether to report events about stopped processes.
Default: false
restart
: Whether to restart the event loop when a signal
interrupts the loop. If true
, Unix errors of the type EINTR
cannot happen any longer. Default: false
check_interval
: How frequently the processes are checked for
events (in seconds). In addition to this, the processes are also
checked when a signal happens. Default: 0.1read
: The file descriptors to check for read eventswrite
: The file descriptors to check for write eventsexcept
: The file descriptors to check for out-of-band eventsval call : command -> process
system
, but no intermediate shell).
status
is guaranteed to return WEXITED or WSIGNALED.val kill : ?signal:int -> process -> unit
signal
: The signal to send, by default SIGTERMsystem_handler
can be used to watch the progress of
jobs from a foreign event loop instead of wait
. This interface
is needed for the integration into the Unixqueue framework.type
system_handler = {
|
sys_register : |
(* | Register an event handler | *) |
|
sys_wait : |
(* | Start the event loop | *) |
sys_register
: By calling this function a callback function for the
specified events is registered. The meaning of the arguments is the
same as for wait
, except of the last argument which is the callback
function of type process_event list -> unit
. Instead of returning
the events like wait
, sys_register
calls this function back
to deliver the events.
sys_wait
: By calling this function the event loop is started, and
events are delivered to the registered callback. If exceptions are
raised in the callback function these will not be caught, so the
caller of sys_wait
will get them. It must be possible to restart
sys_wait
in this case.
The callback function can change the list of interesting events by
calling sys_register
again.
If effectively no events are interesting (sys_register
is called without
file descriptors and no running process) the callback function is called
with an empty process_event list
once. If it does not register a new
callback, the event loop will stop, and sys_wait
will return normally.
job
is the description of how to run several commands which are
linked by pipelines (or which are just a logical unit). A job_instance
is the running instance of a job.
Jobs are implemented on a higher layer than commands; the following means of the operating system are used by job invocations:
job_instance
corresponds to a Unix process group. In
this case the last added command will result in the process group
leader.install_job_handlers
)add_pipeline
).add_producer
and add_consumer
)
In order to run jobs efficiently (without busy waiting) and properly
it is strongly recommended to install the signal handlers using
install_job_handlers
type
job
type
job_instance
val new_job : unit -> job
add_command
), pipelines (add_pipeline
),
consumers (add_consumer
) and producers (add_producer
).
When the job is set up, you can start it (run_job
/finish_job
or
call_job
).val add_command : command -> job -> unit
Note that you cannot add the same command twice; however you can
add a copy of a command already belonging to the job.
val add_pipeline : ?bidirectional:bool ->
?src_descr:Unix.file_descr ->
?dest_descr:Unix.file_descr ->
src:command -> dest:command -> job -> unit
src
to the
input of the command dest
.
bidirectional
: if false
(default), a classical pipe is created
to connect the file descriptors. This normally restricts the data
flow to one direction. If true
, a socketpair is created which is
roughly a bidirectional pipe. In this case, data flow in both
directions is possible.src_descr
: determines the file descriptor of the source command
which is redirected. This is by default stdout
.dest_descr
: determines the file descriptor of the destination
command to which the data stream is sent. This is by default stdin
.val add_producer : ?descr:Unix.file_descr ->
producer:(Unix.file_descr -> bool) ->
command -> job -> unit
descr
of the subprocess and another
descriptor descr'
which is open in the current process. The
function producer
is called when data can be written into the
pipe. The argument of producer
is the writing end of the pipe
descr'
. This file descriptor is in non-blocking mode. The
function producer
must close descr'
when all data are
transferred. The return value of producer
indicates whether
the descriptor is still open.
descr
: The descriptor of the subprocess to which the reading
end of the pipe is dup'ed. By default stdin
.val from_string : ?pos:int ->
?len:int -> ?epipe:(unit -> unit) -> string -> Unix.file_descr -> bool
from_string ?pos ?len ?epipe s
returns a function which can be
used as producer
argument for add_producer
. The data transferred
to the subprocess is taken from the string s
. After these data
are sent, the pipeline is closed.
pos
: The position in s
where the data slice to transfer begins.
By default 0
.len
: The length of the data slice to transfer. By default,
all bytes from the start position pos
to the end of the
string are taken.epipe
: This function is called when the pipeline breaks
(EPIPE). Default: the empty function. EPIPE exceptions are
always caught, and implicitly handled by closing the pipeline.val from_stream : ?epipe:(unit -> unit) -> string Stream.t -> Unix.file_descr -> bool
from_stream ?epipe s
returns a function which can be
used as producer
argument for add_producer
. The data transferred
to the subprocess is taken from the string stream s
. After these data
are sent, the pipeline is closed.
epipe
: This function is called when the pipeline breaks
(EPIPE). Default: the empty function. EPIPE exceptions are
always caught, and implicitly handled by closing the pipeline.val add_consumer : ?descr:Unix.file_descr ->
consumer:(Unix.file_descr -> bool) ->
command -> job -> unit
descr
of the subprocess and another descriptor descr'
which is open
in the current process. The function consumer
is called when
data can be read from the pipe. The argument of consumer
is
reading end of the pipe descr'
. This file descriptor is in
non-blocking mode. The function consumer
must close descr'
after EOF is detected. The return value of consumer
indicates whether
the descriptor is still open.
descr
: The descriptor of the subprocess to which the writing
end of the pipe is dup'ed. By default stdout
.val to_buffer : Buffer.t -> Unix.file_descr -> bool
to_buffer b
returns a function which can be
used as consumer
argument for add_consumer
. The data received
from the subprocess is added to the buffer b
.type
group_mode =
| |
Same_as_caller |
(* | The job runs in the same process group as the current process | *) |
| |
Foreground |
(* | The job runs in a new foreground process group | *) |
| |
Background |
(* | The job runs in a new background process group | *) |
val run_job : ?mode:group_mode ->
?forward_signals:bool -> job -> job_instance
The function returns a job_instance
, i.e. a value recording which
processes are started, and how they are related. Furthermore, the
function has the side effect of adding the
job to the global list of current jobs.
The mode
argument specifies whether a new Unix process group is
created for the job instance. A process group has the advantage that
it is possible to send signals to all processes of the group at
once. For example, one can terminate a group by sending SIGTERM
to it: All member processes get the signal. Usually, these are not only
the subprocesses initially created, but also further processes
started by the initial members.
So if it is necessary to send signals to the processes of the job, it will be advantegous to run it in a new process group. However, this also means that signals sent to the current process group are not automatically forwarded to the created process group. For example, if the current process group is terminated, the job will continue running, because it is member of a different process group. One has to explicitly catch and forward signals to avoid wild-running jobs.
The moral of the story is that one should only create new process groups when it is necessary (e.g. the user must be able to stop an action at any time). Furthermore, signal forwarding must be configured.
The Unix shell also allows the programmer to specify process group handling to a certain extent. Normally, commands are executed in the same process group as the caller. The syntax "command &" forces that the command is run in a new background process group. There is another situation when new process groups are created: when a new interactive shell is started the commands are run in new foreground process groups (so the keyboard signals like CTRL-C work).
mode
: Specifies the process group handling. By default, the
job is executed in the same process group as the current process
(Same_as_caller
). The value Background
causes that a new
background process group is started. The value Foreground
causes
that a new foreground process group is started. For the latter,
it is required that there is a controlling terminal (i.e. it
does not work for daemons). Any existing foreground process group
(there is at most one) is put into the background, but this is
not restored when the job is over (the caller must do this).
Foreground process groups should be avoided unless you are
writing an interactive shell interpreter.forward_signals
: If true
, the default, keyboard signals
(SIGINT, SIGQUIT) delivered to the current process are forwarded to
the job. This has only a meaning if the job is running as
background process group. Furthermore, it is required that
install_job_handlers
has been called to enable signal
forwarding.
The function returns normally if at least one process could be started.
If no process was startable (i.e. the first command was not startable),
an exception is raised. If one or more processes could be started but
not all, job_status
will return Job_partially_running
. The caller
should then discard the job and any intermediate result that might
already have been produced by the partial job.
When all processes could be started and no other exceptional condition
happened, the function sets job_status
to Job_running
.
val register_job : system_handler -> job_instance -> unit
system_handler
. This is not necessary
if you directly call finish_job
.val finish_job : ?sys:system_handler -> job_instance -> unit
Exceptions raised by the producer/consumer functions are not caught.
In this case, finish_job
is restartable.
The sys
argument determines the system_handler (standard_system_handler
by default). The job instance is registered at the system handler,
and it is waited until the job finishes. Roughly, finish_job
is equivalent to
register_job sys jobinst;
sys.sys_wait()
val call_job : ?mode:group_mode ->
?forward_signals:bool ->
?onerror:(job_instance -> unit) ->
job -> job_instance
run_job
) and waits until it finishes (see
finish_job
); i.e. call_job = run_job + finish_job
.
The function returns normally if all processes can be started; you can
examine job_status
of the result to get the information whether all
processes returned the exit code 0.
mode
: See run_job
forward_signals
: See run_job
onerror
: If not all of the processes can be started, the
function passed by onerror
is invoked. By default, this
function calls abandon_job
to stop the already running
processes. After the onerror
function has returned, the original
exception is raised again. Fatal error conditions are not caught.val processes : job_instance -> process list
run_job
; note that the corresponding Unix process group
may have additional processes (e.g. indirectly started processes).exception No_Unix_process_group
val process_group_leader : job_instance -> process
Same_as_caller
.val process_group_id : job_instance -> int
Same_as_caller
.val process_group_expects_signals : job_instance -> bool
true
iff the group has mode=Background
and forward_signals
.type
job_status =
| |
Job_running |
(* | All commands could be started, and at least one process is still running | *) |
| |
Job_partially_running |
(* | Not all commands could be started, and at least one process is still running | *) |
| |
Job_ok |
(* | all processes terminated with exit code 0 | *) |
| |
Job_error |
(* | all processes terminated but some abnormally | *) |
| |
Job_abandoned |
(* | the job has been abandoned (see abandon_job ) | *) |
val job_status : job_instance -> job_status
finish_job
has been called:
run_job
: status is Job_running
or Job_partially_running
finish_job
: if returning normally: status is Job_ok
or
Job_error
. After an exception happened the other states are possible,
tooval kill_process_group : ?signal:int -> job_instance -> unit
Same_as_caller
(exception No_Unix_process_group
).
Note 1: In the Unix terminology, "killing a job" only means to send a signal to the job. So the job may continue running, or it may terminate; in general we do not know this. Because of this, the job will still have an entry in the job list.
Note 2: Because sub-sub-processes are also killed, this function may send the signal to more processes than kill_processes (below). On the other hand, it is possible that sub-processes change their group ID such that it is also possible that this function sends the signal to fewer processes than kill_processes.
signal
: The signal number to send (O'Caml signal numbers as
used by the Sys
module). Default is Sys.sigterm
.val kill_processes : ?signal:int -> job_instance -> unit
signal
: The signal number to send (O'Caml signal numbers as
used by the Sys
module). Default is Sys.sigterm
.val abandon_job : ?signal:int -> job_instance -> unit
Same_as_caller
, the
signal is sent to the processes individually. If the mode is
Foreground
or Background
, the signal is sent to the process group
corresponding to the job.
This function removes the job from the job list; i.e. it is no longer watched. Because of some magic spells it is guaranteed that the job dies immediately without becoming a zombie (provided you have a SIGCHLD handler).
signal
: The signal number to send (O'Caml signal numbers as
used by the Sys
module). Default is Sys.sigterm
.val iter_job_instances : f:(job_instance -> unit) -> unit
f
for every
job_instance
.val watch_for_zombies : unit -> unit
exception Already_installed
val configure_job_handlers : ?catch_sigint:bool ->
?catch_sigquit:bool ->
?catch_sigterm:bool ->
?catch_sighup:bool ->
?catch_sigchld:bool -> ?set_sigpipe:bool -> ?at_exit:bool -> unit -> unit
forward_signals
).
After the signals have been forwarded, the previous signal action
is performed.forward_signals
).
After the signals have been forwarded, the previous signal action
is performed.at_exit
handler sends a SIGTERM to all dependent processes, too.watch_for_zombies
.
After this function is called, the previous signal action
is performed; however if the previous action was Signal_ignore
this is incorrectly interpreted as empty action (zombies are not
avoided)set_sigpipe
to stress this)Foreground
or Background
: the processes
of the corresponding Unix process groupSame_as_caller
: the actually started
children processes
This function sets only which handlers will be installed when
install_job_handlers
(below) is invoked.
The function fails if the handlers are already installed.
KNOWN BUGS: At least for O'Caml 3.00, the handlers do not call the old signal handlers after their own work has been done; this is due to an error in Sys.signal.
catch_sigint
: whether to install a SIGINT handler (default: true
)catch_sigquit
: whether to install a SIGQUIT handler (default: true
)catch_sigterm
: whether to install a SIGTERM handler (default: true
)catch_sighup
: whether to install a SIGHUP handler (default: true
)catch_sigchld
: whether to install a SIGCHLD handler (default: true
)set_sigpipe
: whether to set a SIGPIPE handler (default: true
)at_exit
: whether to set the at_exit
handler (default: true
)val install_job_handlers : unit -> unit
Already_installed
if the handlers are already installed.add_rd_polling
and add_wr_polling
have been removed.
They were added prior to the merge with the equeue library. Use a
Unixqueue now, which is much more powerful.