# HG changeset patch # User Glenn Morris # Date 1189052567 0 # Node ID 888f14c01e6d72edf068ede12f61a97b5e3dde93 # Parent d72112764c93653b38b7c40a48c555ce33018f33 Move here from ../../lispref diff -r d72112764c93 -r 888f14c01e6d doc/lispref/processes.texi --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/lispref/processes.texi Thu Sep 06 04:22:47 2007 +0000 @@ -0,0 +1,2561 @@ +@c -*-texinfo-*- +@c This is part of the GNU Emacs Lisp Reference Manual. +@c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2001, +@c 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. +@c See the file elisp.texi for copying conditions. +@setfilename ../info/processes +@node Processes, Display, Abbrevs, Top +@chapter Processes +@cindex child process +@cindex parent process +@cindex subprocess +@cindex process + + In the terminology of operating systems, a @dfn{process} is a space in +which a program can execute. Emacs runs in a process. Emacs Lisp +programs can invoke other programs in processes of their own. These are +called @dfn{subprocesses} or @dfn{child processes} of the Emacs process, +which is their @dfn{parent process}. + + A subprocess of Emacs may be @dfn{synchronous} or @dfn{asynchronous}, +depending on how it is created. When you create a synchronous +subprocess, the Lisp program waits for the subprocess to terminate +before continuing execution. When you create an asynchronous +subprocess, it can run in parallel with the Lisp program. This kind of +subprocess is represented within Emacs by a Lisp object which is also +called a ``process.'' Lisp programs can use this object to communicate +with the subprocess or to control it. For example, you can send +signals, obtain status information, receive output from the process, or +send input to it. + +@defun processp object +This function returns @code{t} if @var{object} is a process, +@code{nil} otherwise. +@end defun + +@menu +* Subprocess Creation:: Functions that start subprocesses. +* Shell Arguments:: Quoting an argument to pass it to a shell. +* Synchronous Processes:: Details of using synchronous subprocesses. +* Asynchronous Processes:: Starting up an asynchronous subprocess. +* Deleting Processes:: Eliminating an asynchronous subprocess. +* Process Information:: Accessing run-status and other attributes. +* Input to Processes:: Sending input to an asynchronous subprocess. +* Signals to Processes:: Stopping, continuing or interrupting + an asynchronous subprocess. +* Output from Processes:: Collecting output from an asynchronous subprocess. +* Sentinels:: Sentinels run when process run-status changes. +* Query Before Exit:: Whether to query if exiting will kill a process. +* Transaction Queues:: Transaction-based communication with subprocesses. +* Network:: Opening network connections. +* Network Servers:: Network servers let Emacs accept net connections. +* Datagrams:: UDP network connections. +* Low-Level Network:: Lower-level but more general function + to create connections and servers. +* Misc Network:: Additional relevant functions for network connections. +* Byte Packing:: Using bindat to pack and unpack binary data. +@end menu + +@node Subprocess Creation +@section Functions that Create Subprocesses + + There are three functions that create a new subprocess in which to run +a program. One of them, @code{start-process}, creates an asynchronous +process and returns a process object (@pxref{Asynchronous Processes}). +The other two, @code{call-process} and @code{call-process-region}, +create a synchronous process and do not return a process object +(@pxref{Synchronous Processes}). + + Synchronous and asynchronous processes are explained in the following +sections. Since the three functions are all called in a similar +fashion, their common arguments are described here. + +@cindex execute program +@cindex @code{PATH} environment variable +@cindex @code{HOME} environment variable + In all cases, the function's @var{program} argument specifies the +program to be run. An error is signaled if the file is not found or +cannot be executed. If the file name is relative, the variable +@code{exec-path} contains a list of directories to search. Emacs +initializes @code{exec-path} when it starts up, based on the value of +the environment variable @code{PATH}. The standard file name +constructs, @samp{~}, @samp{.}, and @samp{..}, are interpreted as +usual in @code{exec-path}, but environment variable substitutions +(@samp{$HOME}, etc.) are not recognized; use +@code{substitute-in-file-name} to perform them (@pxref{File Name +Expansion}). @code{nil} in this list refers to +@code{default-directory}. + + Executing a program can also try adding suffixes to the specified +name: + +@defvar exec-suffixes +This variable is a list of suffixes (strings) to try adding to the +specified program file name. The list should include @code{""} if you +want the name to be tried exactly as specified. The default value is +system-dependent. +@end defvar + + @strong{Please note:} The argument @var{program} contains only the +name of the program; it may not contain any command-line arguments. You +must use @var{args} to provide those. + + Each of the subprocess-creating functions has a @var{buffer-or-name} +argument which specifies where the standard output from the program will +go. It should be a buffer or a buffer name; if it is a buffer name, +that will create the buffer if it does not already exist. It can also +be @code{nil}, which says to discard the output unless a filter function +handles it. (@xref{Filter Functions}, and @ref{Read and Print}.) +Normally, you should avoid having multiple processes send output to the +same buffer because their output would be intermixed randomly. + +@cindex program arguments + All three of the subprocess-creating functions have a @code{&rest} +argument, @var{args}. The @var{args} must all be strings, and they are +supplied to @var{program} as separate command line arguments. Wildcard +characters and other shell constructs have no special meanings in these +strings, since the strings are passed directly to the specified program. + + The subprocess gets its current directory from the value of +@code{default-directory} (@pxref{File Name Expansion}). + +@cindex environment variables, subprocesses + The subprocess inherits its environment from Emacs, but you can +specify overrides for it with @code{process-environment}. @xref{System +Environment}. + +@defvar exec-directory +@pindex movemail +The value of this variable is a string, the name of a directory that +contains programs that come with GNU Emacs, programs intended for Emacs +to invoke. The program @code{movemail} is an example of such a program; +Rmail uses it to fetch new mail from an inbox. +@end defvar + +@defopt exec-path +The value of this variable is a list of directories to search for +programs to run in subprocesses. Each element is either the name of a +directory (i.e., a string), or @code{nil}, which stands for the default +directory (which is the value of @code{default-directory}). +@cindex program directories + +The value of @code{exec-path} is used by @code{call-process} and +@code{start-process} when the @var{program} argument is not an absolute +file name. +@end defopt + +@node Shell Arguments +@section Shell Arguments +@cindex arguments for shell commands +@cindex shell command arguments + + Lisp programs sometimes need to run a shell and give it a command +that contains file names that were specified by the user. These +programs ought to be able to support any valid file name. But the shell +gives special treatment to certain characters, and if these characters +occur in the file name, they will confuse the shell. To handle these +characters, use the function @code{shell-quote-argument}: + +@defun shell-quote-argument argument +This function returns a string which represents, in shell syntax, +an argument whose actual contents are @var{argument}. It should +work reliably to concatenate the return value into a shell command +and then pass it to a shell for execution. + +Precisely what this function does depends on your operating system. The +function is designed to work with the syntax of your system's standard +shell; if you use an unusual shell, you will need to redefine this +function. + +@example +;; @r{This example shows the behavior on GNU and Unix systems.} +(shell-quote-argument "foo > bar") + @result{} "foo\\ \\>\\ bar" + +;; @r{This example shows the behavior on MS-DOS and MS-Windows.} +(shell-quote-argument "foo > bar") + @result{} "\"foo > bar\"" +@end example + +Here's an example of using @code{shell-quote-argument} to construct +a shell command: + +@example +(concat "diff -c " + (shell-quote-argument oldfile) + " " + (shell-quote-argument newfile)) +@end example +@end defun + +@node Synchronous Processes +@section Creating a Synchronous Process +@cindex synchronous subprocess + + After a @dfn{synchronous process} is created, Emacs waits for the +process to terminate before continuing. Starting Dired on GNU or +Unix@footnote{On other systems, Emacs uses a Lisp emulation of +@code{ls}; see @ref{Contents of Directories}.} is an example of this: it +runs @code{ls} in a synchronous process, then modifies the output +slightly. Because the process is synchronous, the entire directory +listing arrives in the buffer before Emacs tries to do anything with it. + + While Emacs waits for the synchronous subprocess to terminate, the +user can quit by typing @kbd{C-g}. The first @kbd{C-g} tries to kill +the subprocess with a @code{SIGINT} signal; but it waits until the +subprocess actually terminates before quitting. If during that time the +user types another @kbd{C-g}, that kills the subprocess instantly with +@code{SIGKILL} and quits immediately (except on MS-DOS, where killing +other processes doesn't work). @xref{Quitting}. + + The synchronous subprocess functions return an indication of how the +process terminated. + + The output from a synchronous subprocess is generally decoded using a +coding system, much like text read from a file. The input sent to a +subprocess by @code{call-process-region} is encoded using a coding +system, much like text written into a file. @xref{Coding Systems}. + +@defun call-process program &optional infile destination display &rest args +This function calls @var{program} in a separate process and waits for +it to finish. + +The standard input for the process comes from file @var{infile} if +@var{infile} is not @code{nil}, and from the null device otherwise. +The argument @var{destination} says where to put the process output. +Here are the possibilities: + +@table @asis +@item a buffer +Insert the output in that buffer, before point. This includes both the +standard output stream and the standard error stream of the process. + +@item a string +Insert the output in a buffer with that name, before point. + +@item @code{t} +Insert the output in the current buffer, before point. + +@item @code{nil} +Discard the output. + +@item 0 +Discard the output, and return @code{nil} immediately without waiting +for the subprocess to finish. + +In this case, the process is not truly synchronous, since it can run in +parallel with Emacs; but you can think of it as synchronous in that +Emacs is essentially finished with the subprocess as soon as this +function returns. + +MS-DOS doesn't support asynchronous subprocesses, so this option doesn't +work there. + +@item @code{(@var{real-destination} @var{error-destination})} +Keep the standard output stream separate from the standard error stream; +deal with the ordinary output as specified by @var{real-destination}, +and dispose of the error output according to @var{error-destination}. +If @var{error-destination} is @code{nil}, that means to discard the +error output, @code{t} means mix it with the ordinary output, and a +string specifies a file name to redirect error output into. + +You can't directly specify a buffer to put the error output in; that is +too difficult to implement. But you can achieve this result by sending +the error output to a temporary file and then inserting the file into a +buffer. +@end table + +If @var{display} is non-@code{nil}, then @code{call-process} redisplays +the buffer as output is inserted. (However, if the coding system chosen +for decoding output is @code{undecided}, meaning deduce the encoding +from the actual data, then redisplay sometimes cannot continue once +non-@acronym{ASCII} characters are encountered. There are fundamental +reasons why it is hard to fix this; see @ref{Output from Processes}.) + +Otherwise the function @code{call-process} does no redisplay, and the +results become visible on the screen only when Emacs redisplays that +buffer in the normal course of events. + +The remaining arguments, @var{args}, are strings that specify command +line arguments for the program. + +The value returned by @code{call-process} (unless you told it not to +wait) indicates the reason for process termination. A number gives the +exit status of the subprocess; 0 means success, and any other value +means failure. If the process terminated with a signal, +@code{call-process} returns a string describing the signal. + +In the examples below, the buffer @samp{foo} is current. + +@smallexample +@group +(call-process "pwd" nil t) + @result{} 0 + +---------- Buffer: foo ---------- +/usr/user/lewis/manual +---------- Buffer: foo ---------- +@end group + +@group +(call-process "grep" nil "bar" nil "lewis" "/etc/passwd") + @result{} 0 + +---------- Buffer: bar ---------- +lewis:5LTsHm66CSWKg:398:21:Bil Lewis:/user/lewis:/bin/csh + +---------- Buffer: bar ---------- +@end group +@end smallexample + +Here is a good example of the use of @code{call-process}, which used to +be found in the definition of @code{insert-directory}: + +@smallexample +@group +(call-process insert-directory-program nil t nil @var{switches} + (if full-directory-p + (concat (file-name-as-directory file) ".") + file)) +@end group +@end smallexample +@end defun + +@defun process-file program &optional infile buffer display &rest args +This function processes files synchronously in a separate process. It +is similar to @code{call-process} but may invoke a file handler based +on the value of the variable @code{default-directory}. The current +working directory of the subprocess is @code{default-directory}. + +The arguments are handled in almost the same way as for +@code{call-process}, with the following differences: + +Some file handlers may not support all combinations and forms of the +arguments @var{infile}, @var{buffer}, and @var{display}. For example, +some file handlers might behave as if @var{display} were @code{nil}, +regardless of the value actually passed. As another example, some +file handlers might not support separating standard output and error +output by way of the @var{buffer} argument. + +If a file handler is invoked, it determines the program to run based +on the first argument @var{program}. For instance, consider that a +handler for remote files is invoked. Then the path that is used for +searching the program might be different than @code{exec-path}. + +The second argument @var{infile} may invoke a file handler. The file +handler could be different from the handler chosen for the +@code{process-file} function itself. (For example, +@code{default-directory} could be on a remote host, whereas +@var{infile} is on another remote host. Or @code{default-directory} +could be non-special, whereas @var{infile} is on a remote host.) + +If @var{buffer} is a list of the form @code{(@var{real-destination} +@var{error-destination})}, and @var{error-destination} names a file, +then the same remarks as for @var{infile} apply. + +The remaining arguments (@var{args}) will be passed to the process +verbatim. Emacs is not involved in processing file names that are +present in @var{args}. To avoid confusion, it may be best to avoid +absolute file names in @var{args}, but rather to specify all file +names as relative to @code{default-directory}. The function +@code{file-relative-name} is useful for constructing such relative +file names. +@end defun + +@defun call-process-region start end program &optional delete destination display &rest args +This function sends the text from @var{start} to @var{end} as +standard input to a process running @var{program}. It deletes the text +sent if @var{delete} is non-@code{nil}; this is useful when +@var{destination} is @code{t}, to insert the output in the current +buffer in place of the input. + +The arguments @var{destination} and @var{display} control what to do +with the output from the subprocess, and whether to update the display +as it comes in. For details, see the description of +@code{call-process}, above. If @var{destination} is the integer 0, +@code{call-process-region} discards the output and returns @code{nil} +immediately, without waiting for the subprocess to finish (this only +works if asynchronous subprocesses are supported). + +The remaining arguments, @var{args}, are strings that specify command +line arguments for the program. + +The return value of @code{call-process-region} is just like that of +@code{call-process}: @code{nil} if you told it to return without +waiting; otherwise, a number or string which indicates how the +subprocess terminated. + +In the following example, we use @code{call-process-region} to run the +@code{cat} utility, with standard input being the first five characters +in buffer @samp{foo} (the word @samp{input}). @code{cat} copies its +standard input into its standard output. Since the argument +@var{destination} is @code{t}, this output is inserted in the current +buffer. + +@smallexample +@group +---------- Buffer: foo ---------- +input@point{} +---------- Buffer: foo ---------- +@end group + +@group +(call-process-region 1 6 "cat" nil t) + @result{} 0 + +---------- Buffer: foo ---------- +inputinput@point{} +---------- Buffer: foo ---------- +@end group +@end smallexample + + The @code{shell-command-on-region} command uses +@code{call-process-region} like this: + +@smallexample +@group +(call-process-region + start end + shell-file-name ; @r{Name of program.} + nil ; @r{Do not delete region.} + buffer ; @r{Send output to @code{buffer}.} + nil ; @r{No redisplay during output.} + "-c" command) ; @r{Arguments for the shell.} +@end group +@end smallexample +@end defun + +@defun call-process-shell-command command &optional infile destination display &rest args +This function executes the shell command @var{command} synchronously +in a separate process. The final arguments @var{args} are additional +arguments to add at the end of @var{command}. The other arguments +are handled as in @code{call-process}. +@end defun + +@defun process-file-shell-command command &optional infile destination display &rest args +This function is like @code{call-process-shell-command}, but uses +@code{process-file} internally. Depending on @code{default-directory}, +@var{command} can be executed also on remote hosts. +@end defun + +@defun shell-command-to-string command +This function executes @var{command} (a string) as a shell command, +then returns the command's output as a string. +@end defun + +@node Asynchronous Processes +@section Creating an Asynchronous Process +@cindex asynchronous subprocess + + After an @dfn{asynchronous process} is created, Emacs and the subprocess +both continue running immediately. The process thereafter runs +in parallel with Emacs, and the two can communicate with each other +using the functions described in the following sections. However, +communication is only partially asynchronous: Emacs sends data to the +process only when certain functions are called, and Emacs accepts data +from the process only when Emacs is waiting for input or for a time +delay. + + Here we describe how to create an asynchronous process. + +@defun start-process name buffer-or-name program &rest args +This function creates a new asynchronous subprocess and starts the +program @var{program} running in it. It returns a process object that +stands for the new subprocess in Lisp. The argument @var{name} +specifies the name for the process object; if a process with this name +already exists, then @var{name} is modified (by appending @samp{<1>}, +etc.) to be unique. The buffer @var{buffer-or-name} is the buffer to +associate with the process. + +The remaining arguments, @var{args}, are strings that specify command +line arguments for the program. + +In the example below, the first process is started and runs (rather, +sleeps) for 100 seconds. Meanwhile, the second process is started, and +given the name @samp{my-process<1>} for the sake of uniqueness. It +inserts the directory listing at the end of the buffer @samp{foo}, +before the first process finishes. Then it finishes, and a message to +that effect is inserted in the buffer. Much later, the first process +finishes, and another message is inserted in the buffer for it. + +@smallexample +@group +(start-process "my-process" "foo" "sleep" "100") + @result{} # +@end group + +@group +(start-process "my-process" "foo" "ls" "-l" "/user/lewis/bin") + @result{} #> + +---------- Buffer: foo ---------- +total 2 +lrwxrwxrwx 1 lewis 14 Jul 22 10:12 gnuemacs --> /emacs +-rwxrwxrwx 1 lewis 19 Jul 30 21:02 lemon + +Process my-process<1> finished + +Process my-process finished +---------- Buffer: foo ---------- +@end group +@end smallexample +@end defun + +@defun start-file-process name buffer-or-name program &rest args +Like @code{start-process}, this function starts a new asynchronous +subprocess running @var{program} in it, and returns its process +object---when @code{default-directory} is not a magic file name. + +If @code{default-directory} is magic, the function invokes its file +handler instead. This handler ought to run @var{program}, perhaps on +the local host, perhaps on a remote host that corresponds to +@code{default-directory}. In the latter case, the local part of +@code{default-directory} becomes the working directory of the process. + +This function does not try to invoke file name handlers for +@var{program} or for the @var{program-args}. + +Depending on the implementation of the file handler, it might not be +possible to apply @code{process-filter} or @code{process-sentinel} to +the resulting process object (@pxref{Filter Functions}, @pxref{Sentinels}). + +Some file handlers may not support @code{start-file-process} (for +example @code{ange-ftp-hook-function}). In such cases, the function +does nothing and returns @code{nil}. +@end defun + +@defun start-process-shell-command name buffer-or-name command &rest command-args +This function is like @code{start-process} except that it uses a shell +to execute the specified command. The argument @var{command} is a shell +command name, and @var{command-args} are the arguments for the shell +command. The variable @code{shell-file-name} specifies which shell to +use. + +The point of running a program through the shell, rather than directly +with @code{start-process}, is so that you can employ shell features such +as wildcards in the arguments. It follows that if you include an +arbitrary user-specified arguments in the command, you should quote it +with @code{shell-quote-argument} first, so that any special shell +characters do @emph{not} have their special shell meanings. @xref{Shell +Arguments}. +@end defun + +@defun start-file-process-shell-command name buffer-or-name command &rest command-args +This function is like @code{start-process-shell-command}, but uses +@code{start-file-process} internally. By this, @var{command} can be +executed also on remote hosts, depending on @code{default-directory}. +@end defun + +@defvar process-connection-type +@cindex pipes +@cindex @acronym{PTY}s +This variable controls the type of device used to communicate with +asynchronous subprocesses. If it is non-@code{nil}, then @acronym{PTY}s are +used, when available. Otherwise, pipes are used. + +@acronym{PTY}s are usually preferable for processes visible to the user, as +in Shell mode, because they allow job control (@kbd{C-c}, @kbd{C-z}, +etc.) to work between the process and its children, whereas pipes do +not. For subprocesses used for internal purposes by programs, it is +often better to use a pipe, because they are more efficient. In +addition, the total number of @acronym{PTY}s is limited on many systems and +it is good not to waste them. + +The value of @code{process-connection-type} takes effect when +@code{start-process} is called. So you can specify how to communicate +with one subprocess by binding the variable around the call to +@code{start-process}. + +@smallexample +@group +(let ((process-connection-type nil)) ; @r{Use a pipe.} + (start-process @dots{})) +@end group +@end smallexample + +To determine whether a given subprocess actually got a pipe or a +@acronym{PTY}, use the function @code{process-tty-name} (@pxref{Process +Information}). +@end defvar + +@node Deleting Processes +@section Deleting Processes +@cindex deleting processes + + @dfn{Deleting a process} disconnects Emacs immediately from the +subprocess. Processes are deleted automatically after they terminate, +but not necessarily right away. You can delete a process explicitly +at any time. If you delete a terminated process explicitly before it +is deleted automatically, no harm results. Deleting a running +process sends a signal to terminate it (and its child processes if +any), and calls the process sentinel if it has one. @xref{Sentinels}. + + When a process is deleted, the process object itself continues to +exist as long as other Lisp objects point to it. All the Lisp +primitives that work on process objects accept deleted processes, but +those that do I/O or send signals will report an error. The process +mark continues to point to the same place as before, usually into a +buffer where output from the process was being inserted. + +@defopt delete-exited-processes +This variable controls automatic deletion of processes that have +terminated (due to calling @code{exit} or to a signal). If it is +@code{nil}, then they continue to exist until the user runs +@code{list-processes}. Otherwise, they are deleted immediately after +they exit. +@end defopt + +@defun delete-process process +This function deletes a process, killing it with a @code{SIGKILL} +signal. The argument may be a process, the name of a process, a +buffer, or the name of a buffer. (A buffer or buffer-name stands for +the process that @code{get-buffer-process} returns.) Calling +@code{delete-process} on a running process terminates it, updates the +process status, and runs the sentinel (if any) immediately. If the +process has already terminated, calling @code{delete-process} has no +effect on its status, or on the running of its sentinel (which will +happen sooner or later). + +@smallexample +@group +(delete-process "*shell*") + @result{} nil +@end group +@end smallexample +@end defun + +@node Process Information +@section Process Information + + Several functions return information about processes. +@code{list-processes} is provided for interactive use. + +@deffn Command list-processes &optional query-only +This command displays a listing of all living processes. In addition, +it finally deletes any process whose status was @samp{Exited} or +@samp{Signaled}. It returns @code{nil}. + +If @var{query-only} is non-@code{nil} then it lists only processes +whose query flag is non-@code{nil}. @xref{Query Before Exit}. +@end deffn + +@defun process-list +This function returns a list of all processes that have not been deleted. + +@smallexample +@group +(process-list) + @result{} (# #) +@end group +@end smallexample +@end defun + +@defun get-process name +This function returns the process named @var{name}, or @code{nil} if +there is none. An error is signaled if @var{name} is not a string. + +@smallexample +@group +(get-process "shell") + @result{} # +@end group +@end smallexample +@end defun + +@defun process-command process +This function returns the command that was executed to start +@var{process}. This is a list of strings, the first string being the +program executed and the rest of the strings being the arguments that +were given to the program. + +@smallexample +@group +(process-command (get-process "shell")) + @result{} ("/bin/csh" "-i") +@end group +@end smallexample +@end defun + +@defun process-id process +This function returns the @acronym{PID} of @var{process}. This is an +integer that distinguishes the process @var{process} from all other +processes running on the same computer at the current time. The +@acronym{PID} of a process is chosen by the operating system kernel when the +process is started and remains constant as long as the process exists. +@end defun + +@defun process-name process +This function returns the name of @var{process}. +@end defun + +@defun process-status process-name +This function returns the status of @var{process-name} as a symbol. +The argument @var{process-name} must be a process, a buffer, a +process name (string) or a buffer name (string). + +The possible values for an actual subprocess are: + +@table @code +@item run +for a process that is running. +@item stop +for a process that is stopped but continuable. +@item exit +for a process that has exited. +@item signal +for a process that has received a fatal signal. +@item open +for a network connection that is open. +@item closed +for a network connection that is closed. Once a connection +is closed, you cannot reopen it, though you might be able to open +a new connection to the same place. +@item connect +for a non-blocking connection that is waiting to complete. +@item failed +for a non-blocking connection that has failed to complete. +@item listen +for a network server that is listening. +@item nil +if @var{process-name} is not the name of an existing process. +@end table + +@smallexample +@group +(process-status "shell") + @result{} run +@end group +@group +(process-status (get-buffer "*shell*")) + @result{} run +@end group +@group +x + @result{} #> +(process-status x) + @result{} exit +@end group +@end smallexample + +For a network connection, @code{process-status} returns one of the symbols +@code{open} or @code{closed}. The latter means that the other side +closed the connection, or Emacs did @code{delete-process}. +@end defun + +@defun process-exit-status process +This function returns the exit status of @var{process} or the signal +number that killed it. (Use the result of @code{process-status} to +determine which of those it is.) If @var{process} has not yet +terminated, the value is 0. +@end defun + +@defun process-tty-name process +This function returns the terminal name that @var{process} is using for +its communication with Emacs---or @code{nil} if it is using pipes +instead of a terminal (see @code{process-connection-type} in +@ref{Asynchronous Processes}). +@end defun + +@defun process-coding-system process +@anchor{Coding systems for a subprocess} +This function returns a cons cell describing the coding systems in use +for decoding output from @var{process} and for encoding input to +@var{process} (@pxref{Coding Systems}). The value has this form: + +@example +(@var{coding-system-for-decoding} . @var{coding-system-for-encoding}) +@end example +@end defun + +@defun set-process-coding-system process &optional decoding-system encoding-system +This function specifies the coding systems to use for subsequent output +from and input to @var{process}. It will use @var{decoding-system} to +decode subprocess output, and @var{encoding-system} to encode subprocess +input. +@end defun + + Every process also has a property list that you can use to store +miscellaneous values associated with the process. + +@defun process-get process propname +This function returns the value of the @var{propname} property +of @var{process}. +@end defun + +@defun process-put process propname value +This function sets the value of the @var{propname} property +of @var{process} to @var{value}. +@end defun + +@defun process-plist process +This function returns the process plist of @var{process}. +@end defun + +@defun set-process-plist process plist +This function sets the process plist of @var{process} to @var{plist}. +@end defun + +@node Input to Processes +@section Sending Input to Processes +@cindex process input + + Asynchronous subprocesses receive input when it is sent to them by +Emacs, which is done with the functions in this section. You must +specify the process to send input to, and the input data to send. The +data appears on the ``standard input'' of the subprocess. + + Some operating systems have limited space for buffered input in a +@acronym{PTY}. On these systems, Emacs sends an @acronym{EOF} +periodically amidst the other characters, to force them through. For +most programs, these @acronym{EOF}s do no harm. + + Subprocess input is normally encoded using a coding system before the +subprocess receives it, much like text written into a file. You can use +@code{set-process-coding-system} to specify which coding system to use +(@pxref{Process Information}). Otherwise, the coding system comes from +@code{coding-system-for-write}, if that is non-@code{nil}; or else from +the defaulting mechanism (@pxref{Default Coding Systems}). + + Sometimes the system is unable to accept input for that process, +because the input buffer is full. When this happens, the send functions +wait a short while, accepting output from subprocesses, and then try +again. This gives the subprocess a chance to read more of its pending +input and make space in the buffer. It also allows filters, sentinels +and timers to run---so take account of that in writing your code. + + In these functions, the @var{process} argument can be a process or +the name of a process, or a buffer or buffer name (which stands +for a process via @code{get-buffer-process}). @code{nil} means +the current buffer's process. + +@defun process-send-string process string +This function sends @var{process} the contents of @var{string} as +standard input. If it is @code{nil}, the current buffer's process is used. + + The function returns @code{nil}. + +@smallexample +@group +(process-send-string "shell<1>" "ls\n") + @result{} nil +@end group + + +@group +---------- Buffer: *shell* ---------- +... +introduction.texi syntax-tables.texi~ +introduction.texi~ text.texi +introduction.txt text.texi~ +... +---------- Buffer: *shell* ---------- +@end group +@end smallexample +@end defun + +@defun process-send-region process start end +This function sends the text in the region defined by @var{start} and +@var{end} as standard input to @var{process}. + +An error is signaled unless both @var{start} and @var{end} are +integers or markers that indicate positions in the current buffer. (It +is unimportant which number is larger.) +@end defun + +@defun process-send-eof &optional process +This function makes @var{process} see an end-of-file in its +input. The @acronym{EOF} comes after any text already sent to it. + +The function returns @var{process}. + +@smallexample +@group +(process-send-eof "shell") + @result{} "shell" +@end group +@end smallexample +@end defun + +@defun process-running-child-p process +This function will tell you whether a subprocess has given control of +its terminal to its own child process. The value is @code{t} if this is +true, or if Emacs cannot tell; it is @code{nil} if Emacs can be certain +that this is not so. +@end defun + +@node Signals to Processes +@section Sending Signals to Processes +@cindex process signals +@cindex sending signals +@cindex signals + + @dfn{Sending a signal} to a subprocess is a way of interrupting its +activities. There are several different signals, each with its own +meaning. The set of signals and their names is defined by the operating +system. For example, the signal @code{SIGINT} means that the user has +typed @kbd{C-c}, or that some analogous thing has happened. + + Each signal has a standard effect on the subprocess. Most signals +kill the subprocess, but some stop or resume execution instead. Most +signals can optionally be handled by programs; if the program handles +the signal, then we can say nothing in general about its effects. + + You can send signals explicitly by calling the functions in this +section. Emacs also sends signals automatically at certain times: +killing a buffer sends a @code{SIGHUP} signal to all its associated +processes; killing Emacs sends a @code{SIGHUP} signal to all remaining +processes. (@code{SIGHUP} is a signal that usually indicates that the +user hung up the phone.) + + Each of the signal-sending functions takes two optional arguments: +@var{process} and @var{current-group}. + + The argument @var{process} must be either a process, a process +name, a buffer, a buffer name, or @code{nil}. A buffer or buffer name +stands for a process through @code{get-buffer-process}. @code{nil} +stands for the process associated with the current buffer. An error +is signaled if @var{process} does not identify a process. + + The argument @var{current-group} is a flag that makes a difference +when you are running a job-control shell as an Emacs subprocess. If it +is non-@code{nil}, then the signal is sent to the current process-group +of the terminal that Emacs uses to communicate with the subprocess. If +the process is a job-control shell, this means the shell's current +subjob. If it is @code{nil}, the signal is sent to the process group of +the immediate subprocess of Emacs. If the subprocess is a job-control +shell, this is the shell itself. + + The flag @var{current-group} has no effect when a pipe is used to +communicate with the subprocess, because the operating system does not +support the distinction in the case of pipes. For the same reason, +job-control shells won't work when a pipe is used. See +@code{process-connection-type} in @ref{Asynchronous Processes}. + +@defun interrupt-process &optional process current-group +This function interrupts the process @var{process} by sending the +signal @code{SIGINT}. Outside of Emacs, typing the ``interrupt +character'' (normally @kbd{C-c} on some systems, and @code{DEL} on +others) sends this signal. When the argument @var{current-group} is +non-@code{nil}, you can think of this function as ``typing @kbd{C-c}'' +on the terminal by which Emacs talks to the subprocess. +@end defun + +@defun kill-process &optional process current-group +This function kills the process @var{process} by sending the +signal @code{SIGKILL}. This signal kills the subprocess immediately, +and cannot be handled by the subprocess. +@end defun + +@defun quit-process &optional process current-group +This function sends the signal @code{SIGQUIT} to the process +@var{process}. This signal is the one sent by the ``quit +character'' (usually @kbd{C-b} or @kbd{C-\}) when you are not inside +Emacs. +@end defun + +@defun stop-process &optional process current-group +This function stops the process @var{process} by sending the +signal @code{SIGTSTP}. Use @code{continue-process} to resume its +execution. + +Outside of Emacs, on systems with job control, the ``stop character'' +(usually @kbd{C-z}) normally sends this signal. When +@var{current-group} is non-@code{nil}, you can think of this function as +``typing @kbd{C-z}'' on the terminal Emacs uses to communicate with the +subprocess. +@end defun + +@defun continue-process &optional process current-group +This function resumes execution of the process @var{process} by sending +it the signal @code{SIGCONT}. This presumes that @var{process} was +stopped previously. +@end defun + +@c Emacs 19 feature +@defun signal-process process signal +This function sends a signal to process @var{process}. The argument +@var{signal} specifies which signal to send; it should be an integer. + +The @var{process} argument can be a system process @acronym{ID}; that +allows you to send signals to processes that are not children of +Emacs. +@end defun + +@node Output from Processes +@section Receiving Output from Processes +@cindex process output +@cindex output from processes + + There are two ways to receive the output that a subprocess writes to +its standard output stream. The output can be inserted in a buffer, +which is called the associated buffer of the process, or a function +called the @dfn{filter function} can be called to act on the output. If +the process has no buffer and no filter function, its output is +discarded. + + When a subprocess terminates, Emacs reads any pending output, +then stops reading output from that subprocess. Therefore, if the +subprocess has children that are still live and still producing +output, Emacs won't receive that output. + + Output from a subprocess can arrive only while Emacs is waiting: when +reading terminal input, in @code{sit-for} and @code{sleep-for} +(@pxref{Waiting}), and in @code{accept-process-output} (@pxref{Accepting +Output}). This minimizes the problem of timing errors that usually +plague parallel programming. For example, you can safely create a +process and only then specify its buffer or filter function; no output +can arrive before you finish, if the code in between does not call any +primitive that waits. + +@defvar process-adaptive-read-buffering +On some systems, when Emacs reads the output from a subprocess, the +output data is read in very small blocks, potentially resulting in +very poor performance. This behavior can be remedied to some extent +by setting the variable @var{process-adaptive-read-buffering} to a +non-@code{nil} value (the default), as it will automatically delay reading +from such processes, thus allowing them to produce more output before +Emacs tries to read it. +@end defvar + + It is impossible to separate the standard output and standard error +streams of the subprocess, because Emacs normally spawns the subprocess +inside a pseudo-TTY, and a pseudo-TTY has only one output channel. If +you want to keep the output to those streams separate, you should +redirect one of them to a file---for example, by using an appropriate +shell command. + +@menu +* Process Buffers:: If no filter, output is put in a buffer. +* Filter Functions:: Filter functions accept output from the process. +* Decoding Output:: Filters can get unibyte or multibyte strings. +* Accepting Output:: How to wait until process output arrives. +@end menu + +@node Process Buffers +@subsection Process Buffers + + A process can (and usually does) have an @dfn{associated buffer}, +which is an ordinary Emacs buffer that is used for two purposes: storing +the output from the process, and deciding when to kill the process. You +can also use the buffer to identify a process to operate on, since in +normal practice only one process is associated with any given buffer. +Many applications of processes also use the buffer for editing input to +be sent to the process, but this is not built into Emacs Lisp. + + Unless the process has a filter function (@pxref{Filter Functions}), +its output is inserted in the associated buffer. The position to insert +the output is determined by the @code{process-mark}, which is then +updated to point to the end of the text just inserted. Usually, but not +always, the @code{process-mark} is at the end of the buffer. + +@defun process-buffer process +This function returns the associated buffer of the process +@var{process}. + +@smallexample +@group +(process-buffer (get-process "shell")) + @result{} # +@end group +@end smallexample +@end defun + +@defun process-mark process +This function returns the process marker for @var{process}, which is the +marker that says where to insert output from the process. + +If @var{process} does not have a buffer, @code{process-mark} returns a +marker that points nowhere. + +Insertion of process output in a buffer uses this marker to decide where +to insert, and updates it to point after the inserted text. That is why +successive batches of output are inserted consecutively. + +Filter functions normally should use this marker in the same fashion +as is done by direct insertion of output in the buffer. A good +example of a filter function that uses @code{process-mark} is found at +the end of the following section. + +When the user is expected to enter input in the process buffer for +transmission to the process, the process marker separates the new input +from previous output. +@end defun + +@defun set-process-buffer process buffer +This function sets the buffer associated with @var{process} to +@var{buffer}. If @var{buffer} is @code{nil}, the process becomes +associated with no buffer. +@end defun + +@defun get-buffer-process buffer-or-name +This function returns a nondeleted process associated with the buffer +specified by @var{buffer-or-name}. If there are several processes +associated with it, this function chooses one (currently, the one most +recently created, but don't count on that). Deletion of a process +(see @code{delete-process}) makes it ineligible for this function to +return. + +It is usually a bad idea to have more than one process associated with +the same buffer. + +@smallexample +@group +(get-buffer-process "*shell*") + @result{} # +@end group +@end smallexample + +Killing the process's buffer deletes the process, which kills the +subprocess with a @code{SIGHUP} signal (@pxref{Signals to Processes}). +@end defun + +@node Filter Functions +@subsection Process Filter Functions +@cindex filter function +@cindex process filter + + A process @dfn{filter function} is a function that receives the +standard output from the associated process. If a process has a filter, +then @emph{all} output from that process is passed to the filter. The +process buffer is used directly for output from the process only when +there is no filter. + + The filter function can only be called when Emacs is waiting for +something, because process output arrives only at such times. Emacs +waits when reading terminal input, in @code{sit-for} and +@code{sleep-for} (@pxref{Waiting}), and in @code{accept-process-output} +(@pxref{Accepting Output}). + + A filter function must accept two arguments: the associated process +and a string, which is output just received from it. The function is +then free to do whatever it chooses with the output. + + Quitting is normally inhibited within a filter function---otherwise, +the effect of typing @kbd{C-g} at command level or to quit a user +command would be unpredictable. If you want to permit quitting inside +a filter function, bind @code{inhibit-quit} to @code{nil}. In most +cases, the right way to do this is with the macro +@code{with-local-quit}. @xref{Quitting}. + + If an error happens during execution of a filter function, it is +caught automatically, so that it doesn't stop the execution of whatever +program was running when the filter function was started. However, if +@code{debug-on-error} is non-@code{nil}, the error-catching is turned +off. This makes it possible to use the Lisp debugger to debug the +filter function. @xref{Debugger}. + + Many filter functions sometimes or always insert the text in the +process's buffer, mimicking the actions of Emacs when there is no +filter. Such filter functions need to use @code{set-buffer} in order to +be sure to insert in that buffer. To avoid setting the current buffer +semipermanently, these filter functions must save and restore the +current buffer. They should also update the process marker, and in some +cases update the value of point. Here is how to do these things: + +@smallexample +@group +(defun ordinary-insertion-filter (proc string) + (with-current-buffer (process-buffer proc) + (let ((moving (= (point) (process-mark proc)))) +@end group +@group + (save-excursion + ;; @r{Insert the text, advancing the process marker.} + (goto-char (process-mark proc)) + (insert string) + (set-marker (process-mark proc) (point))) + (if moving (goto-char (process-mark proc)))))) +@end group +@end smallexample + +@noindent +The reason to use @code{with-current-buffer}, rather than using +@code{save-excursion} to save and restore the current buffer, is so as +to preserve the change in point made by the second call to +@code{goto-char}. + + To make the filter force the process buffer to be visible whenever new +text arrives, insert the following line just before the +@code{with-current-buffer} construct: + +@smallexample +(display-buffer (process-buffer proc)) +@end smallexample + + To force point to the end of the new output, no matter where it was +previously, eliminate the variable @code{moving} and call +@code{goto-char} unconditionally. + + In earlier Emacs versions, every filter function that did regular +expression searching or matching had to explicitly save and restore the +match data. Now Emacs does this automatically for filter functions; +they never need to do it explicitly. @xref{Match Data}. + + A filter function that writes the output into the buffer of the +process should check whether the buffer is still alive. If it tries to +insert into a dead buffer, it will get an error. The expression +@code{(buffer-name (process-buffer @var{process}))} returns @code{nil} +if the buffer is dead. + + The output to the function may come in chunks of any size. A program +that produces the same output twice in a row may send it as one batch of +200 characters one time, and five batches of 40 characters the next. If +the filter looks for certain text strings in the subprocess output, make +sure to handle the case where one of these strings is split across two +or more batches of output. + +@defun set-process-filter process filter +This function gives @var{process} the filter function @var{filter}. If +@var{filter} is @code{nil}, it gives the process no filter. +@end defun + +@defun process-filter process +This function returns the filter function of @var{process}, or @code{nil} +if it has none. +@end defun + + Here is an example of use of a filter function: + +@smallexample +@group +(defun keep-output (process output) + (setq kept (cons output kept))) + @result{} keep-output +@end group +@group +(setq kept nil) + @result{} nil +@end group +@group +(set-process-filter (get-process "shell") 'keep-output) + @result{} keep-output +@end group +@group +(process-send-string "shell" "ls ~/other\n") + @result{} nil +kept + @result{} ("lewis@@slug[8] % " +@end group +@group +"FINAL-W87-SHORT.MSS backup.otl kolstad.mss~ +address.txt backup.psf kolstad.psf +backup.bib~ david.mss resume-Dec-86.mss~ +backup.err david.psf resume-Dec.psf +backup.mss dland syllabus.mss +" +"#backups.mss# backup.mss~ kolstad.mss +") +@end group +@end smallexample + +@ignore @c The code in this example doesn't show the right way to do things. +Here is another, more realistic example, which demonstrates how to use +the process mark to do insertion in the same fashion as is done when +there is no filter function: + +@smallexample +@group +;; @r{Insert input in the buffer specified by @code{my-shell-buffer}} +;; @r{and make sure that buffer is shown in some window.} +(defun my-process-filter (proc str) + (let ((cur (selected-window)) + (pop-up-windows t)) + (pop-to-buffer my-shell-buffer) +@end group +@group + (goto-char (point-max)) + (insert str) + (set-marker (process-mark proc) (point-max)) + (select-window cur))) +@end group +@end smallexample +@end ignore + +@node Decoding Output +@subsection Decoding Process Output +@cindex decode process output + + When Emacs writes process output directly into a multibyte buffer, +it decodes the output according to the process output coding system. +If the coding system is @code{raw-text} or @code{no-conversion}, Emacs +converts the unibyte output to multibyte using +@code{string-to-multibyte}, and inserts the resulting multibyte text. + + You can use @code{set-process-coding-system} to specify which coding +system to use (@pxref{Process Information}). Otherwise, the coding +system comes from @code{coding-system-for-read}, if that is +non-@code{nil}; or else from the defaulting mechanism (@pxref{Default +Coding Systems}). + + @strong{Warning:} Coding systems such as @code{undecided} which +determine the coding system from the data do not work entirely +reliably with asynchronous subprocess output. This is because Emacs +has to process asynchronous subprocess output in batches, as it +arrives. Emacs must try to detect the proper coding system from one +batch at a time, and this does not always work. Therefore, if at all +possible, specify a coding system that determines both the character +code conversion and the end of line conversion---that is, one like +@code{latin-1-unix}, rather than @code{undecided} or @code{latin-1}. + +@cindex filter multibyte flag, of process +@cindex process filter multibyte flag + When Emacs calls a process filter function, it provides the process +output as a multibyte string or as a unibyte string according to the +process's filter multibyte flag. If the flag is non-@code{nil}, Emacs +decodes the output according to the process output coding system to +produce a multibyte string, and passes that to the process. If the +flag is @code{nil}, Emacs puts the output into a unibyte string, with +no decoding, and passes that. + + When you create a process, the filter multibyte flag takes its +initial value from @code{default-enable-multibyte-characters}. If you +want to change the flag later on, use +@code{set-process-filter-multibyte}. + +@defun set-process-filter-multibyte process multibyte +This function sets the filter multibyte flag of @var{process} +to @var{multibyte}. +@end defun + +@defun process-filter-multibyte-p process +This function returns the filter multibyte flag of @var{process}. +@end defun + +@node Accepting Output +@subsection Accepting Output from Processes +@cindex accept input from processes + + Output from asynchronous subprocesses normally arrives only while +Emacs is waiting for some sort of external event, such as elapsed time +or terminal input. Occasionally it is useful in a Lisp program to +explicitly permit output to arrive at a specific point, or even to wait +until output arrives from a process. + +@defun accept-process-output &optional process seconds millisec just-this-one +This function allows Emacs to read pending output from processes. The +output is inserted in the associated buffers or given to their filter +functions. If @var{process} is non-@code{nil} then this function does +not return until some output has been received from @var{process}. + +@c Emacs 19 feature +The arguments @var{seconds} and @var{millisec} let you specify timeout +periods. The former specifies a period measured in seconds and the +latter specifies one measured in milliseconds. The two time periods +thus specified are added together, and @code{accept-process-output} +returns after that much time, whether or not there has been any +subprocess output. + +The argument @var{millisec} is semi-obsolete nowadays because +@var{seconds} can be a floating point number to specify waiting a +fractional number of seconds. If @var{seconds} is 0, the function +accepts whatever output is pending but does not wait. + +@c Emacs 22.1 feature +If @var{process} is a process, and the argument @var{just-this-one} is +non-@code{nil}, only output from that process is handled, suspending output +from other processes until some output has been received from that +process or the timeout expires. If @var{just-this-one} is an integer, +also inhibit running timers. This feature is generally not +recommended, but may be necessary for specific applications, such as +speech synthesis. + +The function @code{accept-process-output} returns non-@code{nil} if it +did get some output, or @code{nil} if the timeout expired before output +arrived. +@end defun + +@node Sentinels +@section Sentinels: Detecting Process Status Changes +@cindex process sentinel +@cindex sentinel (of process) + + A @dfn{process sentinel} is a function that is called whenever the +associated process changes status for any reason, including signals +(whether sent by Emacs or caused by the process's own actions) that +terminate, stop, or continue the process. The process sentinel is +also called if the process exits. The sentinel receives two +arguments: the process for which the event occurred, and a string +describing the type of event. + + The string describing the event looks like one of the following: + +@itemize @bullet +@item +@code{"finished\n"}. + +@item +@code{"exited abnormally with code @var{exitcode}\n"}. + +@item +@code{"@var{name-of-signal}\n"}. + +@item +@code{"@var{name-of-signal} (core dumped)\n"}. +@end itemize + + A sentinel runs only while Emacs is waiting (e.g., for terminal +input, or for time to elapse, or for process output). This avoids the +timing errors that could result from running them at random places in +the middle of other Lisp programs. A program can wait, so that +sentinels will run, by calling @code{sit-for} or @code{sleep-for} +(@pxref{Waiting}), or @code{accept-process-output} (@pxref{Accepting +Output}). Emacs also allows sentinels to run when the command loop is +reading input. @code{delete-process} calls the sentinel when it +terminates a running process. + + Emacs does not keep a queue of multiple reasons to call the sentinel +of one process; it records just the current status and the fact that +there has been a change. Therefore two changes in status, coming in +quick succession, can call the sentinel just once. However, process +termination will always run the sentinel exactly once. This is +because the process status can't change again after termination. + + Emacs explicitly checks for output from the process before running +the process sentinel. Once the sentinel runs due to process +termination, no further output can arrive from the process. + + A sentinel that writes the output into the buffer of the process +should check whether the buffer is still alive. If it tries to insert +into a dead buffer, it will get an error. If the buffer is dead, +@code{(buffer-name (process-buffer @var{process}))} returns @code{nil}. + + Quitting is normally inhibited within a sentinel---otherwise, the +effect of typing @kbd{C-g} at command level or to quit a user command +would be unpredictable. If you want to permit quitting inside a +sentinel, bind @code{inhibit-quit} to @code{nil}. In most cases, the +right way to do this is with the macro @code{with-local-quit}. +@xref{Quitting}. + + If an error happens during execution of a sentinel, it is caught +automatically, so that it doesn't stop the execution of whatever +programs was running when the sentinel was started. However, if +@code{debug-on-error} is non-@code{nil}, the error-catching is turned +off. This makes it possible to use the Lisp debugger to debug the +sentinel. @xref{Debugger}. + + While a sentinel is running, the process sentinel is temporarily +set to @code{nil} so that the sentinel won't run recursively. +For this reason it is not possible for a sentinel to specify +a new sentinel. + + In earlier Emacs versions, every sentinel that did regular expression +searching or matching had to explicitly save and restore the match data. +Now Emacs does this automatically for sentinels; they never need to do +it explicitly. @xref{Match Data}. + +@defun set-process-sentinel process sentinel +This function associates @var{sentinel} with @var{process}. If +@var{sentinel} is @code{nil}, then the process will have no sentinel. +The default behavior when there is no sentinel is to insert a message in +the process's buffer when the process status changes. + +Changes in process sentinel take effect immediately---if the sentinel +is slated to be run but has not been called yet, and you specify a new +sentinel, the eventual call to the sentinel will use the new one. + +@smallexample +@group +(defun msg-me (process event) + (princ + (format "Process: %s had the event `%s'" process event))) +(set-process-sentinel (get-process "shell") 'msg-me) + @result{} msg-me +@end group +@group +(kill-process (get-process "shell")) + @print{} Process: # had the event `killed' + @result{} # +@end group +@end smallexample +@end defun + +@defun process-sentinel process +This function returns the sentinel of @var{process}, or @code{nil} if it +has none. +@end defun + +@defun waiting-for-user-input-p +While a sentinel or filter function is running, this function returns +non-@code{nil} if Emacs was waiting for keyboard input from the user at +the time the sentinel or filter function was called, @code{nil} if it +was not. +@end defun + +@node Query Before Exit +@section Querying Before Exit + + When Emacs exits, it terminates all its subprocesses by sending them +the @code{SIGHUP} signal. Because subprocesses may be doing +valuable work, Emacs normally asks the user to confirm that it is ok +to terminate them. Each process has a query flag which, if +non-@code{nil}, says that Emacs should ask for confirmation before +exiting and thus killing that process. The default for the query flag +is @code{t}, meaning @emph{do} query. + +@defun process-query-on-exit-flag process +This returns the query flag of @var{process}. +@end defun + +@defun set-process-query-on-exit-flag process flag +This function sets the query flag of @var{process} to @var{flag}. It +returns @var{flag}. + +@smallexample +@group +;; @r{Don't query about the shell process} +(set-process-query-on-exit-flag (get-process "shell") nil) + @result{} t +@end group +@end smallexample +@end defun + +@defun process-kill-without-query process &optional do-query +This function clears the query flag of @var{process}, so that +Emacs will not query the user on account of that process. + +Actually, the function does more than that: it returns the old value of +the process's query flag, and sets the query flag to @var{do-query}. +Please don't use this function to do those things any more---please +use the newer, cleaner functions @code{process-query-on-exit-flag} and +@code{set-process-query-on-exit-flag} in all but the simplest cases. +The only way you should use @code{process-kill-without-query} nowadays +is like this: + +@smallexample +@group +;; @r{Don't query about the shell process} +(process-kill-without-query (get-process "shell")) +@end group +@end smallexample +@end defun + +@node Transaction Queues +@section Transaction Queues +@cindex transaction queue + +You can use a @dfn{transaction queue} to communicate with a subprocess +using transactions. First use @code{tq-create} to create a transaction +queue communicating with a specified process. Then you can call +@code{tq-enqueue} to send a transaction. + +@defun tq-create process +This function creates and returns a transaction queue communicating with +@var{process}. The argument @var{process} should be a subprocess +capable of sending and receiving streams of bytes. It may be a child +process, or it may be a TCP connection to a server, possibly on another +machine. +@end defun + +@defun tq-enqueue queue question regexp closure fn &optional delay-question +This function sends a transaction to queue @var{queue}. Specifying the +queue has the effect of specifying the subprocess to talk to. + +The argument @var{question} is the outgoing message that starts the +transaction. The argument @var{fn} is the function to call when the +corresponding answer comes back; it is called with two arguments: +@var{closure}, and the answer received. + +The argument @var{regexp} is a regular expression that should match +text at the end of the entire answer, but nothing before; that's how +@code{tq-enqueue} determines where the answer ends. + +If the argument @var{delay-question} is non-nil, delay sending this +question until the process has finished replying to any previous +questions. This produces more reliable results with some processes. + +The return value of @code{tq-enqueue} itself is not meaningful. +@end defun + +@defun tq-close queue +Shut down transaction queue @var{queue}, waiting for all pending transactions +to complete, and then terminate the connection or child process. +@end defun + +Transaction queues are implemented by means of a filter function. +@xref{Filter Functions}. + +@node Network +@section Network Connections +@cindex network connection +@cindex TCP +@cindex UDP + + Emacs Lisp programs can open stream (TCP) and datagram (UDP) network +connections to other processes on the same machine or other machines. +A network connection is handled by Lisp much like a subprocess, and is +represented by a process object. However, the process you are +communicating with is not a child of the Emacs process, so it has no +process @acronym{ID}, and you can't kill it or send it signals. All you +can do is send and receive data. @code{delete-process} closes the +connection, but does not kill the program at the other end; that +program must decide what to do about closure of the connection. + + Lisp programs can listen for connections by creating network +servers. A network server is also represented by a kind of process +object, but unlike a network connection, the network server never +transfers data itself. When it receives a connection request, it +creates a new network connection to represent the connection just +made. (The network connection inherits certain information, including +the process plist, from the server.) The network server then goes +back to listening for more connection requests. + + Network connections and servers are created by calling +@code{make-network-process} with an argument list consisting of +keyword/argument pairs, for example @code{:server t} to create a +server process, or @code{:type 'datagram} to create a datagram +connection. @xref{Low-Level Network}, for details. You can also use +the @code{open-network-stream} function described below. + + You can distinguish process objects representing network connections +and servers from those representing subprocesses with the +@code{process-status} function. The possible status values for +network connections are @code{open}, @code{closed}, @code{connect}, +and @code{failed}. For a network server, the status is always +@code{listen}. None of those values is possible for a real +subprocess. @xref{Process Information}. + + You can stop and resume operation of a network process by calling +@code{stop-process} and @code{continue-process}. For a server +process, being stopped means not accepting new connections. (Up to 5 +connection requests will be queued for when you resume the server; you +can increase this limit, unless it is imposed by the operating +system.) For a network stream connection, being stopped means not +processing input (any arriving input waits until you resume the +connection). For a datagram connection, some number of packets may be +queued but input may be lost. You can use the function +@code{process-command} to determine whether a network connection or +server is stopped; a non-@code{nil} value means yes. + +@defun open-network-stream name buffer-or-name host service +This function opens a TCP connection, and returns a process object +that represents the connection. + +The @var{name} argument specifies the name for the process object. It +is modified as necessary to make it unique. + +The @var{buffer-or-name} argument is the buffer to associate with the +connection. Output from the connection is inserted in the buffer, +unless you specify a filter function to handle the output. If +@var{buffer-or-name} is @code{nil}, it means that the connection is not +associated with any buffer. + +The arguments @var{host} and @var{service} specify where to connect to; +@var{host} is the host name (a string), and @var{service} is the name of +a defined network service (a string) or a port number (an integer). +@end defun + +@defun process-contact process &optional key +This function returns information about how a network process was set +up. For a connection, when @var{key} is @code{nil}, it returns +@code{(@var{hostname} @var{service})} which specifies what you +connected to. + +If @var{key} is @code{t}, the value is the complete status information +for the connection or server; that is, the list of keywords and values +specified in @code{make-network-process}, except that some of the +values represent the current status instead of what you specified: + +@table @code +@item :buffer +The associated value is the process buffer. +@item :filter +The associated value is the process filter function. +@item :sentinel +The associated value is the process sentinel function. +@item :remote +In a connection, the address in internal format of the remote peer. +@item :local +The local address, in internal format. +@item :service +In a server, if you specified @code{t} for @var{service}, +this value is the actual port number. +@end table + +@code{:local} and @code{:remote} are included even if they were not +specified explicitly in @code{make-network-process}. + +If @var{key} is a keyword, the function returns the value corresponding +to that keyword. + +For an ordinary child process, this function always returns @code{t}. +@end defun + +@node Network Servers +@section Network Servers +@cindex network servers + + You create a server by calling @code{make-network-process} with +@code{:server t}. The server will listen for connection requests from +clients. When it accepts a client connection request, that creates a +new network connection, itself a process object, with the following +parameters: + +@itemize @bullet +@item +The connection's process name is constructed by concatenating the +server process' @var{name} with a client identification string. The +client identification string for an IPv4 connection looks like +@samp{<@var{a}.@var{b}.@var{c}.@var{d}:@var{p}>}. Otherwise, it is a +unique number in brackets, as in @samp{<@var{nnn}>}. The number +is unique for each connection in the Emacs session. + +@item +If the server's filter is non-@code{nil}, the connection process does +not get a separate process buffer; otherwise, Emacs creates a new +buffer for the purpose. The buffer name is the server's buffer name +or process name, concatenated with the client identification string. + +The server's process buffer value is never used directly by Emacs, but +it is passed to the log function, which can log connections by +inserting text there. + +@item +The communication type and the process filter and sentinel are +inherited from those of the server. The server never directly +uses its filter and sentinel; their sole purpose is to initialize +connections made to the server. + +@item +The connection's process contact info is set according to the client's +addressing information (typically an IP address and a port number). +This information is associated with the @code{process-contact} +keywords @code{:host}, @code{:service}, @code{:remote}. + +@item +The connection's local address is set up according to the port +number used for the connection. + +@item +The client process' plist is initialized from the server's plist. +@end itemize + +@node Datagrams +@section Datagrams +@cindex datagrams + + A datagram connection communicates with individual packets rather +than streams of data. Each call to @code{process-send} sends one +datagram packet (@pxref{Input to Processes}), and each datagram +received results in one call to the filter function. + + The datagram connection doesn't have to talk with the same remote +peer all the time. It has a @dfn{remote peer address} which specifies +where to send datagrams to. Each time an incoming datagram is passed +to the filter function, the peer address is set to the address that +datagram came from; that way, if the filter function sends a datagram, +it will go back to that place. You can specify the remote peer +address when you create the datagram connection using the +@code{:remote} keyword. You can change it later on by calling +@code{set-process-datagram-address}. + +@defun process-datagram-address process +If @var{process} is a datagram connection or server, this function +returns its remote peer address. +@end defun + +@defun set-process-datagram-address process address +If @var{process} is a datagram connection or server, this function +sets its remote peer address to @var{address}. +@end defun + +@node Low-Level Network +@section Low-Level Network Access + + You can also create network connections by operating at a lower +level than that of @code{open-network-stream}, using +@code{make-network-process}. + +@menu +* Proc: Network Processes. Using @code{make-network-process}. +* Options: Network Options. Further control over network connections. +* Features: Network Feature Testing. + Determining which network features work on + the machine you are using. +@end menu + +@node Network Processes +@subsection @code{make-network-process} + + The basic function for creating network connections and network +servers is @code{make-network-process}. It can do either of those +jobs, depending on the arguments you give it. + +@defun make-network-process &rest args +This function creates a network connection or server and returns the +process object that represents it. The arguments @var{args} are a +list of keyword/argument pairs. Omitting a keyword is always +equivalent to specifying it with value @code{nil}, except for +@code{:coding}, @code{:filter-multibyte}, and @code{:reuseaddr}. Here +are the meaningful keywords: + +@table @asis +@item :name @var{name} +Use the string @var{name} as the process name. It is modified if +necessary to make it unique. + +@item :type @var{type} +Specify the communication type. A value of @code{nil} specifies a +stream connection (the default); @code{datagram} specifies a datagram +connection. Both connections and servers can be of either type. + +@item :server @var{server-flag} +If @var{server-flag} is non-@code{nil}, create a server. Otherwise, +create a connection. For a stream type server, @var{server-flag} may +be an integer which then specifies the length of the queue of pending +connections to the server. The default queue length is 5. + +@item :host @var{host} +Specify the host to connect to. @var{host} should be a host name or +Internet address, as a string, or the symbol @code{local} to specify +the local host. If you specify @var{host} for a server, it must +specify a valid address for the local host, and only clients +connecting to that address will be accepted. + +@item :service @var{service} +@var{service} specifies a port number to connect to, or, for a server, +the port number to listen on. It should be a service name that +translates to a port number, or an integer specifying the port number +directly. For a server, it can also be @code{t}, which means to let +the system select an unused port number. + +@item :family @var{family} +@var{family} specifies the address (and protocol) family for +communication. @code{nil} means determine the proper address family +automatically for the given @var{host} and @var{service}. +@code{local} specifies a Unix socket, in which case @var{host} is +ignored. @code{ipv4} and @code{ipv6} specify to use IPv4 and IPv6 +respectively. + +@item :local @var{local-address} +For a server process, @var{local-address} is the address to listen on. +It overrides @var{family}, @var{host} and @var{service}, and you +may as well not specify them. + +@item :remote @var{remote-address} +For a connection, @var{remote-address} is the address to connect to. +It overrides @var{family}, @var{host} and @var{service}, and you +may as well not specify them. + +For a datagram server, @var{remote-address} specifies the initial +setting of the remote datagram address. + +The format of @var{local-address} or @var{remote-address} depends on +the address family: + +@itemize - +@item +An IPv4 address is represented as a five-element vector of four 8-bit +integers and one 16-bit integer +@code{[@var{a} @var{b} @var{c} @var{d} @var{p}]} corresponding to +numeric IPv4 address @var{a}.@var{b}.@var{c}.@var{d} and port number +@var{p}. + +@item +An IPv6 address is represented as a nine-element vector of 16-bit +integers @code{[@var{a} @var{b} @var{c} @var{d} @var{e} @var{f} +@var{g} @var{h} @var{p}]} corresponding to numeric IPv6 address +@var{a}:@var{b}:@var{c}:@var{d}:@var{e}:@var{f}:@var{g}:@var{h} and +port number @var{p}. + +@item +A local address is represented as a string which specifies the address +in the local address space. + +@item +An ``unsupported family'' address is represented by a cons +@code{(@var{f} . @var{av})}, where @var{f} is the family number and +@var{av} is a vector specifying the socket address using one element +per address data byte. Do not rely on this format in portable code, +as it may depend on implementation defined constants, data sizes, and +data structure alignment. +@end itemize + +@item :nowait @var{bool} +If @var{bool} is non-@code{nil} for a stream connection, return +without waiting for the connection to complete. When the connection +succeeds or fails, Emacs will call the sentinel function, with a +second argument matching @code{"open"} (if successful) or +@code{"failed"}. The default is to block, so that +@code{make-network-process} does not return until the connection +has succeeded or failed. + +@item :stop @var{stopped} +Start the network connection or server in the `stopped' state if +@var{stopped} is non-@code{nil}. + +@item :buffer @var{buffer} +Use @var{buffer} as the process buffer. + +@item :coding @var{coding} +Use @var{coding} as the coding system for this process. To specify +different coding systems for decoding data from the connection and for +encoding data sent to it, specify @code{(@var{decoding} . +@var{encoding})} for @var{coding}. + +If you don't specify this keyword at all, the default +is to determine the coding systems from the data. + +@item :noquery @var{query-flag} +Initialize the process query flag to @var{query-flag}. +@xref{Query Before Exit}. + +@item :filter @var{filter} +Initialize the process filter to @var{filter}. + +@item :filter-multibyte @var{bool} +If @var{bool} is non-@code{nil}, strings given to the process filter +are multibyte, otherwise they are unibyte. If you don't specify this +keyword at all, the default is that the strings are multibyte if +@code{default-enable-multibyte-characters} is non-@code{nil}. + +@item :sentinel @var{sentinel} +Initialize the process sentinel to @var{sentinel}. + +@item :log @var{log} +Initialize the log function of a server process to @var{log}. The log +function is called each time the server accepts a network connection +from a client. The arguments passed to the log function are +@var{server}, @var{connection}, and @var{message}, where @var{server} +is the server process, @var{connection} is the new process for the +connection, and @var{message} is a string describing what has +happened. + +@item :plist @var{plist} +Initialize the process plist to @var{plist}. +@end table + +The original argument list, modified with the actual connection +information, is available via the @code{process-contact} function. +@end defun + +@node Network Options +@subsection Network Options + + The following network options can be specified when you create a +network process. Except for @code{:reuseaddr}, you can also set or +modify these options later, using @code{set-network-process-option}. + + For a server process, the options specified with +@code{make-network-process} are not inherited by the client +connections, so you will need to set the necessary options for each +child connection as it is created. + +@table @asis +@item :bindtodevice @var{device-name} +If @var{device-name} is a non-empty string identifying a network +interface name (see @code{network-interface-list}), only handle +packets received on that interface. If @var{device-name} is @code{nil} +(the default), handle packets received on any interface. + +Using this option may require special privileges on some systems. + +@item :broadcast @var{broadcast-flag} +If @var{broadcast-flag} is non-@code{nil} for a datagram process, the +process will receive datagram packet sent to a broadcast address, and +be able to send packets to a broadcast address. Ignored for a stream +connection. + +@item :dontroute @var{dontroute-flag} +If @var{dontroute-flag} is non-@code{nil}, the process can only send +to hosts on the same network as the local host. + +@item :keepalive @var{keepalive-flag} +If @var{keepalive-flag} is non-@code{nil} for a stream connection, +enable exchange of low-level keep-alive messages. + +@item :linger @var{linger-arg} +If @var{linger-arg} is non-@code{nil}, wait for successful +transmission of all queued packets on the connection before it is +deleted (see @code{delete-process}). If @var{linger-arg} is an +integer, it specifies the maximum time in seconds to wait for queued +packets to be sent before closing the connection. Default is +@code{nil} which means to discard unsent queued packets when the +process is deleted. + +@item :oobinline @var{oobinline-flag} +If @var{oobinline-flag} is non-@code{nil} for a stream connection, +receive out-of-band data in the normal data stream. Otherwise, ignore +out-of-band data. + +@item :priority @var{priority} +Set the priority for packets sent on this connection to the integer +@var{priority}. The interpretation of this number is protocol +specific, such as setting the TOS (type of service) field on IP +packets sent on this connection. It may also have system dependent +effects, such as selecting a specific output queue on the network +interface. + +@item :reuseaddr @var{reuseaddr-flag} +If @var{reuseaddr-flag} is non-@code{nil} (the default) for a stream +server process, allow this server to reuse a specific port number (see +@code{:service}) unless another process on this host is already +listening on that port. If @var{reuseaddr-flag} is @code{nil}, there +may be a period of time after the last use of that port (by any +process on the host), where it is not possible to make a new server on +that port. +@end table + +@defun set-network-process-option process option value +This function sets or modifies a network option for network process +@var{process}. See @code{make-network-process} for details of options +@var{option} and their corresponding values @var{value}. + +The current setting of an option is available via the +@code{process-contact} function. +@end defun + +@node Network Feature Testing +@subsection Testing Availability of Network Features + + To test for the availability of a given network feature, use +@code{featurep} like this: + +@example +(featurep 'make-network-process '(@var{keyword} @var{value})) +@end example + +@noindent +The result of the first form is @code{t} if it works to specify +@var{keyword} with value @var{value} in @code{make-network-process}. +The result of the second form is @code{t} if @var{keyword} is +supported by @code{make-network-process}. Here are some of the +@var{keyword}---@var{value} pairs you can test in +this way. + +@table @code +@item (:nowait t) +Non-@code{nil} if non-blocking connect is supported. +@item (:type datagram) +Non-@code{nil} if datagrams are supported. +@item (:family local) +Non-@code{nil} if local (a.k.a.@: ``UNIX domain'') sockets are supported. +@item (:family ipv6) +Non-@code{nil} if IPv6 is supported. +@item (:service t) +Non-@code{nil} if the system can select the port for a server. +@end table + + To test for the availability of a given network option, use +@code{featurep} like this: + +@example +(featurep 'make-network-process '@var{keyword}) +@end example + +@noindent +Here are some of the options you can test in this way. + +@table @code +@item :bindtodevice +@itemx :broadcast +@itemx :dontroute +@itemx :keepalive +@itemx :linger +@itemx :oobinline +@itemx :priority +@itemx :reuseaddr +That particular network option is supported by +@code{make-network-process} and @code{set-network-process-option}. +@end table + +@node Misc Network +@section Misc Network Facilities + + These additional functions are useful for creating and operating +on network connections. + +@defun network-interface-list +This function returns a list describing the network interfaces +of the machine you are using. The value is an alist whose +elements have the form @code{(@var{name} . @var{address})}. +@var{address} has the same form as the @var{local-address} +and @var{remote-address} arguments to @code{make-network-process}. +@end defun + +@defun network-interface-info ifname +This function returns information about the network interface named +@var{ifname}. The value is a list of the form +@code{(@var{addr} @var{bcast} @var{netmask} @var{hwaddr} @var{flags})}. + +@table @var +@item addr +The Internet protocol address. +@item bcast +The broadcast address. +@item netmask +The network mask. +@item hwaddr +The layer 2 address (Ethernet MAC address, for instance). +@item flags +The current flags of the interface. +@end table +@end defun + +@defun format-network-address address &optional omit-port +This function converts the Lisp representation of a network address to +a string. + +A five-element vector @code{[@var{a} @var{b} @var{c} @var{d} @var{p}]} +represents an IPv4 address @var{a}.@var{b}.@var{c}.@var{d} and port +number @var{p}. @code{format-network-address} converts that to the +string @code{"@var{a}.@var{b}.@var{c}.@var{d}:@var{p}"}. + +A nine-element vector @code{[@var{a} @var{b} @var{c} @var{d} @var{e} +@var{f} @var{g} @var{h} @var{p}]} represents an IPv6 address along +with a port number. @code{format-network-address} converts that to +the string +@code{"[@var{a}:@var{b}:@var{c}:@var{d}:@var{e}:@var{f}:@var{g}:@var{h}]:@var{p}"}. + +If the vector does not include the port number, @var{p}, or if +@var{omit-port} is non-@code{nil}, the result does not include the +@code{:@var{p}} suffix. +@end defun + +@node Byte Packing +@section Packing and Unpacking Byte Arrays +@cindex byte packing and unpacking + + This section describes how to pack and unpack arrays of bytes, +usually for binary network protocols. These functions convert byte arrays +to alists, and vice versa. The byte array can be represented as a +unibyte string or as a vector of integers, while the alist associates +symbols either with fixed-size objects or with recursive sub-alists. + +@cindex serializing +@cindex deserializing +@cindex packing +@cindex unpacking + Conversion from byte arrays to nested alists is also known as +@dfn{deserializing} or @dfn{unpacking}, while going in the opposite +direction is also known as @dfn{serializing} or @dfn{packing}. + +@menu +* Bindat Spec:: Describing data layout. +* Bindat Functions:: Doing the unpacking and packing. +* Bindat Examples:: Samples of what bindat.el can do for you! +@end menu + +@node Bindat Spec +@subsection Describing Data Layout + + To control unpacking and packing, you write a @dfn{data layout +specification}, a special nested list describing named and typed +@dfn{fields}. This specification controls length of each field to be +processed, and how to pack or unpack it. We normally keep bindat specs +in variables whose names end in @samp{-bindat-spec}; that kind of name +is automatically recognized as ``risky.'' + +@cindex endianness +@cindex big endian +@cindex little endian +@cindex network byte ordering + A field's @dfn{type} describes the size (in bytes) of the object +that the field represents and, in the case of multibyte fields, how +the bytes are ordered within the field. The two possible orderings +are ``big endian'' (also known as ``network byte ordering'') and +``little endian.'' For instance, the number @code{#x23cd} (decimal +9165) in big endian would be the two bytes @code{#x23} @code{#xcd}; +and in little endian, @code{#xcd} @code{#x23}. Here are the possible +type values: + +@table @code +@item u8 +@itemx byte +Unsigned byte, with length 1. + +@item u16 +@itemx word +@itemx short +Unsigned integer in network byte order, with length 2. + +@item u24 +Unsigned integer in network byte order, with length 3. + +@item u32 +@itemx dword +@itemx long +Unsigned integer in network byte order, with length 4. +Note: These values may be limited by Emacs' integer implementation limits. + +@item u16r +@itemx u24r +@itemx u32r +Unsigned integer in little endian order, with length 2, 3 and 4, respectively. + +@item str @var{len} +String of length @var{len}. + +@item strz @var{len} +Zero-terminated string, in a fixed-size field with length @var{len}. + +@item vec @var{len} [@var{type}] +Vector of @var{len} elements of type @var{type}, or bytes if not +@var{type} is specified. +The @var{type} is any of the simple types above, or another vector +specified as a list @code{(vec @var{len} [@var{type}])}. + +@item ip +Four-byte vector representing an Internet address. For example: +@code{[127 0 0 1]} for localhost. + +@item bits @var{len} +List of set bits in @var{len} bytes. The bytes are taken in big +endian order and the bits are numbered starting with @code{8 * +@var{len} @minus{} 1} and ending with zero. For example: @code{bits +2} unpacks @code{#x28} @code{#x1c} to @code{(2 3 4 11 13)} and +@code{#x1c} @code{#x28} to @code{(3 5 10 11 12)}. + +@item (eval @var{form}) +@var{form} is a Lisp expression evaluated at the moment the field is +unpacked or packed. The result of the evaluation should be one of the +above-listed type specifications. +@end table + +For a fixed-size field, the length @var{len} is given as an integer +specifying the number of bytes in the field. + +When the length of a field is not fixed, it typically depends on the +value of a preceding field. In this case, the length @var{len} can be +given either as a list @code{(@var{name} ...)} identifying a +@dfn{field name} in the format specified for @code{bindat-get-field} +below, or by an expression @code{(eval @var{form})} where @var{form} +should evaluate to an integer, specifying the field length. + +A field specification generally has the form @code{([@var{name}] +@var{handler})}. The square braces indicate that @var{name} is +optional. (Don't use names that are symbols meaningful as type +specifications (above) or handler specifications (below), since that +would be ambiguous.) @var{name} can be a symbol or the expression +@code{(eval @var{form})}, in which case @var{form} should evaluate to +a symbol. + +@var{handler} describes how to unpack or pack the field and can be one +of the following: + +@table @code +@item @var{type} +Unpack/pack this field according to the type specification @var{type}. + +@item eval @var{form} +Evaluate @var{form}, a Lisp expression, for side-effect only. If the +field name is specified, the value is bound to that field name. + +@item fill @var{len} +Skip @var{len} bytes. In packing, this leaves them unchanged, +which normally means they remain zero. In unpacking, this means +they are ignored. + +@item align @var{len} +Skip to the next multiple of @var{len} bytes. + +@item struct @var{spec-name} +Process @var{spec-name} as a sub-specification. This describes a +structure nested within another structure. + +@item union @var{form} (@var{tag} @var{spec})@dots{} +@c ??? I don't see how one would actually use this. +@c ??? what kind of expression would be useful for @var{form}? +Evaluate @var{form}, a Lisp expression, find the first @var{tag} +that matches it, and process its associated data layout specification +@var{spec}. Matching can occur in one of three ways: + +@itemize +@item +If a @var{tag} has the form @code{(eval @var{expr})}, evaluate +@var{expr} with the variable @code{tag} dynamically bound to the value +of @var{form}. A non-@code{nil} result indicates a match. + +@item +@var{tag} matches if it is @code{equal} to the value of @var{form}. + +@item +@var{tag} matches unconditionally if it is @code{t}. +@end itemize + +@item repeat @var{count} @var{field-specs}@dots{} +Process the @var{field-specs} recursively, in order, then repeat +starting from the first one, processing all the specs @var{count} +times overall. The @var{count} is given using the same formats as a +field length---if an @code{eval} form is used, it is evaluated just once. +For correct operation, each spec in @var{field-specs} must include a name. +@end table + +For the @code{(eval @var{form})} forms used in a bindat specification, +the @var{form} can access and update these dynamically bound variables +during evaluation: + +@table @code +@item last +Value of the last field processed. + +@item bindat-raw +The data as a byte array. + +@item bindat-idx +Current index (within @code{bindat-raw}) for unpacking or packing. + +@item struct +The alist containing the structured data that have been unpacked so +far, or the entire structure being packed. You can use +@code{bindat-get-field} to access specific fields of this structure. + +@item count +@itemx index +Inside a @code{repeat} block, these contain the maximum number of +repetitions (as specified by the @var{count} parameter), and the +current repetition number (counting from 0). Setting @code{count} to +zero will terminate the inner-most repeat block after the current +repetition has completed. +@end table + +@node Bindat Functions +@subsection Functions to Unpack and Pack Bytes + + In the following documentation, @var{spec} refers to a data layout +specification, @code{bindat-raw} to a byte array, and @var{struct} to an +alist representing unpacked field data. + +@defun bindat-unpack spec bindat-raw &optional bindat-idx +This function unpacks data from the unibyte string or byte +array @code{bindat-raw} +according to @var{spec}. Normally this starts unpacking at the +beginning of the byte array, but if @var{bindat-idx} is non-@code{nil}, it +specifies a zero-based starting position to use instead. + +The value is an alist or nested alist in which each element describes +one unpacked field. +@end defun + +@defun bindat-get-field struct &rest name +This function selects a field's data from the nested alist +@var{struct}. Usually @var{struct} was returned by +@code{bindat-unpack}. If @var{name} corresponds to just one argument, +that means to extract a top-level field value. Multiple @var{name} +arguments specify repeated lookup of sub-structures. An integer name +acts as an array index. + +For example, if @var{name} is @code{(a b 2 c)}, that means to find +field @code{c} in the third element of subfield @code{b} of field +@code{a}. (This corresponds to @code{struct.a.b[2].c} in C.) +@end defun + + Although packing and unpacking operations change the organization of +data (in memory), they preserve the data's @dfn{total length}, which is +the sum of all the fields' lengths, in bytes. This value is not +generally inherent in either the specification or alist alone; instead, +both pieces of information contribute to its calculation. Likewise, the +length of a string or array being unpacked may be longer than the data's +total length as described by the specification. + +@defun bindat-length spec struct +This function returns the total length of the data in @var{struct}, +according to @var{spec}. +@end defun + +@defun bindat-pack spec struct &optional bindat-raw bindat-idx +This function returns a byte array packed according to @var{spec} from +the data in the alist @var{struct}. Normally it creates and fills a +new byte array starting at the beginning. However, if @var{bindat-raw} +is non-@code{nil}, it specifies a pre-allocated unibyte string or vector to +pack into. If @var{bindat-idx} is non-@code{nil}, it specifies the starting +offset for packing into @code{bindat-raw}. + +When pre-allocating, you should make sure @code{(length @var{bindat-raw})} +meets or exceeds the total length to avoid an out-of-range error. +@end defun + +@defun bindat-ip-to-string ip +Convert the Internet address vector @var{ip} to a string in the usual +dotted notation. + +@example +(bindat-ip-to-string [127 0 0 1]) + @result{} "127.0.0.1" +@end example +@end defun + +@node Bindat Examples +@subsection Examples of Byte Unpacking and Packing + + Here is a complete example of byte unpacking and packing: + +@lisp +(defvar fcookie-index-spec + '((:version u32) + (:count u32) + (:longest u32) + (:shortest u32) + (:flags u32) + (:delim u8) + (:ignored fill 3) + (:offset repeat (:count) + (:foo u32))) + "Description of a fortune cookie index file's contents.") + +(defun fcookie (cookies &optional index) + "Display a random fortune cookie from file COOKIES. +Optional second arg INDEX specifies the associated index +filename, which is by default constructed by appending +\".dat\" to COOKIES. Display cookie text in possibly +new buffer \"*Fortune Cookie: BASENAME*\" where BASENAME +is COOKIES without the directory part." + (interactive "fCookies file: ") + (let* ((info (with-temp-buffer + (insert-file-contents-literally + (or index (concat cookies ".dat"))) + (bindat-unpack fcookie-index-spec + (buffer-string)))) + (sel (random (bindat-get-field info :count))) + (beg (cdar (bindat-get-field info :offset sel))) + (end (or (cdar (bindat-get-field info + :offset (1+ sel))) + (nth 7 (file-attributes cookies))))) + (switch-to-buffer + (get-buffer-create + (format "*Fortune Cookie: %s*" + (file-name-nondirectory cookies)))) + (erase-buffer) + (insert-file-contents-literally + cookies nil beg (- end 3)))) + +(defun fcookie-create-index (cookies &optional index delim) + "Scan file COOKIES, and write out its index file. +Optional second arg INDEX specifies the index filename, +which is by default constructed by appending \".dat\" to +COOKIES. Optional third arg DELIM specifies the unibyte +character which, when found on a line of its own in +COOKIES, indicates the border between entries." + (interactive "fCookies file: ") + (setq delim (or delim ?%)) + (let ((delim-line (format "\n%c\n" delim)) + (count 0) + (max 0) + min p q len offsets) + (unless (= 3 (string-bytes delim-line)) + (error "Delimiter cannot be represented in one byte")) + (with-temp-buffer + (insert-file-contents-literally cookies) + (while (and (setq p (point)) + (search-forward delim-line (point-max) t) + (setq len (- (point) 3 p))) + (setq count (1+ count) + max (max max len) + min (min (or min max) len) + offsets (cons (1- p) offsets)))) + (with-temp-buffer + (set-buffer-multibyte nil) + (insert + (bindat-pack + fcookie-index-spec + `((:version . 2) + (:count . ,count) + (:longest . ,max) + (:shortest . ,min) + (:flags . 0) + (:delim . ,delim) + (:offset . ,(mapcar (lambda (o) + (list (cons :foo o))) + (nreverse offsets)))))) + (let ((coding-system-for-write 'raw-text-unix)) + (write-file (or index (concat cookies ".dat"))))))) +@end lisp + +Following is an example of defining and unpacking a complex structure. +Consider the following C structures: + +@example +struct header @{ + unsigned long dest_ip; + unsigned long src_ip; + unsigned short dest_port; + unsigned short src_port; +@}; + +struct data @{ + unsigned char type; + unsigned char opcode; + unsigned short length; /* In network byte order */ + unsigned char id[8]; /* null-terminated string */ + unsigned char data[/* (length + 3) & ~3 */]; +@}; + +struct packet @{ + struct header header; + unsigned long counters[2]; /* In little endian order */ + unsigned char items; + unsigned char filler[3]; + struct data item[/* items */]; + +@}; +@end example + +The corresponding data layout specification: + +@lisp +(setq header-spec + '((dest-ip ip) + (src-ip ip) + (dest-port u16) + (src-port u16))) + +(setq data-spec + '((type u8) + (opcode u8) + (length u16) ;; network byte order + (id strz 8) + (data vec (length)) + (align 4))) + +(setq packet-spec + '((header struct header-spec) + (counters vec 2 u32r) ;; little endian order + (items u8) + (fill 3) + (item repeat (items) + (struct data-spec)))) +@end lisp + +A binary data representation: + +@lisp +(setq binary-data + [ 192 168 1 100 192 168 1 101 01 28 21 32 + 160 134 1 0 5 1 0 0 2 0 0 0 + 2 3 0 5 ?A ?B ?C ?D ?E ?F 0 0 1 2 3 4 5 0 0 0 + 1 4 0 7 ?B ?C ?D ?E ?F ?G 0 0 6 7 8 9 10 11 12 0 ]) +@end lisp + +The corresponding decoded structure: + +@lisp +(setq decoded (bindat-unpack packet-spec binary-data)) + @result{} +((header + (dest-ip . [192 168 1 100]) + (src-ip . [192 168 1 101]) + (dest-port . 284) + (src-port . 5408)) + (counters . [100000 261]) + (items . 2) + (item ((data . [1 2 3 4 5]) + (id . "ABCDEF") + (length . 5) + (opcode . 3) + (type . 2)) + ((data . [6 7 8 9 10 11 12]) + (id . "BCDEFG") + (length . 7) + (opcode . 4) + (type . 1)))) +@end lisp + +Fetching data from this structure: + +@lisp +(bindat-get-field decoded 'item 1 'id) + @result{} "BCDEFG" +@end lisp + +@ignore + arch-tag: ba9da253-e65f-4e7f-b727-08fba0a1df7a +@end ignore