Mercurial > emacs
changeset 84022:3186616a69e6
Move to ../doc/lispref
| author | Glenn Morris <rgm@gnu.org> |
|---|---|
| date | Thu, 06 Sep 2007 04:13:55 +0000 |
| parents | f35d161c52b1 |
| children | ce25544102d5 |
| files | lispref/processes.texi |
| diffstat | 1 files changed, 0 insertions(+), 2561 deletions(-) [+] |
line wrap: on
line diff
--- a/lispref/processes.texi Thu Sep 06 04:13:48 2007 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,2561 +0,0 @@ -@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{} #<process my-process> -@end group - -@group -(start-process "my-process" "foo" "ls" "-l" "/user/lewis/bin") - @result{} #<process my-process<1>> - ----------- 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{} (#<process display-time> #<process shell>) -@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{} #<process shell> -@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 xx<1>> -(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{} #<buffer *shell*> -@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{} #<process shell> -@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: #<process shell> had the event `killed' - @result{} #<process shell> -@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