@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, 2008, 2009, 2010
+@c Copyright (C) 1990-1995, 1998-1999, 2001-2012
@c Free Software Foundation, Inc.
@c See the file elisp.texi for copying conditions.
@setfilename ../../info/processes
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
+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.
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}).
+(@pxref{Synchronous Processes}). There are various higher-level
+functions that make use of these primitives to run particular types of
+process.
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
+@cindex @env{PATH} environment variable
+@cindex @env{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
+the environment variable @env{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
@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.
+must use a separate argument, @var{args}, to provide those, as
+described below.
Each of the subprocess-creating functions has a @var{buffer-or-name}
-argument which specifies where the standard output from the program will
+argument that 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.
+For synchronous processes, you can send the output to a file instead
+of a buffer.
@cindex program arguments
All three of the subprocess-creating functions have a @code{&rest}
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}.
+Environment}. The subprocess gets its current directory from the
+value of @code{default-directory}.
@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
+contains programs that come with GNU Emacs and are 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
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.
+
+Generally, you should not modify @code{exec-path} directly. Instead,
+ensure that your @env{PATH} environment variable is set appropriately
+before starting Emacs. Trying to modify @code{exec-path}
+independently of @env{PATH} can lead to confusing results.
@end defopt
@node Shell Arguments
characters, use the function @code{shell-quote-argument}:
@defun shell-quote-argument argument
-This function returns a string which represents, in shell syntax,
+This function returns a string that 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.
@end example
@end defun
-@cindex quoting and unquoting shell command line
- The following two functions are useful for creating shell commands
-from individual argument strings, and taking shell command lines apart
-into individual arguments.
+@cindex quoting and unquoting command-line arguments
+@cindex minibuffer input, and command-line arguments
+@cindex @code{call-process}, command-line arguments from minibuffer
+@cindex @code{start-process}, command-line arguments from minibuffer
+ The following two functions are useful for combining a list of
+individual command-line argument strings into a single string, and
+taking a string apart into a list of individual command-line
+arguments. These functions are mainly intended for
+converting user input in the minibuffer, a Lisp string, into a list of
+string arguments to be passed to @code{call-process} or
+@code{start-process}, or for converting such lists of arguments into
+a single Lisp string to be presented in the minibuffer or echo area.
@defun split-string-and-unquote string &optional separators
This function splits @var{string} into substrings at matches for the
@code{"\\s-+"}, which is a regular expression that matches one or more
characters with whitespace syntax (@pxref{Syntax Class Table}).
-This function performs two types of quoting: enclosing a whole string
+This function supports two types of quoting: enclosing a whole string
in double quotes @code{"@dots{}"}, and quoting individual characters
with a backslash escape @samp{\}. The latter is also used in Lisp
strings, so this function can handle those as well.
The strings in @var{list-of-strings} that need quoting are those that
include @var{separator} as their substring. Quoting a string encloses
it in double quotes @code{"@dots{}"}. In the simplest case, if you
-are consing a shell command from the individual command-line
-arguments, every argument that includes embedded blanks will be
-quoted.
+are consing a command from the individual command-line arguments,
+every argument that includes embedded blanks will be quoted.
@end defun
@node Synchronous Processes
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.
+This function calls @var{program} and waits for it to finish.
-The standard input for the process comes from file @var{infile} if
+The standard input for the new 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:
MS-DOS doesn't support asynchronous subprocesses, so this option doesn't
work there.
+@item @code{(:file @var{file-name})}
+Send the output to the file name specified, overwriting it if it
+already exists.
+
@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},
@result{} 0
---------- Buffer: foo ----------
-/usr/user/lewis/manual
+/home/lewis/manual
---------- Buffer: foo ----------
@end group
@result{} 0
---------- Buffer: bar ----------
-lewis:5LTsHm66CSWKg:398:21:Bil Lewis:/user/lewis:/bin/csh
+lewis:x:1001:1001:Bil Lewis,,,,:/home/lewis:/bin/bash
---------- 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}:
+Here is an example of the use of @code{call-process}, as used to
+be found in the definition of the @code{insert-directory} function:
@smallexample
@group
-(call-process insert-directory-program nil t nil @var{switches}
+(call-process insert-directory-program nil t nil switches
(if full-directory-p
(concat (file-name-as-directory file) ".")
file))
@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}.
+is similar to @code{call-process}, but may invoke a file handler based
+on the value of the variable @code{default-directory}, which specifies
+the current working directory of the subprocess.
The arguments are handled in almost the same way as for
@code{call-process}, with the following differences:
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
+on the first argument @var{program}. For instance, suppose 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}.
+searching for the program might be different from @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}
+@code{default-directory} could be on one remote host, and
+@var{infile} on a different 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}
@end defun
@defvar process-file-side-effects
-This variable indicates, whether a call of @code{process-file} changes
+This variable indicates whether a call of @code{process-file} changes
remote files.
-Per default, this variable is always set to @code{t}, meaning that a
+By default, this variable is always set to @code{t}, meaning that a
call of @code{process-file} could potentially change any file on a
remote host. When set to @code{nil}, a file handler could optimize
-its behaviour with respect to remote file attributes caching.
+its behavior with respect to remote file attribute caching.
-This variable should never be changed by @code{setq}. Instead of, it
-shall be set only by let-binding.
+You should only ever change this variable with a let-binding; never
+with @code{setq}.
@end defvar
@defun call-process-region start end program &optional delete destination display &rest args
@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).
+works if asynchronous subprocesses are supported; i.e. not on MS-DOS).
The remaining arguments, @var{args}, are strings that specify command
line arguments for the program.
@end group
@end smallexample
- The @code{shell-command-on-region} command uses
-@code{call-process-region} like this:
+ For example, the @code{shell-command-on-region} command uses
+@code{call-process-region} in a manner similar to 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.}
+ 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
+@c It actually uses shell-command-switch, but no need to mention that here.
@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}.
+This function executes the shell command @var{command} synchronously.
+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
then returns the command's output as a string.
@end defun
+@c There is also shell-command-on-region, but that is more of a user
+@c command, not something to use in programs.
+
@defun process-lines program &rest args
-This function runs @var{program} in a separate process, waits for it
-to finish, and returns its output as a list of strings. Each string
-in the list holds a single line of text output by the program; the
-end-of-line characters are stripped from each line. The arguments
-beyond @var{program}, @var{args}, are strings that specify
-command-line arguments with which to run the program.
+This function runs @var{program}, waits for it to finish, and returns
+its output as a list of strings. Each string in the list holds a
+single line of text output by the program; the end-of-line characters
+are stripped from each line. The arguments beyond @var{program},
+@var{args}, are strings that specify command-line arguments with which
+to run the program.
If @var{program} exits with a non-zero exit status, this function
signals an error.
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
+sleeps) for 100 seconds (the output buffer @samp{foo} is created
+immediately). 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
@end group
@group
-(start-process "my-process" "foo" "ls" "-l" "/user/lewis/bin")
+(start-process "my-process" "foo" "ls" "-l" "/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
+total 8336
+-rwxr-xr-x 1 root root 971384 Mar 30 10:14 bash
+-rwxr-xr-x 1 root root 146920 Jul 5 2011 bsd-csh
+@dots{}
+-rwxr-xr-x 1 root root 696880 Feb 28 15:55 zsh4
Process my-process<1> finished
@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.
+object.
-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.
+The difference from @code{start-process} is that this function may
+invoked a file handler based on the value of @code{default-directory}.
+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}).
+the resulting process object. @xref{Filter Functions}, and @ref{Sentinels}.
+@c FIXME Can we find a better example (i.e. a more modern function
+@c that is actually documented).
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}.
+example the function @code{ange-ftp-hook-function}). In such cases,
+this function does nothing and returns @code{nil}.
@end defun
@defun start-process-shell-command name buffer-or-name command
-This function is like @code{start-process} except that it uses a shell
+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. 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
+as wildcards in the arguments. It follows that if you include any
+arbitrary user-specified arguments in the command, you should quote them
with @code{shell-quote-argument} first, so that any special shell
characters do @emph{not} have their special shell meanings. @xref{Shell
-Arguments}.
+Arguments}. Of course, when executing commands based on user input
+you should also consider the security implications.
@end defun
@defun start-file-process-shell-command name buffer-or-name command
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}.
+@code{start-file-process} internally. Because of this, @var{command}
+can also be executed on remote hosts, depending on @code{default-directory}.
@end defun
@defvar process-connection-type
@smallexample
@group
-(let ((process-connection-type nil)) ; @r{Use a pipe.}
+(let ((process-connection-type nil)) ; @r{use a pipe}
(start-process @dots{}))
@end group
@end smallexample
@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
+at any time. If you explicitly delete a terminated process before it
is deleted automatically, no harm results. Deleting a running
-process sends a signal to terminate it (and its child processes if
+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
@section Process Information
Several functions return information about processes.
-@code{list-processes} is provided for interactive use.
-@deffn Command list-processes &optional query-only
+@deffn Command list-processes &optional query-only buffer
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
+The processes are shown in a buffer named @file{*Process List*}
+(unless you specify otherwise using the optional argument @var{buffer}),
+whose major mode is Process Menu mode.
+
+If @var{query-only} is non-@code{nil}, it only lists processes
whose query flag is non-@code{nil}. @xref{Query Before Exit}.
@end deffn
@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.
+This function returns the process named @var{name} (a string), or
+@code{nil} if there is none.
@smallexample
@group
@smallexample
@group
(process-command (get-process "shell"))
- @result{} ("/bin/csh" "-i")
+ @result{} ("bash" "-i")
@end group
@end smallexample
@end defun
@defun process-contact process &optional key
This function returns information about how a network or serial
-process was set up. For a network process, when @var{key} is
-@code{nil}, it returns @code{(@var{hostname} @var{service})} which
-specifies what you connected to. For a serial process, when @var{key}
-is @code{nil}, it returns @code{(@var{port} @var{speed})}. For an
-ordinary child process, this function always returns @code{t}.
+process was set up. When @var{key} is @code{nil}, it returns
+@code{(@var{hostname} @var{service})} for a network process, and
+@code{(@var{port} @var{speed})} for a serial process.
+For an ordinary child process, this function always returns @code{t}.
If @var{key} is @code{t}, the value is the complete status information
for the connection, server, or serial port; that is, the list of
@code{make-serial-process}, except that some of the values represent
the current status instead of what you specified.
-For a network process:
+For a network process, the values include (see
+@code{make-network-process} for a complete list):
@table @code
@item :buffer
@end defun
@defun process-name process
-This function returns the name of @var{process}.
+This function returns the name of @var{process}, as a string.
@end defun
@defun process-status process-name
(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
closed the connection, or Emacs did @code{delete-process}.
@end defun
+@defun process-live-p process
+This function returns non-@code{nil} if @var{process} is alive. A
+process is considered alive if its status is @code{run}, @code{open},
+@code{listen}, @code{connect} or @code{stop}.
+@end defun
+
@defun process-type process
This function returns the symbol @code{network} for a network
connection or server, @code{serial} for a serial port connection, or
@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
+This function returns a cons cell @code{(@var{decode} . @var{encode})},
+describing the coding systems in use for decoding output from, and
+encoding input to, @var{process} (@pxref{Coding Systems}).
@end defun
@defun set-process-coding-system process &optional decoding-system encoding-system
specify the process to send input to, and the input data to send. The
data appears on the ``standard input'' of the subprocess.
+@c FIXME which?
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
@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}.
+standard input. It returns @code{nil}. For example, to make a
+Shell buffer list files:
@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-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
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
+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.
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.)
+user ``hung up the phone'', i.e., disconnected.)
Each of the signal-sending functions takes two optional arguments:
@var{process} and @var{current-group}.
@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
+@c FIXME? Never heard of C-b being used for this. In readline, eg
+@c bash, that is backward-word.
character'' (usually @kbd{C-b} or @kbd{C-\}) when you are not inside
Emacs.
@end defun
@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.
+@var{signal} specifies which signal to send; it should be an integer,
+or a symbol whose name is a signal.
-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. @xref{System Processes}.
+The @var{process} argument can be a system process @acronym{ID} (an
+integer); that allows you to send signals to processes that are not
+children of Emacs. @xref{System Processes}.
@end defun
@node 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.
+which is called the associated buffer of the process (@pxref{Process
+Buffers}), 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
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
+by setting the variable @code{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.
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.
+as is done by direct insertion of output in the buffer. For an
+example of a filter function that uses @code{process-mark},
+@pxref{Process Filter Example}.
When the user is expected to enter input in the process buffer for
transmission to the process, the process marker separates the new input
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
+@code{debug-on-error} is non-@code{nil}, errors are not caught.
+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
+ Many filter functions sometimes (or always) insert the output 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 check whether the buffer is still
-alive, update the process marker, and in some cases update the value
-of point. Here is how to do these things:
-
+filter. Such filter functions need to make sure that they save the
+current buffer, select the correct buffer (if different) before
+inserting output, and then restore the original buffer.
+They should also check whether the buffer is still alive, update the
+process marker, and in some cases update the value of point. Here is
+how to do these things:
+
+@anchor{Process Filter Example}
@smallexample
@group
(defun ordinary-insertion-filter (proc string)
@end group
@group
(save-excursion
- ;; @r{Insert the text, advancing the process marker.}
+ ;; @r{Insert the text, advancing the process marker.}
(goto-char (process-mark proc))
(insert string)
(set-marker (process-mark proc) (point)))
@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
+text arrives, you could insert a line like the following just before the
@code{with-current-buffer} construct:
@smallexample
previously, eliminate the variable @code{moving} and call
@code{goto-char} unconditionally.
+@ignore
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}.
+they never need to do it explicitly.
+@end ignore
+ Note that Emacs automatically saves and restores the match data
+while executing filter functions. @xref{Match Data}.
- The output to the function may come in chunks of any size. A program
+ The output to the filter 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
if it has none.
@end defun
- Here is an example of use of a filter function:
+ Here is an example of the use of a filter function:
@smallexample
@group
(process-send-string "shell" "ls ~/other\n")
@result{} nil
kept
- @result{} ("lewis@@slug[8] % "
+ @result{} ("lewis@@slug:$ "
@end group
@group
"FINAL-W87-SHORT.MSS backup.otl kolstad.mss~
@ref{Lisp and Coding Systems, inhibit-null-byte-detection}, for how to
control this behavior.
- @strong{Warning:} Coding systems such as @code{undecided} which
-determine the coding system from the data do not work entirely
+ @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
process's filter coding system. Emacs
decodes the output according to the process output coding system,
which usually produces a multibyte string, except for coding systems
-such as @code{binary} and @code{raw-text}
+such as @code{binary} and @code{raw-text}.
@node Accepting Output
@subsection Accepting Output from Processes
This function sets the query flag of @var{process} to @var{flag}. It
returns @var{flag}.
+Here is an example of using @code{set-process-query-on-exit-flag} on a
+shell process to avoid querying:
+
@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 System Processes
@section Accessing Other Processes
@cindex system processes
The number of threads in the process.
@item start
-The time the process was started, in the @w{@code{(@var{high}
-@var{low} @var{microsec})}} format used by @code{current-time} and
-@code{file-attributes}.
+The time when the process was started, in the same
+@w{@code{(@var{high} @var{low} @var{microsec})}} format used by
+@code{current-time} and @code{file-attributes}.
@item etime
The time elapsed since the process started, in the @w{@code{(@var{high}
@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.
+@cindex network connection, encrypted
+@cindex encrypted network connections
+@cindex TLS network connections
+@cindex STARTTLS network connections
+@defun open-network-stream name buffer-or-name host service &rest parameters
+This function opens a TCP connection, with optional encryption, 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 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).
+
+@c FIXME? Is this too lengthy for the printed manual?
+The remaining arguments @var{parameters} are keyword/argument pairs
+that are mainly relevant to encrypted connections:
+
+@table @code
+
+@item :nowait @var{boolean}
+If non-@code{nil}, try to make an asynchronous connection.
+
+@item :type @var{type}
+The type of connection. Options are:
+
+@table @code
+@item plain
+An ordinary, unencrypted connection.
+@item tls
+@itemx ssl
+A TLS (``Transport Layer Security'') connection.
+@item nil
+@itemx network
+Start with a plain connection, and if parameters @samp{:success}
+and @samp{:capability-command} are supplied, try to upgrade to an encrypted
+connection via STARTTLS. If that fails, retain the unencrypted connection.
+@item starttls
+As for @code{nil}, but if STARTTLS fails drop the connection.
+@item shell
+A shell connection.
+@end table
+
+@item :always-query-capabilities @var{boolean}
+If non-@code{nil}, always ask for the server's capabilities, even when
+doing a @samp{plain} connection.
+
+@item :capability-command @var{capability-command}
+Command string to query the host capabilities.
+
+@item :end-of-command @var{regexp}
+@itemx :end-of-capability @var{regexp}
+Regular expression matching the end of a command, or the end of the
+command @var{capability-command}. The latter defaults to the former.
+
+@item :starttls-function @var{function}
+Function of one argument (the response to @var{capability-command}),
+which returns either @code{nil}, or the command to activate STARTTLS
+if supported.
+
+@item :success @var{regexp}
+Regular expression matching a successful STARTTLS negotiation.
+
+@item :use-starttls-if-possible @var{boolean}
+If non-@code{nil}, do opportunistic STARTTLS upgrades even if Emacs
+doesn't have built-in TLS support.
+
+@item :client-certificate @var{list-or-t}
+Either a list of the form @code{(@var{key-file} @var{cert-file})},
+naming the certificate key file and certificate file itself, or
+@code{t}, meaning to query @code{auth-source} for this information
+(@pxref{Top,,auth-source, auth, Emacs auth-source Library}).
+Only used for TLS or STARTTLS.
+
+@item :return-list @var{cons-or-nil}
+The return value of this function. If omitted or @code{nil}, return a
+process object. Otherwise, a cons of the form @code{(@var{process-object}
+. @var{plist})}, where @var{plist} has keywords:
+
+@table @code
+@item :greeting @var{string-or-nil}
+If non-@code{nil}, the greeting string returned by the host.
+@item :capabilities @var{string-or-nil}
+If non-@code{nil}, the host's capability string.
+@item :type @var{symbol}
+The connection type: @samp{plain} or @samp{tls}.
+@end table
+
+@end table
+
@end defun
@node Network Servers
@itemize @bullet
@item
The connection's process name is constructed by concatenating the
-server process' @var{name} with a client identification string. The
+server process's @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
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.
+The server's process buffer value is never used directly, but the log
+function can retrieve it and use it to log connections by inserting
+text there.
@item
The communication type and the process filter and sentinel are
number used for the connection.
@item
-The client process' plist is initialized from the server's plist.
+The client process's plist is initialized from the server's plist.
@end itemize
@node Datagrams
@itemx :parity
@itemx :stopbits
@itemx :flowcontrol
-These arguments are handled by @code{serial-process-configure}, which
-is called by @code{make-serial-process}.
+These are handled by @code{serial-process-configure}, which is called
+by @code{make-serial-process}.
@end table
The original argument list, possibly modified by later configuration,
is available via the function @code{process-contact}.
-Examples:
+Here is an example:
@example
(make-serial-process :port "/dev/ttyS0" :speed 9600)
-
-(make-serial-process :port "COM1" :speed 115200 :stopbits 2)
-
-(make-serial-process :port "\\\\.\\COM13" :speed 1200
- :bytesize 7 :parity 'odd)
-
-(make-serial-process :port "/dev/tty.BlueConsole-SPP-1"
- :speed nil)
@end example
@end defun
flow control.
@end table
-@code{serial-process-configure} is called by @code{make-serial-process} for the
-initial configuration of the serial port.
-
-Examples:
-
-@example
-(serial-process-configure :process "/dev/ttyS0" :speed 1200)
-
-(serial-process-configure :buffer "COM1" :stopbits 1
- :parity 'odd :flowcontrol 'hw)
-
-(serial-process-configure :port "\\\\.\\COM13" :bytesize 7)
-@end example
+@code{serial-process-configure} is called by
+@code{make-serial-process} for the initial configuration of the serial
+port.
@end defun
@node Byte Packing
@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.''
+is automatically recognized as ``risky''.
@cindex endianness
@cindex big endian
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
+``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:
@itemx dword
@itemx long
Unsigned integer in network byte order, with length 4.
-Note: These values may be limited by Emacs' integer implementation limits.
+Note: These values may be limited by Emacs's integer implementation limits.
@item u16r
@itemx u24r
(bindat-get-field decoded 'item 1 'id)
@result{} "BCDEFG"
@end lisp
-
-@ignore
- arch-tag: ba9da253-e65f-4e7f-b727-08fba0a1df7a
-@end ignore
HCoop / bpt / emacs.git / blobdiff