| 1 | @c -*-texinfo-*- |
| 2 | @c This is part of the GNU Emacs Lisp Reference Manual. |
| 3 | @c Copyright (C) 1990-1995, 1998-1999, 2001-2013 Free Software |
| 4 | @c Foundation, Inc. |
| 5 | @c See the file elisp.texi for copying conditions. |
| 6 | @node Processes |
| 7 | @chapter Processes |
| 8 | @cindex child process |
| 9 | @cindex parent process |
| 10 | @cindex subprocess |
| 11 | @cindex process |
| 12 | |
| 13 | In the terminology of operating systems, a @dfn{process} is a space in |
| 14 | which a program can execute. Emacs runs in a process. Emacs Lisp |
| 15 | programs can invoke other programs in processes of their own. These are |
| 16 | called @dfn{subprocesses} or @dfn{child processes} of the Emacs process, |
| 17 | which is their @dfn{parent process}. |
| 18 | |
| 19 | A subprocess of Emacs may be @dfn{synchronous} or @dfn{asynchronous}, |
| 20 | depending on how it is created. When you create a synchronous |
| 21 | subprocess, the Lisp program waits for the subprocess to terminate |
| 22 | before continuing execution. When you create an asynchronous |
| 23 | subprocess, it can run in parallel with the Lisp program. This kind of |
| 24 | subprocess is represented within Emacs by a Lisp object which is also |
| 25 | called a ``process''. Lisp programs can use this object to communicate |
| 26 | with the subprocess or to control it. For example, you can send |
| 27 | signals, obtain status information, receive output from the process, or |
| 28 | send input to it. |
| 29 | |
| 30 | @defun processp object |
| 31 | This function returns @code{t} if @var{object} represents an Emacs |
| 32 | subprocess, @code{nil} otherwise. |
| 33 | @end defun |
| 34 | |
| 35 | In addition to subprocesses of the current Emacs session, you can |
| 36 | also access other processes running on your machine. @xref{System |
| 37 | Processes}. |
| 38 | |
| 39 | @menu |
| 40 | * Subprocess Creation:: Functions that start subprocesses. |
| 41 | * Shell Arguments:: Quoting an argument to pass it to a shell. |
| 42 | * Synchronous Processes:: Details of using synchronous subprocesses. |
| 43 | * Asynchronous Processes:: Starting up an asynchronous subprocess. |
| 44 | * Deleting Processes:: Eliminating an asynchronous subprocess. |
| 45 | * Process Information:: Accessing run-status and other attributes. |
| 46 | * Input to Processes:: Sending input to an asynchronous subprocess. |
| 47 | * Signals to Processes:: Stopping, continuing or interrupting |
| 48 | an asynchronous subprocess. |
| 49 | * Output from Processes:: Collecting output from an asynchronous subprocess. |
| 50 | * Sentinels:: Sentinels run when process run-status changes. |
| 51 | * Query Before Exit:: Whether to query if exiting will kill a process. |
| 52 | * System Processes:: Accessing other processes running on your system. |
| 53 | * Transaction Queues:: Transaction-based communication with subprocesses. |
| 54 | * Network:: Opening network connections. |
| 55 | * Network Servers:: Network servers let Emacs accept net connections. |
| 56 | * Datagrams:: UDP network connections. |
| 57 | * Low-Level Network:: Lower-level but more general function |
| 58 | to create connections and servers. |
| 59 | * Misc Network:: Additional relevant functions for net connections. |
| 60 | * Serial Ports:: Communicating with serial ports. |
| 61 | * Byte Packing:: Using bindat to pack and unpack binary data. |
| 62 | @end menu |
| 63 | |
| 64 | @node Subprocess Creation |
| 65 | @section Functions that Create Subprocesses |
| 66 | |
| 67 | There are three primitives that create a new subprocess in which to run |
| 68 | a program. One of them, @code{start-process}, creates an asynchronous |
| 69 | process and returns a process object (@pxref{Asynchronous Processes}). |
| 70 | The other two, @code{call-process} and @code{call-process-region}, |
| 71 | create a synchronous process and do not return a process object |
| 72 | (@pxref{Synchronous Processes}). There are various higher-level |
| 73 | functions that make use of these primitives to run particular types of |
| 74 | process. |
| 75 | |
| 76 | Synchronous and asynchronous processes are explained in the following |
| 77 | sections. Since the three functions are all called in a similar |
| 78 | fashion, their common arguments are described here. |
| 79 | |
| 80 | @cindex execute program |
| 81 | @cindex @env{PATH} environment variable |
| 82 | @cindex @env{HOME} environment variable |
| 83 | In all cases, the function's @var{program} argument specifies the |
| 84 | program to be run. An error is signaled if the file is not found or |
| 85 | cannot be executed. If the file name is relative, the variable |
| 86 | @code{exec-path} contains a list of directories to search. Emacs |
| 87 | initializes @code{exec-path} when it starts up, based on the value of |
| 88 | the environment variable @env{PATH}. The standard file name |
| 89 | constructs, @samp{~}, @samp{.}, and @samp{..}, are interpreted as |
| 90 | usual in @code{exec-path}, but environment variable substitutions |
| 91 | (@samp{$HOME}, etc.) are not recognized; use |
| 92 | @code{substitute-in-file-name} to perform them (@pxref{File Name |
| 93 | Expansion}). @code{nil} in this list refers to |
| 94 | @code{default-directory}. |
| 95 | |
| 96 | Executing a program can also try adding suffixes to the specified |
| 97 | name: |
| 98 | |
| 99 | @defopt exec-suffixes |
| 100 | This variable is a list of suffixes (strings) to try adding to the |
| 101 | specified program file name. The list should include @code{""} if you |
| 102 | want the name to be tried exactly as specified. The default value is |
| 103 | system-dependent. |
| 104 | @end defopt |
| 105 | |
| 106 | @strong{Please note:} The argument @var{program} contains only the |
| 107 | name of the program; it may not contain any command-line arguments. You |
| 108 | must use a separate argument, @var{args}, to provide those, as |
| 109 | described below. |
| 110 | |
| 111 | Each of the subprocess-creating functions has a @var{buffer-or-name} |
| 112 | argument that specifies where the standard output from the program will |
| 113 | go. It should be a buffer or a buffer name; if it is a buffer name, |
| 114 | that will create the buffer if it does not already exist. It can also |
| 115 | be @code{nil}, which says to discard the output unless a filter function |
| 116 | handles it. (@xref{Filter Functions}, and @ref{Read and Print}.) |
| 117 | Normally, you should avoid having multiple processes send output to the |
| 118 | same buffer because their output would be intermixed randomly. |
| 119 | For synchronous processes, you can send the output to a file instead |
| 120 | of a buffer. |
| 121 | |
| 122 | @cindex program arguments |
| 123 | All three of the subprocess-creating functions have a @code{&rest} |
| 124 | argument, @var{args}. The @var{args} must all be strings, and they are |
| 125 | supplied to @var{program} as separate command line arguments. Wildcard |
| 126 | characters and other shell constructs have no special meanings in these |
| 127 | strings, since the strings are passed directly to the specified program. |
| 128 | |
| 129 | @cindex environment variables, subprocesses |
| 130 | The subprocess inherits its environment from Emacs, but you can |
| 131 | specify overrides for it with @code{process-environment}. @xref{System |
| 132 | Environment}. The subprocess gets its current directory from the |
| 133 | value of @code{default-directory}. |
| 134 | |
| 135 | @defvar exec-directory |
| 136 | @pindex movemail |
| 137 | The value of this variable is a string, the name of a directory that |
| 138 | contains programs that come with GNU Emacs and are intended for Emacs |
| 139 | to invoke. The program @code{movemail} is an example of such a program; |
| 140 | Rmail uses it to fetch new mail from an inbox. |
| 141 | @end defvar |
| 142 | |
| 143 | @defopt exec-path |
| 144 | The value of this variable is a list of directories to search for |
| 145 | programs to run in subprocesses. Each element is either the name of a |
| 146 | directory (i.e., a string), or @code{nil}, which stands for the default |
| 147 | directory (which is the value of @code{default-directory}). |
| 148 | @cindex program directories |
| 149 | |
| 150 | The value of @code{exec-path} is used by @code{call-process} and |
| 151 | @code{start-process} when the @var{program} argument is not an absolute |
| 152 | file name. |
| 153 | |
| 154 | Generally, you should not modify @code{exec-path} directly. Instead, |
| 155 | ensure that your @env{PATH} environment variable is set appropriately |
| 156 | before starting Emacs. Trying to modify @code{exec-path} |
| 157 | independently of @env{PATH} can lead to confusing results. |
| 158 | @end defopt |
| 159 | |
| 160 | @node Shell Arguments |
| 161 | @section Shell Arguments |
| 162 | @cindex arguments for shell commands |
| 163 | @cindex shell command arguments |
| 164 | |
| 165 | Lisp programs sometimes need to run a shell and give it a command |
| 166 | that contains file names that were specified by the user. These |
| 167 | programs ought to be able to support any valid file name. But the shell |
| 168 | gives special treatment to certain characters, and if these characters |
| 169 | occur in the file name, they will confuse the shell. To handle these |
| 170 | characters, use the function @code{shell-quote-argument}: |
| 171 | |
| 172 | @defun shell-quote-argument argument |
| 173 | This function returns a string that represents, in shell syntax, |
| 174 | an argument whose actual contents are @var{argument}. It should |
| 175 | work reliably to concatenate the return value into a shell command |
| 176 | and then pass it to a shell for execution. |
| 177 | |
| 178 | Precisely what this function does depends on your operating system. The |
| 179 | function is designed to work with the syntax of your system's standard |
| 180 | shell; if you use an unusual shell, you will need to redefine this |
| 181 | function. |
| 182 | |
| 183 | @example |
| 184 | ;; @r{This example shows the behavior on GNU and Unix systems.} |
| 185 | (shell-quote-argument "foo > bar") |
| 186 | @result{} "foo\\ \\>\\ bar" |
| 187 | |
| 188 | ;; @r{This example shows the behavior on MS-DOS and MS-Windows.} |
| 189 | (shell-quote-argument "foo > bar") |
| 190 | @result{} "\"foo > bar\"" |
| 191 | @end example |
| 192 | |
| 193 | Here's an example of using @code{shell-quote-argument} to construct |
| 194 | a shell command: |
| 195 | |
| 196 | @example |
| 197 | (concat "diff -c " |
| 198 | (shell-quote-argument oldfile) |
| 199 | " " |
| 200 | (shell-quote-argument newfile)) |
| 201 | @end example |
| 202 | @end defun |
| 203 | |
| 204 | @cindex quoting and unquoting command-line arguments |
| 205 | @cindex minibuffer input, and command-line arguments |
| 206 | @cindex @code{call-process}, command-line arguments from minibuffer |
| 207 | @cindex @code{start-process}, command-line arguments from minibuffer |
| 208 | The following two functions are useful for combining a list of |
| 209 | individual command-line argument strings into a single string, and |
| 210 | taking a string apart into a list of individual command-line |
| 211 | arguments. These functions are mainly intended for |
| 212 | converting user input in the minibuffer, a Lisp string, into a list of |
| 213 | string arguments to be passed to @code{call-process} or |
| 214 | @code{start-process}, or for converting such lists of arguments into |
| 215 | a single Lisp string to be presented in the minibuffer or echo area. |
| 216 | |
| 217 | @defun split-string-and-unquote string &optional separators |
| 218 | This function splits @var{string} into substrings at matches for the |
| 219 | regular expression @var{separators}, like @code{split-string} does |
| 220 | (@pxref{Creating Strings}); in addition, it removes quoting from the |
| 221 | substrings. It then makes a list of the substrings and returns it. |
| 222 | |
| 223 | If @var{separators} is omitted or @code{nil}, it defaults to |
| 224 | @code{"\\s-+"}, which is a regular expression that matches one or more |
| 225 | characters with whitespace syntax (@pxref{Syntax Class Table}). |
| 226 | |
| 227 | This function supports two types of quoting: enclosing a whole string |
| 228 | in double quotes @code{"@dots{}"}, and quoting individual characters |
| 229 | with a backslash escape @samp{\}. The latter is also used in Lisp |
| 230 | strings, so this function can handle those as well. |
| 231 | @end defun |
| 232 | |
| 233 | @defun combine-and-quote-strings list-of-strings &optional separator |
| 234 | This function concatenates @var{list-of-strings} into a single string, |
| 235 | quoting each string as necessary. It also sticks the @var{separator} |
| 236 | string between each pair of strings; if @var{separator} is omitted or |
| 237 | @code{nil}, it defaults to @code{" "}. The return value is the |
| 238 | resulting string. |
| 239 | |
| 240 | The strings in @var{list-of-strings} that need quoting are those that |
| 241 | include @var{separator} as their substring. Quoting a string encloses |
| 242 | it in double quotes @code{"@dots{}"}. In the simplest case, if you |
| 243 | are consing a command from the individual command-line arguments, |
| 244 | every argument that includes embedded blanks will be quoted. |
| 245 | @end defun |
| 246 | |
| 247 | @node Synchronous Processes |
| 248 | @section Creating a Synchronous Process |
| 249 | @cindex synchronous subprocess |
| 250 | |
| 251 | After a @dfn{synchronous process} is created, Emacs waits for the |
| 252 | process to terminate before continuing. Starting Dired on GNU or |
| 253 | Unix@footnote{On other systems, Emacs uses a Lisp emulation of |
| 254 | @code{ls}; see @ref{Contents of Directories}.} is an example of this: it |
| 255 | runs @code{ls} in a synchronous process, then modifies the output |
| 256 | slightly. Because the process is synchronous, the entire directory |
| 257 | listing arrives in the buffer before Emacs tries to do anything with it. |
| 258 | |
| 259 | While Emacs waits for the synchronous subprocess to terminate, the |
| 260 | user can quit by typing @kbd{C-g}. The first @kbd{C-g} tries to kill |
| 261 | the subprocess with a @code{SIGINT} signal; but it waits until the |
| 262 | subprocess actually terminates before quitting. If during that time the |
| 263 | user types another @kbd{C-g}, that kills the subprocess instantly with |
| 264 | @code{SIGKILL} and quits immediately (except on MS-DOS, where killing |
| 265 | other processes doesn't work). @xref{Quitting}. |
| 266 | |
| 267 | The synchronous subprocess functions return an indication of how the |
| 268 | process terminated. |
| 269 | |
| 270 | The output from a synchronous subprocess is generally decoded using a |
| 271 | coding system, much like text read from a file. The input sent to a |
| 272 | subprocess by @code{call-process-region} is encoded using a coding |
| 273 | system, much like text written into a file. @xref{Coding Systems}. |
| 274 | |
| 275 | @defun call-process program &optional infile destination display &rest args |
| 276 | This function calls @var{program} and waits for it to finish. |
| 277 | |
| 278 | The current working directory of the subprocess is |
| 279 | @code{default-directory}. |
| 280 | |
| 281 | The standard input for the new process comes from file @var{infile} if |
| 282 | @var{infile} is not @code{nil}, and from the null device otherwise. |
| 283 | The argument @var{destination} says where to put the process output. |
| 284 | Here are the possibilities: |
| 285 | |
| 286 | @table @asis |
| 287 | @item a buffer |
| 288 | Insert the output in that buffer, before point. This includes both the |
| 289 | standard output stream and the standard error stream of the process. |
| 290 | |
| 291 | @item a string |
| 292 | Insert the output in a buffer with that name, before point. |
| 293 | |
| 294 | @item @code{t} |
| 295 | Insert the output in the current buffer, before point. |
| 296 | |
| 297 | @item @code{nil} |
| 298 | Discard the output. |
| 299 | |
| 300 | @item 0 |
| 301 | Discard the output, and return @code{nil} immediately without waiting |
| 302 | for the subprocess to finish. |
| 303 | |
| 304 | In this case, the process is not truly synchronous, since it can run in |
| 305 | parallel with Emacs; but you can think of it as synchronous in that |
| 306 | Emacs is essentially finished with the subprocess as soon as this |
| 307 | function returns. |
| 308 | |
| 309 | MS-DOS doesn't support asynchronous subprocesses, so this option doesn't |
| 310 | work there. |
| 311 | |
| 312 | @item @code{(:file @var{file-name})} |
| 313 | Send the output to the file name specified, overwriting it if it |
| 314 | already exists. |
| 315 | |
| 316 | @item @code{(@var{real-destination} @var{error-destination})} |
| 317 | Keep the standard output stream separate from the standard error stream; |
| 318 | deal with the ordinary output as specified by @var{real-destination}, |
| 319 | and dispose of the error output according to @var{error-destination}. |
| 320 | If @var{error-destination} is @code{nil}, that means to discard the |
| 321 | error output, @code{t} means mix it with the ordinary output, and a |
| 322 | string specifies a file name to redirect error output into. |
| 323 | |
| 324 | You can't directly specify a buffer to put the error output in; that is |
| 325 | too difficult to implement. But you can achieve this result by sending |
| 326 | the error output to a temporary file and then inserting the file into a |
| 327 | buffer. |
| 328 | @end table |
| 329 | |
| 330 | If @var{display} is non-@code{nil}, then @code{call-process} redisplays |
| 331 | the buffer as output is inserted. (However, if the coding system chosen |
| 332 | for decoding output is @code{undecided}, meaning deduce the encoding |
| 333 | from the actual data, then redisplay sometimes cannot continue once |
| 334 | non-@acronym{ASCII} characters are encountered. There are fundamental |
| 335 | reasons why it is hard to fix this; see @ref{Output from Processes}.) |
| 336 | |
| 337 | Otherwise the function @code{call-process} does no redisplay, and the |
| 338 | results become visible on the screen only when Emacs redisplays that |
| 339 | buffer in the normal course of events. |
| 340 | |
| 341 | The remaining arguments, @var{args}, are strings that specify command |
| 342 | line arguments for the program. |
| 343 | |
| 344 | The value returned by @code{call-process} (unless you told it not to |
| 345 | wait) indicates the reason for process termination. A number gives the |
| 346 | exit status of the subprocess; 0 means success, and any other value |
| 347 | means failure. If the process terminated with a signal, |
| 348 | @code{call-process} returns a string describing the signal. |
| 349 | |
| 350 | In the examples below, the buffer @samp{foo} is current. |
| 351 | |
| 352 | @smallexample |
| 353 | @group |
| 354 | (call-process "pwd" nil t) |
| 355 | @result{} 0 |
| 356 | |
| 357 | ---------- Buffer: foo ---------- |
| 358 | /home/lewis/manual |
| 359 | ---------- Buffer: foo ---------- |
| 360 | @end group |
| 361 | |
| 362 | @group |
| 363 | (call-process "grep" nil "bar" nil "lewis" "/etc/passwd") |
| 364 | @result{} 0 |
| 365 | |
| 366 | ---------- Buffer: bar ---------- |
| 367 | lewis:x:1001:1001:Bil Lewis,,,,:/home/lewis:/bin/bash |
| 368 | |
| 369 | ---------- Buffer: bar ---------- |
| 370 | @end group |
| 371 | @end smallexample |
| 372 | |
| 373 | Here is an example of the use of @code{call-process}, as used to |
| 374 | be found in the definition of the @code{insert-directory} function: |
| 375 | |
| 376 | @smallexample |
| 377 | @group |
| 378 | (call-process insert-directory-program nil t nil switches |
| 379 | (if full-directory-p |
| 380 | (concat (file-name-as-directory file) ".") |
| 381 | file)) |
| 382 | @end group |
| 383 | @end smallexample |
| 384 | @end defun |
| 385 | |
| 386 | @defun process-file program &optional infile buffer display &rest args |
| 387 | This function processes files synchronously in a separate process. It |
| 388 | is similar to @code{call-process}, but may invoke a file handler based |
| 389 | on the value of the variable @code{default-directory}, which specifies |
| 390 | the current working directory of the subprocess. |
| 391 | |
| 392 | The arguments are handled in almost the same way as for |
| 393 | @code{call-process}, with the following differences: |
| 394 | |
| 395 | Some file handlers may not support all combinations and forms of the |
| 396 | arguments @var{infile}, @var{buffer}, and @var{display}. For example, |
| 397 | some file handlers might behave as if @var{display} were @code{nil}, |
| 398 | regardless of the value actually passed. As another example, some |
| 399 | file handlers might not support separating standard output and error |
| 400 | output by way of the @var{buffer} argument. |
| 401 | |
| 402 | If a file handler is invoked, it determines the program to run based |
| 403 | on the first argument @var{program}. For instance, suppose that a |
| 404 | handler for remote files is invoked. Then the path that is used for |
| 405 | searching for the program might be different from @code{exec-path}. |
| 406 | |
| 407 | The second argument @var{infile} may invoke a file handler. The file |
| 408 | handler could be different from the handler chosen for the |
| 409 | @code{process-file} function itself. (For example, |
| 410 | @code{default-directory} could be on one remote host, and |
| 411 | @var{infile} on a different remote host. Or @code{default-directory} |
| 412 | could be non-special, whereas @var{infile} is on a remote host.) |
| 413 | |
| 414 | If @var{buffer} is a list of the form @code{(@var{real-destination} |
| 415 | @var{error-destination})}, and @var{error-destination} names a file, |
| 416 | then the same remarks as for @var{infile} apply. |
| 417 | |
| 418 | The remaining arguments (@var{args}) will be passed to the process |
| 419 | verbatim. Emacs is not involved in processing file names that are |
| 420 | present in @var{args}. To avoid confusion, it may be best to avoid |
| 421 | absolute file names in @var{args}, but rather to specify all file |
| 422 | names as relative to @code{default-directory}. The function |
| 423 | @code{file-relative-name} is useful for constructing such relative |
| 424 | file names. |
| 425 | @end defun |
| 426 | |
| 427 | @defvar process-file-side-effects |
| 428 | This variable indicates whether a call of @code{process-file} changes |
| 429 | remote files. |
| 430 | |
| 431 | By default, this variable is always set to @code{t}, meaning that a |
| 432 | call of @code{process-file} could potentially change any file on a |
| 433 | remote host. When set to @code{nil}, a file handler could optimize |
| 434 | its behavior with respect to remote file attribute caching. |
| 435 | |
| 436 | You should only ever change this variable with a let-binding; never |
| 437 | with @code{setq}. |
| 438 | @end defvar |
| 439 | |
| 440 | @defun call-process-region start end program &optional delete destination display &rest args |
| 441 | This function sends the text from @var{start} to @var{end} as |
| 442 | standard input to a process running @var{program}. It deletes the text |
| 443 | sent if @var{delete} is non-@code{nil}; this is useful when |
| 444 | @var{destination} is @code{t}, to insert the output in the current |
| 445 | buffer in place of the input. |
| 446 | |
| 447 | The arguments @var{destination} and @var{display} control what to do |
| 448 | with the output from the subprocess, and whether to update the display |
| 449 | as it comes in. For details, see the description of |
| 450 | @code{call-process}, above. If @var{destination} is the integer 0, |
| 451 | @code{call-process-region} discards the output and returns @code{nil} |
| 452 | immediately, without waiting for the subprocess to finish (this only |
| 453 | works if asynchronous subprocesses are supported; i.e., not on MS-DOS). |
| 454 | |
| 455 | The remaining arguments, @var{args}, are strings that specify command |
| 456 | line arguments for the program. |
| 457 | |
| 458 | The return value of @code{call-process-region} is just like that of |
| 459 | @code{call-process}: @code{nil} if you told it to return without |
| 460 | waiting; otherwise, a number or string which indicates how the |
| 461 | subprocess terminated. |
| 462 | |
| 463 | In the following example, we use @code{call-process-region} to run the |
| 464 | @code{cat} utility, with standard input being the first five characters |
| 465 | in buffer @samp{foo} (the word @samp{input}). @code{cat} copies its |
| 466 | standard input into its standard output. Since the argument |
| 467 | @var{destination} is @code{t}, this output is inserted in the current |
| 468 | buffer. |
| 469 | |
| 470 | @smallexample |
| 471 | @group |
| 472 | ---------- Buffer: foo ---------- |
| 473 | input@point{} |
| 474 | ---------- Buffer: foo ---------- |
| 475 | @end group |
| 476 | |
| 477 | @group |
| 478 | (call-process-region 1 6 "cat" nil t) |
| 479 | @result{} 0 |
| 480 | |
| 481 | ---------- Buffer: foo ---------- |
| 482 | inputinput@point{} |
| 483 | ---------- Buffer: foo ---------- |
| 484 | @end group |
| 485 | @end smallexample |
| 486 | |
| 487 | For example, the @code{shell-command-on-region} command uses |
| 488 | @code{call-process-region} in a manner similar to this: |
| 489 | |
| 490 | @smallexample |
| 491 | @group |
| 492 | (call-process-region |
| 493 | start end |
| 494 | shell-file-name ; @r{name of program} |
| 495 | nil ; @r{do not delete region} |
| 496 | buffer ; @r{send output to @code{buffer}} |
| 497 | nil ; @r{no redisplay during output} |
| 498 | "-c" command) ; @r{arguments for the shell} |
| 499 | @end group |
| 500 | @end smallexample |
| 501 | @c It actually uses shell-command-switch, but no need to mention that here. |
| 502 | @end defun |
| 503 | |
| 504 | @defun call-process-shell-command command &optional infile destination display &rest args |
| 505 | This function executes the shell command @var{command} synchronously. |
| 506 | The final arguments @var{args} are additional arguments to add at the |
| 507 | end of @var{command}. The other arguments are handled as in |
| 508 | @code{call-process}. |
| 509 | @end defun |
| 510 | |
| 511 | @defun process-file-shell-command command &optional infile destination display &rest args |
| 512 | This function is like @code{call-process-shell-command}, but uses |
| 513 | @code{process-file} internally. Depending on @code{default-directory}, |
| 514 | @var{command} can be executed also on remote hosts. |
| 515 | @end defun |
| 516 | |
| 517 | @defun shell-command-to-string command |
| 518 | This function executes @var{command} (a string) as a shell command, |
| 519 | then returns the command's output as a string. |
| 520 | @end defun |
| 521 | |
| 522 | @c There is also shell-command-on-region, but that is more of a user |
| 523 | @c command, not something to use in programs. |
| 524 | |
| 525 | @defun process-lines program &rest args |
| 526 | This function runs @var{program}, waits for it to finish, and returns |
| 527 | its output as a list of strings. Each string in the list holds a |
| 528 | single line of text output by the program; the end-of-line characters |
| 529 | are stripped from each line. The arguments beyond @var{program}, |
| 530 | @var{args}, are strings that specify command-line arguments with which |
| 531 | to run the program. |
| 532 | |
| 533 | If @var{program} exits with a non-zero exit status, this function |
| 534 | signals an error. |
| 535 | |
| 536 | This function works by calling @code{call-process}, so program output |
| 537 | is decoded in the same way as for @code{call-process}. |
| 538 | @end defun |
| 539 | |
| 540 | @node Asynchronous Processes |
| 541 | @section Creating an Asynchronous Process |
| 542 | @cindex asynchronous subprocess |
| 543 | |
| 544 | In this section, we describe how to create an @dfn{asynchronous |
| 545 | process}. After an asynchronous process is created, it runs in |
| 546 | parallel with Emacs, and Emacs can communicate with it using the |
| 547 | functions described in the following sections (@pxref{Input to |
| 548 | Processes}, and @pxref{Output from Processes}). Note that process |
| 549 | communication is only partially asynchronous: Emacs sends data to the |
| 550 | process only when certain functions are called, and Emacs accepts data |
| 551 | from the process only while waiting for input or for a time delay. |
| 552 | |
| 553 | @cindex pty |
| 554 | @cindex pipe |
| 555 | An asynchronous process is controlled either via a @dfn{pty} |
| 556 | (pseudo-terminal) or a @dfn{pipe}. The choice of pty or pipe is made |
| 557 | when creating the process, based on the value of the variable |
| 558 | @code{process-connection-type} (see below). Ptys are usually |
| 559 | preferable for processes visible to the user, as in Shell mode, |
| 560 | because they allow for job control (@kbd{C-c}, @kbd{C-z}, etc.) |
| 561 | between the process and its children, whereas pipes do not. For |
| 562 | subprocesses used for internal purposes by programs, it is often |
| 563 | better to use a pipe, because they are more efficient, and because |
| 564 | they are immune to stray character injections that ptys introduce for |
| 565 | large (around 500 byte) messages. Also, the total number of ptys is |
| 566 | limited on many systems and it is good not to waste them. |
| 567 | |
| 568 | @defun start-process name buffer-or-name program &rest args |
| 569 | This function creates a new asynchronous subprocess and starts the |
| 570 | program @var{program} running in it. It returns a process object that |
| 571 | stands for the new subprocess in Lisp. The argument @var{name} |
| 572 | specifies the name for the process object; if a process with this name |
| 573 | already exists, then @var{name} is modified (by appending @samp{<1>}, |
| 574 | etc.) to be unique. The buffer @var{buffer-or-name} is the buffer to |
| 575 | associate with the process. |
| 576 | |
| 577 | If @var{program} is @code{nil}, Emacs opens a new pseudoterminal (pty) |
| 578 | and associates its input and output with @var{buffer-or-name}, without |
| 579 | creating a subprocess. In that case, the remaining arguments |
| 580 | @var{args} are ignored. |
| 581 | |
| 582 | The remaining arguments, @var{args}, are strings that specify command |
| 583 | line arguments for the subprocess. |
| 584 | |
| 585 | In the example below, the first process is started and runs (rather, |
| 586 | sleeps) for 100 seconds (the output buffer @samp{foo} is created |
| 587 | immediately). Meanwhile, the second process is started, and |
| 588 | given the name @samp{my-process<1>} for the sake of uniqueness. It |
| 589 | inserts the directory listing at the end of the buffer @samp{foo}, |
| 590 | before the first process finishes. Then it finishes, and a message to |
| 591 | that effect is inserted in the buffer. Much later, the first process |
| 592 | finishes, and another message is inserted in the buffer for it. |
| 593 | |
| 594 | @smallexample |
| 595 | @group |
| 596 | (start-process "my-process" "foo" "sleep" "100") |
| 597 | @result{} #<process my-process> |
| 598 | @end group |
| 599 | |
| 600 | @group |
| 601 | (start-process "my-process" "foo" "ls" "-l" "/bin") |
| 602 | @result{} #<process my-process<1>> |
| 603 | |
| 604 | ---------- Buffer: foo ---------- |
| 605 | total 8336 |
| 606 | -rwxr-xr-x 1 root root 971384 Mar 30 10:14 bash |
| 607 | -rwxr-xr-x 1 root root 146920 Jul 5 2011 bsd-csh |
| 608 | @dots{} |
| 609 | -rwxr-xr-x 1 root root 696880 Feb 28 15:55 zsh4 |
| 610 | |
| 611 | Process my-process<1> finished |
| 612 | |
| 613 | Process my-process finished |
| 614 | ---------- Buffer: foo ---------- |
| 615 | @end group |
| 616 | @end smallexample |
| 617 | @end defun |
| 618 | |
| 619 | @defun start-file-process name buffer-or-name program &rest args |
| 620 | Like @code{start-process}, this function starts a new asynchronous |
| 621 | subprocess running @var{program} in it, and returns its process |
| 622 | object. |
| 623 | |
| 624 | The difference from @code{start-process} is that this function may |
| 625 | invoked a file handler based on the value of @code{default-directory}. |
| 626 | This handler ought to run @var{program}, perhaps on the local host, |
| 627 | perhaps on a remote host that corresponds to @code{default-directory}. |
| 628 | In the latter case, the local part of @code{default-directory} becomes |
| 629 | the working directory of the process. |
| 630 | |
| 631 | This function does not try to invoke file name handlers for |
| 632 | @var{program} or for the @var{program-args}. |
| 633 | |
| 634 | Depending on the implementation of the file handler, it might not be |
| 635 | possible to apply @code{process-filter} or @code{process-sentinel} to |
| 636 | the resulting process object. @xref{Filter Functions}, and @ref{Sentinels}. |
| 637 | |
| 638 | @c FIXME Can we find a better example (i.e., a more modern function |
| 639 | @c that is actually documented). |
| 640 | Some file handlers may not support @code{start-file-process} (for |
| 641 | example the function @code{ange-ftp-hook-function}). In such cases, |
| 642 | this function does nothing and returns @code{nil}. |
| 643 | @end defun |
| 644 | |
| 645 | @defun start-process-shell-command name buffer-or-name command |
| 646 | This function is like @code{start-process}, except that it uses a shell |
| 647 | to execute the specified command. The argument @var{command} is a shell |
| 648 | command name. The variable @code{shell-file-name} specifies which shell to |
| 649 | use. |
| 650 | |
| 651 | The point of running a program through the shell, rather than directly |
| 652 | with @code{start-process}, is so that you can employ shell features such |
| 653 | as wildcards in the arguments. It follows that if you include any |
| 654 | arbitrary user-specified arguments in the command, you should quote them |
| 655 | with @code{shell-quote-argument} first, so that any special shell |
| 656 | characters do @emph{not} have their special shell meanings. @xref{Shell |
| 657 | Arguments}. Of course, when executing commands based on user input |
| 658 | you should also consider the security implications. |
| 659 | @end defun |
| 660 | |
| 661 | @defun start-file-process-shell-command name buffer-or-name command |
| 662 | This function is like @code{start-process-shell-command}, but uses |
| 663 | @code{start-file-process} internally. Because of this, @var{command} |
| 664 | can also be executed on remote hosts, depending on @code{default-directory}. |
| 665 | @end defun |
| 666 | |
| 667 | @defvar process-connection-type |
| 668 | This variable controls the type of device used to communicate with |
| 669 | asynchronous subprocesses. If it is non-@code{nil}, then ptys are |
| 670 | used, when available. Otherwise, pipes are used. |
| 671 | |
| 672 | The value of @code{process-connection-type} takes effect when |
| 673 | @code{start-process} is called. So you can specify how to communicate |
| 674 | with one subprocess by binding the variable around the call to |
| 675 | @code{start-process}. |
| 676 | |
| 677 | @smallexample |
| 678 | @group |
| 679 | (let ((process-connection-type nil)) ; @r{use a pipe} |
| 680 | (start-process @dots{})) |
| 681 | @end group |
| 682 | @end smallexample |
| 683 | |
| 684 | To determine whether a given subprocess actually got a pipe or a pty, |
| 685 | use the function @code{process-tty-name} (@pxref{Process |
| 686 | Information}). |
| 687 | @end defvar |
| 688 | |
| 689 | @node Deleting Processes |
| 690 | @section Deleting Processes |
| 691 | @cindex deleting processes |
| 692 | |
| 693 | @dfn{Deleting a process} disconnects Emacs immediately from the |
| 694 | subprocess. Processes are deleted automatically after they terminate, |
| 695 | but not necessarily right away. You can delete a process explicitly |
| 696 | at any time. If you explicitly delete a terminated process before it |
| 697 | is deleted automatically, no harm results. Deleting a running |
| 698 | process sends a signal to terminate it (and its child processes, if |
| 699 | any), and calls the process sentinel if it has one. @xref{Sentinels}. |
| 700 | |
| 701 | When a process is deleted, the process object itself continues to |
| 702 | exist as long as other Lisp objects point to it. All the Lisp |
| 703 | primitives that work on process objects accept deleted processes, but |
| 704 | those that do I/O or send signals will report an error. The process |
| 705 | mark continues to point to the same place as before, usually into a |
| 706 | buffer where output from the process was being inserted. |
| 707 | |
| 708 | @defopt delete-exited-processes |
| 709 | This variable controls automatic deletion of processes that have |
| 710 | terminated (due to calling @code{exit} or to a signal). If it is |
| 711 | @code{nil}, then they continue to exist until the user runs |
| 712 | @code{list-processes}. Otherwise, they are deleted immediately after |
| 713 | they exit. |
| 714 | @end defopt |
| 715 | |
| 716 | @defun delete-process process |
| 717 | This function deletes a process, killing it with a @code{SIGKILL} |
| 718 | signal. The argument may be a process, the name of a process, a |
| 719 | buffer, or the name of a buffer. (A buffer or buffer-name stands for |
| 720 | the process that @code{get-buffer-process} returns.) Calling |
| 721 | @code{delete-process} on a running process terminates it, updates the |
| 722 | process status, and runs the sentinel (if any) immediately. If the |
| 723 | process has already terminated, calling @code{delete-process} has no |
| 724 | effect on its status, or on the running of its sentinel (which will |
| 725 | happen sooner or later). |
| 726 | |
| 727 | @smallexample |
| 728 | @group |
| 729 | (delete-process "*shell*") |
| 730 | @result{} nil |
| 731 | @end group |
| 732 | @end smallexample |
| 733 | @end defun |
| 734 | |
| 735 | @node Process Information |
| 736 | @section Process Information |
| 737 | |
| 738 | Several functions return information about processes. |
| 739 | |
| 740 | @deffn Command list-processes &optional query-only buffer |
| 741 | This command displays a listing of all living processes. In addition, |
| 742 | it finally deletes any process whose status was @samp{Exited} or |
| 743 | @samp{Signaled}. It returns @code{nil}. |
| 744 | |
| 745 | The processes are shown in a buffer named @file{*Process List*} |
| 746 | (unless you specify otherwise using the optional argument @var{buffer}), |
| 747 | whose major mode is Process Menu mode. |
| 748 | |
| 749 | If @var{query-only} is non-@code{nil}, it only lists processes |
| 750 | whose query flag is non-@code{nil}. @xref{Query Before Exit}. |
| 751 | @end deffn |
| 752 | |
| 753 | @defun process-list |
| 754 | This function returns a list of all processes that have not been deleted. |
| 755 | |
| 756 | @smallexample |
| 757 | @group |
| 758 | (process-list) |
| 759 | @result{} (#<process display-time> #<process shell>) |
| 760 | @end group |
| 761 | @end smallexample |
| 762 | @end defun |
| 763 | |
| 764 | @defun get-process name |
| 765 | This function returns the process named @var{name} (a string), or |
| 766 | @code{nil} if there is none. |
| 767 | |
| 768 | @smallexample |
| 769 | @group |
| 770 | (get-process "shell") |
| 771 | @result{} #<process shell> |
| 772 | @end group |
| 773 | @end smallexample |
| 774 | @end defun |
| 775 | |
| 776 | @defun process-command process |
| 777 | This function returns the command that was executed to start |
| 778 | @var{process}. This is a list of strings, the first string being the |
| 779 | program executed and the rest of the strings being the arguments that |
| 780 | were given to the program. |
| 781 | |
| 782 | @smallexample |
| 783 | @group |
| 784 | (process-command (get-process "shell")) |
| 785 | @result{} ("bash" "-i") |
| 786 | @end group |
| 787 | @end smallexample |
| 788 | @end defun |
| 789 | |
| 790 | @defun process-contact process &optional key |
| 791 | |
| 792 | This function returns information about how a network or serial |
| 793 | process was set up. When @var{key} is @code{nil}, it returns |
| 794 | @code{(@var{hostname} @var{service})} for a network process, and |
| 795 | @code{(@var{port} @var{speed})} for a serial process. |
| 796 | For an ordinary child process, this function always returns @code{t}. |
| 797 | |
| 798 | If @var{key} is @code{t}, the value is the complete status information |
| 799 | for the connection, server, or serial port; that is, the list of |
| 800 | keywords and values specified in @code{make-network-process} or |
| 801 | @code{make-serial-process}, except that some of the values represent |
| 802 | the current status instead of what you specified. |
| 803 | |
| 804 | For a network process, the values include (see |
| 805 | @code{make-network-process} for a complete list): |
| 806 | |
| 807 | @table @code |
| 808 | @item :buffer |
| 809 | The associated value is the process buffer. |
| 810 | @item :filter |
| 811 | The associated value is the process filter function. |
| 812 | @item :sentinel |
| 813 | The associated value is the process sentinel function. |
| 814 | @item :remote |
| 815 | In a connection, the address in internal format of the remote peer. |
| 816 | @item :local |
| 817 | The local address, in internal format. |
| 818 | @item :service |
| 819 | In a server, if you specified @code{t} for @var{service}, |
| 820 | this value is the actual port number. |
| 821 | @end table |
| 822 | |
| 823 | @code{:local} and @code{:remote} are included even if they were not |
| 824 | specified explicitly in @code{make-network-process}. |
| 825 | |
| 826 | For a serial process, see @code{make-serial-process} and |
| 827 | @code{serial-process-configure} for a list of keys. |
| 828 | |
| 829 | If @var{key} is a keyword, the function returns the value corresponding |
| 830 | to that keyword. |
| 831 | @end defun |
| 832 | |
| 833 | @defun process-id process |
| 834 | This function returns the @acronym{PID} of @var{process}. This is an |
| 835 | integer that distinguishes the process @var{process} from all other |
| 836 | processes running on the same computer at the current time. The |
| 837 | @acronym{PID} of a process is chosen by the operating system kernel when the |
| 838 | process is started and remains constant as long as the process exists. |
| 839 | @end defun |
| 840 | |
| 841 | @defun process-name process |
| 842 | This function returns the name of @var{process}, as a string. |
| 843 | @end defun |
| 844 | |
| 845 | @defun process-status process-name |
| 846 | This function returns the status of @var{process-name} as a symbol. |
| 847 | The argument @var{process-name} must be a process, a buffer, or a |
| 848 | process name (a string). |
| 849 | |
| 850 | The possible values for an actual subprocess are: |
| 851 | |
| 852 | @table @code |
| 853 | @item run |
| 854 | for a process that is running. |
| 855 | @item stop |
| 856 | for a process that is stopped but continuable. |
| 857 | @item exit |
| 858 | for a process that has exited. |
| 859 | @item signal |
| 860 | for a process that has received a fatal signal. |
| 861 | @item open |
| 862 | for a network connection that is open. |
| 863 | @item closed |
| 864 | for a network connection that is closed. Once a connection |
| 865 | is closed, you cannot reopen it, though you might be able to open |
| 866 | a new connection to the same place. |
| 867 | @item connect |
| 868 | for a non-blocking connection that is waiting to complete. |
| 869 | @item failed |
| 870 | for a non-blocking connection that has failed to complete. |
| 871 | @item listen |
| 872 | for a network server that is listening. |
| 873 | @item nil |
| 874 | if @var{process-name} is not the name of an existing process. |
| 875 | @end table |
| 876 | |
| 877 | @smallexample |
| 878 | @group |
| 879 | (process-status (get-buffer "*shell*")) |
| 880 | @result{} run |
| 881 | @end group |
| 882 | @end smallexample |
| 883 | |
| 884 | For a network connection, @code{process-status} returns one of the symbols |
| 885 | @code{open} or @code{closed}. The latter means that the other side |
| 886 | closed the connection, or Emacs did @code{delete-process}. |
| 887 | @end defun |
| 888 | |
| 889 | @defun process-live-p process |
| 890 | This function returns non-@code{nil} if @var{process} is alive. A |
| 891 | process is considered alive if its status is @code{run}, @code{open}, |
| 892 | @code{listen}, @code{connect} or @code{stop}. |
| 893 | @end defun |
| 894 | |
| 895 | @defun process-type process |
| 896 | This function returns the symbol @code{network} for a network |
| 897 | connection or server, @code{serial} for a serial port connection, or |
| 898 | @code{real} for a real subprocess. |
| 899 | @end defun |
| 900 | |
| 901 | @defun process-exit-status process |
| 902 | This function returns the exit status of @var{process} or the signal |
| 903 | number that killed it. (Use the result of @code{process-status} to |
| 904 | determine which of those it is.) If @var{process} has not yet |
| 905 | terminated, the value is 0. |
| 906 | @end defun |
| 907 | |
| 908 | @defun process-tty-name process |
| 909 | This function returns the terminal name that @var{process} is using for |
| 910 | its communication with Emacs---or @code{nil} if it is using pipes |
| 911 | instead of a terminal (see @code{process-connection-type} in |
| 912 | @ref{Asynchronous Processes}). If @var{process} represents a program |
| 913 | running on a remote host, the terminal name used by that program on |
| 914 | the remote host is provided as process property @code{remote-tty}. |
| 915 | @end defun |
| 916 | |
| 917 | @defun process-coding-system process |
| 918 | @anchor{Coding systems for a subprocess} |
| 919 | This function returns a cons cell @code{(@var{decode} . @var{encode})}, |
| 920 | describing the coding systems in use for decoding output from, and |
| 921 | encoding input to, @var{process} (@pxref{Coding Systems}). |
| 922 | @end defun |
| 923 | |
| 924 | @defun set-process-coding-system process &optional decoding-system encoding-system |
| 925 | This function specifies the coding systems to use for subsequent output |
| 926 | from and input to @var{process}. It will use @var{decoding-system} to |
| 927 | decode subprocess output, and @var{encoding-system} to encode subprocess |
| 928 | input. |
| 929 | @end defun |
| 930 | |
| 931 | Every process also has a property list that you can use to store |
| 932 | miscellaneous values associated with the process. |
| 933 | |
| 934 | @defun process-get process propname |
| 935 | This function returns the value of the @var{propname} property |
| 936 | of @var{process}. |
| 937 | @end defun |
| 938 | |
| 939 | @defun process-put process propname value |
| 940 | This function sets the value of the @var{propname} property |
| 941 | of @var{process} to @var{value}. |
| 942 | @end defun |
| 943 | |
| 944 | @defun process-plist process |
| 945 | This function returns the process plist of @var{process}. |
| 946 | @end defun |
| 947 | |
| 948 | @defun set-process-plist process plist |
| 949 | This function sets the process plist of @var{process} to @var{plist}. |
| 950 | @end defun |
| 951 | |
| 952 | @node Input to Processes |
| 953 | @section Sending Input to Processes |
| 954 | @cindex process input |
| 955 | |
| 956 | Asynchronous subprocesses receive input when it is sent to them by |
| 957 | Emacs, which is done with the functions in this section. You must |
| 958 | specify the process to send input to, and the input data to send. The |
| 959 | data appears on the ``standard input'' of the subprocess. |
| 960 | |
| 961 | @c FIXME which? |
| 962 | Some operating systems have limited space for buffered input in a |
| 963 | pty. On these systems, Emacs sends an @acronym{EOF} periodically |
| 964 | amidst the other characters, to force them through. For most |
| 965 | programs, these @acronym{EOF}s do no harm. |
| 966 | |
| 967 | Subprocess input is normally encoded using a coding system before the |
| 968 | subprocess receives it, much like text written into a file. You can use |
| 969 | @code{set-process-coding-system} to specify which coding system to use |
| 970 | (@pxref{Process Information}). Otherwise, the coding system comes from |
| 971 | @code{coding-system-for-write}, if that is non-@code{nil}; or else from |
| 972 | the defaulting mechanism (@pxref{Default Coding Systems}). |
| 973 | |
| 974 | Sometimes the system is unable to accept input for that process, |
| 975 | because the input buffer is full. When this happens, the send functions |
| 976 | wait a short while, accepting output from subprocesses, and then try |
| 977 | again. This gives the subprocess a chance to read more of its pending |
| 978 | input and make space in the buffer. It also allows filters, sentinels |
| 979 | and timers to run---so take account of that in writing your code. |
| 980 | |
| 981 | In these functions, the @var{process} argument can be a process or |
| 982 | the name of a process, or a buffer or buffer name (which stands |
| 983 | for a process via @code{get-buffer-process}). @code{nil} means |
| 984 | the current buffer's process. |
| 985 | |
| 986 | @defun process-send-string process string |
| 987 | This function sends @var{process} the contents of @var{string} as |
| 988 | standard input. It returns @code{nil}. For example, to make a |
| 989 | Shell buffer list files: |
| 990 | |
| 991 | @smallexample |
| 992 | @group |
| 993 | (process-send-string "shell<1>" "ls\n") |
| 994 | @result{} nil |
| 995 | @end group |
| 996 | @end smallexample |
| 997 | @end defun |
| 998 | |
| 999 | @defun process-send-region process start end |
| 1000 | This function sends the text in the region defined by @var{start} and |
| 1001 | @var{end} as standard input to @var{process}. |
| 1002 | |
| 1003 | An error is signaled unless both @var{start} and @var{end} are |
| 1004 | integers or markers that indicate positions in the current buffer. (It |
| 1005 | is unimportant which number is larger.) |
| 1006 | @end defun |
| 1007 | |
| 1008 | @defun process-send-eof &optional process |
| 1009 | This function makes @var{process} see an end-of-file in its |
| 1010 | input. The @acronym{EOF} comes after any text already sent to it. |
| 1011 | The function returns @var{process}. |
| 1012 | |
| 1013 | @smallexample |
| 1014 | @group |
| 1015 | (process-send-eof "shell") |
| 1016 | @result{} "shell" |
| 1017 | @end group |
| 1018 | @end smallexample |
| 1019 | @end defun |
| 1020 | |
| 1021 | @defun process-running-child-p &optional process |
| 1022 | This function will tell you whether a @var{process} has given control of |
| 1023 | its terminal to its own child process. The value is @code{t} if this is |
| 1024 | true, or if Emacs cannot tell; it is @code{nil} if Emacs can be certain |
| 1025 | that this is not so. |
| 1026 | @end defun |
| 1027 | |
| 1028 | @node Signals to Processes |
| 1029 | @section Sending Signals to Processes |
| 1030 | @cindex process signals |
| 1031 | @cindex sending signals |
| 1032 | @cindex signals |
| 1033 | |
| 1034 | @dfn{Sending a signal} to a subprocess is a way of interrupting its |
| 1035 | activities. There are several different signals, each with its own |
| 1036 | meaning. The set of signals and their names is defined by the operating |
| 1037 | system. For example, the signal @code{SIGINT} means that the user has |
| 1038 | typed @kbd{C-c}, or that some analogous thing has happened. |
| 1039 | |
| 1040 | Each signal has a standard effect on the subprocess. Most signals |
| 1041 | kill the subprocess, but some stop (or resume) execution instead. Most |
| 1042 | signals can optionally be handled by programs; if the program handles |
| 1043 | the signal, then we can say nothing in general about its effects. |
| 1044 | |
| 1045 | You can send signals explicitly by calling the functions in this |
| 1046 | section. Emacs also sends signals automatically at certain times: |
| 1047 | killing a buffer sends a @code{SIGHUP} signal to all its associated |
| 1048 | processes; killing Emacs sends a @code{SIGHUP} signal to all remaining |
| 1049 | processes. (@code{SIGHUP} is a signal that usually indicates that the |
| 1050 | user ``hung up the phone'', i.e., disconnected.) |
| 1051 | |
| 1052 | Each of the signal-sending functions takes two optional arguments: |
| 1053 | @var{process} and @var{current-group}. |
| 1054 | |
| 1055 | The argument @var{process} must be either a process, a process |
| 1056 | name, a buffer, a buffer name, or @code{nil}. A buffer or buffer name |
| 1057 | stands for a process through @code{get-buffer-process}. @code{nil} |
| 1058 | stands for the process associated with the current buffer. An error |
| 1059 | is signaled if @var{process} does not identify a process. |
| 1060 | |
| 1061 | The argument @var{current-group} is a flag that makes a difference |
| 1062 | when you are running a job-control shell as an Emacs subprocess. If it |
| 1063 | is non-@code{nil}, then the signal is sent to the current process-group |
| 1064 | of the terminal that Emacs uses to communicate with the subprocess. If |
| 1065 | the process is a job-control shell, this means the shell's current |
| 1066 | subjob. If it is @code{nil}, the signal is sent to the process group of |
| 1067 | the immediate subprocess of Emacs. If the subprocess is a job-control |
| 1068 | shell, this is the shell itself. |
| 1069 | |
| 1070 | The flag @var{current-group} has no effect when a pipe is used to |
| 1071 | communicate with the subprocess, because the operating system does not |
| 1072 | support the distinction in the case of pipes. For the same reason, |
| 1073 | job-control shells won't work when a pipe is used. See |
| 1074 | @code{process-connection-type} in @ref{Asynchronous Processes}. |
| 1075 | |
| 1076 | @defun interrupt-process &optional process current-group |
| 1077 | This function interrupts the process @var{process} by sending the |
| 1078 | signal @code{SIGINT}. Outside of Emacs, typing the ``interrupt |
| 1079 | character'' (normally @kbd{C-c} on some systems, and @key{DEL} on |
| 1080 | others) sends this signal. When the argument @var{current-group} is |
| 1081 | non-@code{nil}, you can think of this function as ``typing @kbd{C-c}'' |
| 1082 | on the terminal by which Emacs talks to the subprocess. |
| 1083 | @end defun |
| 1084 | |
| 1085 | @defun kill-process &optional process current-group |
| 1086 | This function kills the process @var{process} by sending the |
| 1087 | signal @code{SIGKILL}. This signal kills the subprocess immediately, |
| 1088 | and cannot be handled by the subprocess. |
| 1089 | @end defun |
| 1090 | |
| 1091 | @defun quit-process &optional process current-group |
| 1092 | This function sends the signal @code{SIGQUIT} to the process |
| 1093 | @var{process}. This signal is the one sent by the ``quit |
| 1094 | @c FIXME? Never heard of C-b being used for this. In readline, e.g., |
| 1095 | @c bash, that is backward-word. |
| 1096 | character'' (usually @kbd{C-b} or @kbd{C-\}) when you are not inside |
| 1097 | Emacs. |
| 1098 | @end defun |
| 1099 | |
| 1100 | @defun stop-process &optional process current-group |
| 1101 | This function stops the process @var{process} by sending the |
| 1102 | signal @code{SIGTSTP}. Use @code{continue-process} to resume its |
| 1103 | execution. |
| 1104 | |
| 1105 | Outside of Emacs, on systems with job control, the ``stop character'' |
| 1106 | (usually @kbd{C-z}) normally sends this signal. When |
| 1107 | @var{current-group} is non-@code{nil}, you can think of this function as |
| 1108 | ``typing @kbd{C-z}'' on the terminal Emacs uses to communicate with the |
| 1109 | subprocess. |
| 1110 | @end defun |
| 1111 | |
| 1112 | @defun continue-process &optional process current-group |
| 1113 | This function resumes execution of the process @var{process} by sending |
| 1114 | it the signal @code{SIGCONT}. This presumes that @var{process} was |
| 1115 | stopped previously. |
| 1116 | @end defun |
| 1117 | |
| 1118 | @deffn Command signal-process process signal |
| 1119 | This function sends a signal to process @var{process}. The argument |
| 1120 | @var{signal} specifies which signal to send; it should be an integer, |
| 1121 | or a symbol whose name is a signal. |
| 1122 | |
| 1123 | The @var{process} argument can be a system process @acronym{ID} (an |
| 1124 | integer); that allows you to send signals to processes that are not |
| 1125 | children of Emacs. @xref{System Processes}. |
| 1126 | @end deffn |
| 1127 | |
| 1128 | @node Output from Processes |
| 1129 | @section Receiving Output from Processes |
| 1130 | @cindex process output |
| 1131 | @cindex output from processes |
| 1132 | |
| 1133 | There are two ways to receive the output that a subprocess writes to |
| 1134 | its standard output stream. The output can be inserted in a buffer, |
| 1135 | which is called the associated buffer of the process (@pxref{Process |
| 1136 | Buffers}), or a function called the @dfn{filter function} can be |
| 1137 | called to act on the output. If the process has no buffer and no |
| 1138 | filter function, its output is discarded. |
| 1139 | |
| 1140 | When a subprocess terminates, Emacs reads any pending output, |
| 1141 | then stops reading output from that subprocess. Therefore, if the |
| 1142 | subprocess has children that are still live and still producing |
| 1143 | output, Emacs won't receive that output. |
| 1144 | |
| 1145 | Output from a subprocess can arrive only while Emacs is waiting: when |
| 1146 | reading terminal input (see the function @code{waiting-for-user-input-p}), |
| 1147 | in @code{sit-for} and @code{sleep-for} (@pxref{Waiting}), and in |
| 1148 | @code{accept-process-output} (@pxref{Accepting Output}). This |
| 1149 | minimizes the problem of timing errors that usually plague parallel |
| 1150 | programming. For example, you can safely create a process and only |
| 1151 | then specify its buffer or filter function; no output can arrive |
| 1152 | before you finish, if the code in between does not call any primitive |
| 1153 | that waits. |
| 1154 | |
| 1155 | @defvar process-adaptive-read-buffering |
| 1156 | On some systems, when Emacs reads the output from a subprocess, the |
| 1157 | output data is read in very small blocks, potentially resulting in |
| 1158 | very poor performance. This behavior can be remedied to some extent |
| 1159 | by setting the variable @code{process-adaptive-read-buffering} to a |
| 1160 | non-@code{nil} value (the default), as it will automatically delay reading |
| 1161 | from such processes, thus allowing them to produce more output before |
| 1162 | Emacs tries to read it. |
| 1163 | @end defvar |
| 1164 | |
| 1165 | It is impossible to separate the standard output and standard error |
| 1166 | streams of the subprocess, because Emacs normally spawns the subprocess |
| 1167 | inside a pseudo-TTY, and a pseudo-TTY has only one output channel. If |
| 1168 | you want to keep the output to those streams separate, you should |
| 1169 | redirect one of them to a file---for example, by using an appropriate |
| 1170 | shell command. |
| 1171 | |
| 1172 | @menu |
| 1173 | * Process Buffers:: If no filter, output is put in a buffer. |
| 1174 | * Filter Functions:: Filter functions accept output from the process. |
| 1175 | * Decoding Output:: Filters can get unibyte or multibyte strings. |
| 1176 | * Accepting Output:: How to wait until process output arrives. |
| 1177 | @end menu |
| 1178 | |
| 1179 | @node Process Buffers |
| 1180 | @subsection Process Buffers |
| 1181 | |
| 1182 | A process can (and usually does) have an @dfn{associated buffer}, |
| 1183 | which is an ordinary Emacs buffer that is used for two purposes: storing |
| 1184 | the output from the process, and deciding when to kill the process. You |
| 1185 | can also use the buffer to identify a process to operate on, since in |
| 1186 | normal practice only one process is associated with any given buffer. |
| 1187 | Many applications of processes also use the buffer for editing input to |
| 1188 | be sent to the process, but this is not built into Emacs Lisp. |
| 1189 | |
| 1190 | Unless the process has a filter function (@pxref{Filter Functions}), |
| 1191 | its output is inserted in the associated buffer. The position to insert |
| 1192 | the output is determined by the @code{process-mark}, which is then |
| 1193 | updated to point to the end of the text just inserted. Usually, but not |
| 1194 | always, the @code{process-mark} is at the end of the buffer. |
| 1195 | |
| 1196 | @findex process-kill-buffer-query-function |
| 1197 | Killing the associated buffer of a process also kills the process. |
| 1198 | Emacs asks for confirmation first, if the process's |
| 1199 | @code{process-query-on-exit-flag} is non-@code{nil} (@pxref{Query |
| 1200 | Before Exit}). This confirmation is done by the function |
| 1201 | @code{process-kill-buffer-query-function}, which is run from |
| 1202 | @code{kill-buffer-query-functions} (@pxref{Killing Buffers}). |
| 1203 | |
| 1204 | @defun process-buffer process |
| 1205 | This function returns the associated buffer of the process |
| 1206 | @var{process}. |
| 1207 | |
| 1208 | @smallexample |
| 1209 | @group |
| 1210 | (process-buffer (get-process "shell")) |
| 1211 | @result{} #<buffer *shell*> |
| 1212 | @end group |
| 1213 | @end smallexample |
| 1214 | @end defun |
| 1215 | |
| 1216 | @defun process-mark process |
| 1217 | This function returns the process marker for @var{process}, which is the |
| 1218 | marker that says where to insert output from the process. |
| 1219 | |
| 1220 | If @var{process} does not have a buffer, @code{process-mark} returns a |
| 1221 | marker that points nowhere. |
| 1222 | |
| 1223 | Insertion of process output in a buffer uses this marker to decide where |
| 1224 | to insert, and updates it to point after the inserted text. That is why |
| 1225 | successive batches of output are inserted consecutively. |
| 1226 | |
| 1227 | Filter functions normally should use this marker in the same fashion |
| 1228 | as is done by direct insertion of output in the buffer. For an |
| 1229 | example of a filter function that uses @code{process-mark}, |
| 1230 | @pxref{Process Filter Example}. |
| 1231 | |
| 1232 | When the user is expected to enter input in the process buffer for |
| 1233 | transmission to the process, the process marker separates the new input |
| 1234 | from previous output. |
| 1235 | @end defun |
| 1236 | |
| 1237 | @defun set-process-buffer process buffer |
| 1238 | This function sets the buffer associated with @var{process} to |
| 1239 | @var{buffer}. If @var{buffer} is @code{nil}, the process becomes |
| 1240 | associated with no buffer. |
| 1241 | @end defun |
| 1242 | |
| 1243 | @defun get-buffer-process buffer-or-name |
| 1244 | This function returns a nondeleted process associated with the buffer |
| 1245 | specified by @var{buffer-or-name}. If there are several processes |
| 1246 | associated with it, this function chooses one (currently, the one most |
| 1247 | recently created, but don't count on that). Deletion of a process |
| 1248 | (see @code{delete-process}) makes it ineligible for this function to |
| 1249 | return. |
| 1250 | |
| 1251 | It is usually a bad idea to have more than one process associated with |
| 1252 | the same buffer. |
| 1253 | |
| 1254 | @smallexample |
| 1255 | @group |
| 1256 | (get-buffer-process "*shell*") |
| 1257 | @result{} #<process shell> |
| 1258 | @end group |
| 1259 | @end smallexample |
| 1260 | |
| 1261 | Killing the process's buffer deletes the process, which kills the |
| 1262 | subprocess with a @code{SIGHUP} signal (@pxref{Signals to Processes}). |
| 1263 | @end defun |
| 1264 | |
| 1265 | @node Filter Functions |
| 1266 | @subsection Process Filter Functions |
| 1267 | @cindex filter function |
| 1268 | @cindex process filter |
| 1269 | |
| 1270 | A process @dfn{filter function} is a function that receives the |
| 1271 | standard output from the associated process. If a process has a filter, |
| 1272 | then @emph{all} output from that process is passed to the filter. The |
| 1273 | process buffer is used directly for output from the process only when |
| 1274 | there is no filter. |
| 1275 | |
| 1276 | The filter function can only be called when Emacs is waiting for |
| 1277 | something, because process output arrives only at such times. Emacs |
| 1278 | waits when reading terminal input (see the function |
| 1279 | @code{waiting-for-user-input-p}), in @code{sit-for} and |
| 1280 | @code{sleep-for} (@pxref{Waiting}), and in |
| 1281 | @code{accept-process-output} (@pxref{Accepting Output}). |
| 1282 | |
| 1283 | A filter function must accept two arguments: the associated process |
| 1284 | and a string, which is output just received from it. The function is |
| 1285 | then free to do whatever it chooses with the output. |
| 1286 | |
| 1287 | @c Note this text is duplicated in the sentinels section. |
| 1288 | Quitting is normally inhibited within a filter function---otherwise, |
| 1289 | the effect of typing @kbd{C-g} at command level or to quit a user |
| 1290 | command would be unpredictable. If you want to permit quitting inside |
| 1291 | a filter function, bind @code{inhibit-quit} to @code{nil}. In most |
| 1292 | cases, the right way to do this is with the macro |
| 1293 | @code{with-local-quit}. @xref{Quitting}. |
| 1294 | |
| 1295 | If an error happens during execution of a filter function, it is |
| 1296 | caught automatically, so that it doesn't stop the execution of whatever |
| 1297 | program was running when the filter function was started. However, if |
| 1298 | @code{debug-on-error} is non-@code{nil}, errors are not caught. |
| 1299 | This makes it possible to use the Lisp debugger to debug the |
| 1300 | filter function. @xref{Debugger}. |
| 1301 | |
| 1302 | Many filter functions sometimes (or always) insert the output in the |
| 1303 | process's buffer, mimicking the actions of Emacs when there is no |
| 1304 | filter. Such filter functions need to make sure that they save the |
| 1305 | current buffer, select the correct buffer (if different) before |
| 1306 | inserting output, and then restore the original buffer. |
| 1307 | They should also check whether the buffer is still alive, update the |
| 1308 | process marker, and in some cases update the value of point. Here is |
| 1309 | how to do these things: |
| 1310 | |
| 1311 | @anchor{Process Filter Example} |
| 1312 | @smallexample |
| 1313 | @group |
| 1314 | (defun ordinary-insertion-filter (proc string) |
| 1315 | (when (buffer-live-p (process-buffer proc)) |
| 1316 | (with-current-buffer (process-buffer proc) |
| 1317 | (let ((moving (= (point) (process-mark proc)))) |
| 1318 | @end group |
| 1319 | @group |
| 1320 | (save-excursion |
| 1321 | ;; @r{Insert the text, advancing the process marker.} |
| 1322 | (goto-char (process-mark proc)) |
| 1323 | (insert string) |
| 1324 | (set-marker (process-mark proc) (point))) |
| 1325 | (if moving (goto-char (process-mark proc))))))) |
| 1326 | @end group |
| 1327 | @end smallexample |
| 1328 | |
| 1329 | To make the filter force the process buffer to be visible whenever new |
| 1330 | text arrives, you could insert a line like the following just before the |
| 1331 | @code{with-current-buffer} construct: |
| 1332 | |
| 1333 | @smallexample |
| 1334 | (display-buffer (process-buffer proc)) |
| 1335 | @end smallexample |
| 1336 | |
| 1337 | To force point to the end of the new output, no matter where it was |
| 1338 | previously, eliminate the variable @code{moving} and call |
| 1339 | @code{goto-char} unconditionally. |
| 1340 | |
| 1341 | @ignore |
| 1342 | In earlier Emacs versions, every filter function that did regular |
| 1343 | expression searching or matching had to explicitly save and restore the |
| 1344 | match data. Now Emacs does this automatically for filter functions; |
| 1345 | they never need to do it explicitly. |
| 1346 | @end ignore |
| 1347 | Note that Emacs automatically saves and restores the match data |
| 1348 | while executing filter functions. @xref{Match Data}. |
| 1349 | |
| 1350 | The output to the filter may come in chunks of any size. A program |
| 1351 | that produces the same output twice in a row may send it as one batch of |
| 1352 | 200 characters one time, and five batches of 40 characters the next. If |
| 1353 | the filter looks for certain text strings in the subprocess output, make |
| 1354 | sure to handle the case where one of these strings is split across two |
| 1355 | or more batches of output; one way to do this is to insert the |
| 1356 | received text into a temporary buffer, which can then be searched. |
| 1357 | |
| 1358 | @defun set-process-filter process filter |
| 1359 | This function gives @var{process} the filter function @var{filter}. If |
| 1360 | @var{filter} is @code{nil}, it gives the process no filter. |
| 1361 | @end defun |
| 1362 | |
| 1363 | @defun process-filter process |
| 1364 | This function returns the filter function of @var{process}, or @code{nil} |
| 1365 | if it has none. |
| 1366 | @end defun |
| 1367 | |
| 1368 | Here is an example of the use of a filter function: |
| 1369 | |
| 1370 | @smallexample |
| 1371 | @group |
| 1372 | (defun keep-output (process output) |
| 1373 | (setq kept (cons output kept))) |
| 1374 | @result{} keep-output |
| 1375 | @end group |
| 1376 | @group |
| 1377 | (setq kept nil) |
| 1378 | @result{} nil |
| 1379 | @end group |
| 1380 | @group |
| 1381 | (set-process-filter (get-process "shell") 'keep-output) |
| 1382 | @result{} keep-output |
| 1383 | @end group |
| 1384 | @group |
| 1385 | (process-send-string "shell" "ls ~/other\n") |
| 1386 | @result{} nil |
| 1387 | kept |
| 1388 | @result{} ("lewis@@slug:$ " |
| 1389 | @end group |
| 1390 | @group |
| 1391 | "FINAL-W87-SHORT.MSS backup.otl kolstad.mss~ |
| 1392 | address.txt backup.psf kolstad.psf |
| 1393 | backup.bib~ david.mss resume-Dec-86.mss~ |
| 1394 | backup.err david.psf resume-Dec.psf |
| 1395 | backup.mss dland syllabus.mss |
| 1396 | " |
| 1397 | "#backups.mss# backup.mss~ kolstad.mss |
| 1398 | ") |
| 1399 | @end group |
| 1400 | @end smallexample |
| 1401 | |
| 1402 | @ignore @c The code in this example doesn't show the right way to do things. |
| 1403 | Here is another, more realistic example, which demonstrates how to use |
| 1404 | the process mark to do insertion in the same fashion as is done when |
| 1405 | there is no filter function: |
| 1406 | |
| 1407 | @smallexample |
| 1408 | @group |
| 1409 | ;; @r{Insert input in the buffer specified by @code{my-shell-buffer}} |
| 1410 | ;; @r{and make sure that buffer is shown in some window.} |
| 1411 | (defun my-process-filter (proc str) |
| 1412 | (let ((cur (selected-window)) |
| 1413 | (pop-up-windows t)) |
| 1414 | (pop-to-buffer my-shell-buffer) |
| 1415 | @end group |
| 1416 | @group |
| 1417 | (goto-char (point-max)) |
| 1418 | (insert str) |
| 1419 | (set-marker (process-mark proc) (point-max)) |
| 1420 | (select-window cur))) |
| 1421 | @end group |
| 1422 | @end smallexample |
| 1423 | @end ignore |
| 1424 | |
| 1425 | @node Decoding Output |
| 1426 | @subsection Decoding Process Output |
| 1427 | @cindex decode process output |
| 1428 | |
| 1429 | When Emacs writes process output directly into a multibyte buffer, |
| 1430 | it decodes the output according to the process output coding system. |
| 1431 | If the coding system is @code{raw-text} or @code{no-conversion}, Emacs |
| 1432 | converts the unibyte output to multibyte using |
| 1433 | @code{string-to-multibyte}, and inserts the resulting multibyte text. |
| 1434 | |
| 1435 | You can use @code{set-process-coding-system} to specify which coding |
| 1436 | system to use (@pxref{Process Information}). Otherwise, the coding |
| 1437 | system comes from @code{coding-system-for-read}, if that is |
| 1438 | non-@code{nil}; or else from the defaulting mechanism (@pxref{Default |
| 1439 | Coding Systems}). If the text output by a process contains null |
| 1440 | bytes, Emacs by default uses @code{no-conversion} for it; see |
| 1441 | @ref{Lisp and Coding Systems, inhibit-null-byte-detection}, for how to |
| 1442 | control this behavior. |
| 1443 | |
| 1444 | @strong{Warning:} Coding systems such as @code{undecided}, which |
| 1445 | determine the coding system from the data, do not work entirely |
| 1446 | reliably with asynchronous subprocess output. This is because Emacs |
| 1447 | has to process asynchronous subprocess output in batches, as it |
| 1448 | arrives. Emacs must try to detect the proper coding system from one |
| 1449 | batch at a time, and this does not always work. Therefore, if at all |
| 1450 | possible, specify a coding system that determines both the character |
| 1451 | code conversion and the end of line conversion---that is, one like |
| 1452 | @code{latin-1-unix}, rather than @code{undecided} or @code{latin-1}. |
| 1453 | |
| 1454 | @c Let's keep the index entries that were there for |
| 1455 | @c set-process-filter-multibyte and process-filter-multibyte-p, |
| 1456 | @cindex filter multibyte flag, of process |
| 1457 | @cindex process filter multibyte flag |
| 1458 | When Emacs calls a process filter function, it provides the process |
| 1459 | output as a multibyte string or as a unibyte string according to the |
| 1460 | process's filter coding system. Emacs |
| 1461 | decodes the output according to the process output coding system, |
| 1462 | which usually produces a multibyte string, except for coding systems |
| 1463 | such as @code{binary} and @code{raw-text}. |
| 1464 | |
| 1465 | @node Accepting Output |
| 1466 | @subsection Accepting Output from Processes |
| 1467 | @cindex accept input from processes |
| 1468 | |
| 1469 | Output from asynchronous subprocesses normally arrives only while |
| 1470 | Emacs is waiting for some sort of external event, such as elapsed time |
| 1471 | or terminal input. Occasionally it is useful in a Lisp program to |
| 1472 | explicitly permit output to arrive at a specific point, or even to wait |
| 1473 | until output arrives from a process. |
| 1474 | |
| 1475 | @defun accept-process-output &optional process seconds millisec just-this-one |
| 1476 | This function allows Emacs to read pending output from processes. The |
| 1477 | output is inserted in the associated buffers or given to their filter |
| 1478 | functions. If @var{process} is non-@code{nil} then this function does |
| 1479 | not return until some output has been received from @var{process}. |
| 1480 | |
| 1481 | The arguments @var{seconds} and @var{millisec} let you specify timeout |
| 1482 | periods. The former specifies a period measured in seconds and the |
| 1483 | latter specifies one measured in milliseconds. The two time periods |
| 1484 | thus specified are added together, and @code{accept-process-output} |
| 1485 | returns after that much time, whether or not there has been any |
| 1486 | subprocess output. |
| 1487 | |
| 1488 | The argument @var{millisec} is obsolete (and should not be used), |
| 1489 | because @var{seconds} can be a floating point number to specify |
| 1490 | waiting a fractional number of seconds. If @var{seconds} is 0, the |
| 1491 | function accepts whatever output is pending but does not wait. |
| 1492 | |
| 1493 | @c Emacs 22.1 feature |
| 1494 | If @var{process} is a process, and the argument @var{just-this-one} is |
| 1495 | non-@code{nil}, only output from that process is handled, suspending output |
| 1496 | from other processes until some output has been received from that |
| 1497 | process or the timeout expires. If @var{just-this-one} is an integer, |
| 1498 | also inhibit running timers. This feature is generally not |
| 1499 | recommended, but may be necessary for specific applications, such as |
| 1500 | speech synthesis. |
| 1501 | |
| 1502 | The function @code{accept-process-output} returns non-@code{nil} if it |
| 1503 | did get some output, or @code{nil} if the timeout expired before output |
| 1504 | arrived. |
| 1505 | @end defun |
| 1506 | |
| 1507 | @node Sentinels |
| 1508 | @section Sentinels: Detecting Process Status Changes |
| 1509 | @cindex process sentinel |
| 1510 | @cindex sentinel (of process) |
| 1511 | |
| 1512 | A @dfn{process sentinel} is a function that is called whenever the |
| 1513 | associated process changes status for any reason, including signals |
| 1514 | (whether sent by Emacs or caused by the process's own actions) that |
| 1515 | terminate, stop, or continue the process. The process sentinel is |
| 1516 | also called if the process exits. The sentinel receives two |
| 1517 | arguments: the process for which the event occurred, and a string |
| 1518 | describing the type of event. |
| 1519 | |
| 1520 | The string describing the event looks like one of the following: |
| 1521 | |
| 1522 | @c FIXME? Also "killed\n" - see example below? |
| 1523 | @itemize @bullet |
| 1524 | @item |
| 1525 | @code{"finished\n"}. |
| 1526 | |
| 1527 | @item |
| 1528 | @code{"exited abnormally with code @var{exitcode}\n"}. |
| 1529 | |
| 1530 | @item |
| 1531 | @code{"@var{name-of-signal}\n"}. |
| 1532 | |
| 1533 | @item |
| 1534 | @code{"@var{name-of-signal} (core dumped)\n"}. |
| 1535 | @end itemize |
| 1536 | |
| 1537 | A sentinel runs only while Emacs is waiting (e.g., for terminal |
| 1538 | input, or for time to elapse, or for process output). This avoids the |
| 1539 | timing errors that could result from running sentinels at random places in |
| 1540 | the middle of other Lisp programs. A program can wait, so that |
| 1541 | sentinels will run, by calling @code{sit-for} or @code{sleep-for} |
| 1542 | (@pxref{Waiting}), or @code{accept-process-output} (@pxref{Accepting |
| 1543 | Output}). Emacs also allows sentinels to run when the command loop is |
| 1544 | reading input. @code{delete-process} calls the sentinel when it |
| 1545 | terminates a running process. |
| 1546 | |
| 1547 | Emacs does not keep a queue of multiple reasons to call the sentinel |
| 1548 | of one process; it records just the current status and the fact that |
| 1549 | there has been a change. Therefore two changes in status, coming in |
| 1550 | quick succession, can call the sentinel just once. However, process |
| 1551 | termination will always run the sentinel exactly once. This is |
| 1552 | because the process status can't change again after termination. |
| 1553 | |
| 1554 | Emacs explicitly checks for output from the process before running |
| 1555 | the process sentinel. Once the sentinel runs due to process |
| 1556 | termination, no further output can arrive from the process. |
| 1557 | |
| 1558 | A sentinel that writes the output into the buffer of the process |
| 1559 | should check whether the buffer is still alive. If it tries to insert |
| 1560 | into a dead buffer, it will get an error. If the buffer is dead, |
| 1561 | @code{(buffer-name (process-buffer @var{process}))} returns @code{nil}. |
| 1562 | |
| 1563 | @c Note this text is duplicated in the filter functions section. |
| 1564 | Quitting is normally inhibited within a sentinel---otherwise, the |
| 1565 | effect of typing @kbd{C-g} at command level or to quit a user command |
| 1566 | would be unpredictable. If you want to permit quitting inside a |
| 1567 | sentinel, bind @code{inhibit-quit} to @code{nil}. In most cases, the |
| 1568 | right way to do this is with the macro @code{with-local-quit}. |
| 1569 | @xref{Quitting}. |
| 1570 | |
| 1571 | If an error happens during execution of a sentinel, it is caught |
| 1572 | automatically, so that it doesn't stop the execution of whatever |
| 1573 | programs was running when the sentinel was started. However, if |
| 1574 | @code{debug-on-error} is non-@code{nil}, errors are not caught. |
| 1575 | This makes it possible to use the Lisp debugger to debug the |
| 1576 | sentinel. @xref{Debugger}. |
| 1577 | |
| 1578 | While a sentinel is running, the process sentinel is temporarily |
| 1579 | set to @code{nil} so that the sentinel won't run recursively. |
| 1580 | For this reason it is not possible for a sentinel to specify |
| 1581 | a new sentinel. |
| 1582 | |
| 1583 | @ignore |
| 1584 | In earlier Emacs versions, every sentinel that did regular expression |
| 1585 | searching or matching had to explicitly save and restore the match data. |
| 1586 | Now Emacs does this automatically for sentinels; they never need to do |
| 1587 | it explicitly. |
| 1588 | @end ignore |
| 1589 | Note that Emacs automatically saves and restores the match data |
| 1590 | while executing sentinels. @xref{Match Data}. |
| 1591 | |
| 1592 | @defun set-process-sentinel process sentinel |
| 1593 | This function associates @var{sentinel} with @var{process}. If |
| 1594 | @var{sentinel} is @code{nil}, then the process will have no sentinel. |
| 1595 | The default behavior when there is no sentinel is to insert a message in |
| 1596 | the process's buffer when the process status changes. |
| 1597 | |
| 1598 | Changes in process sentinels take effect immediately---if the sentinel |
| 1599 | is slated to be run but has not been called yet, and you specify a new |
| 1600 | sentinel, the eventual call to the sentinel will use the new one. |
| 1601 | |
| 1602 | @smallexample |
| 1603 | @group |
| 1604 | (defun msg-me (process event) |
| 1605 | (princ |
| 1606 | (format "Process: %s had the event `%s'" process event))) |
| 1607 | (set-process-sentinel (get-process "shell") 'msg-me) |
| 1608 | @result{} msg-me |
| 1609 | @end group |
| 1610 | @group |
| 1611 | (kill-process (get-process "shell")) |
| 1612 | @print{} Process: #<process shell> had the event `killed' |
| 1613 | @result{} #<process shell> |
| 1614 | @end group |
| 1615 | @end smallexample |
| 1616 | @end defun |
| 1617 | |
| 1618 | @defun process-sentinel process |
| 1619 | This function returns the sentinel of @var{process}, or @code{nil} if it |
| 1620 | has none. |
| 1621 | @end defun |
| 1622 | |
| 1623 | @defun waiting-for-user-input-p |
| 1624 | While a sentinel or filter function is running, this function returns |
| 1625 | non-@code{nil} if Emacs was waiting for keyboard input from the user at |
| 1626 | the time the sentinel or filter function was called, or @code{nil} if it |
| 1627 | was not. |
| 1628 | @end defun |
| 1629 | |
| 1630 | @node Query Before Exit |
| 1631 | @section Querying Before Exit |
| 1632 | |
| 1633 | When Emacs exits, it terminates all its subprocesses by sending them |
| 1634 | the @code{SIGHUP} signal. Because subprocesses may be doing |
| 1635 | valuable work, Emacs normally asks the user to confirm that it is ok |
| 1636 | to terminate them. Each process has a query flag, which, if |
| 1637 | non-@code{nil}, says that Emacs should ask for confirmation before |
| 1638 | exiting and thus killing that process. The default for the query flag |
| 1639 | is @code{t}, meaning @emph{do} query. |
| 1640 | |
| 1641 | @defun process-query-on-exit-flag process |
| 1642 | This returns the query flag of @var{process}. |
| 1643 | @end defun |
| 1644 | |
| 1645 | @defun set-process-query-on-exit-flag process flag |
| 1646 | This function sets the query flag of @var{process} to @var{flag}. It |
| 1647 | returns @var{flag}. |
| 1648 | |
| 1649 | Here is an example of using @code{set-process-query-on-exit-flag} on a |
| 1650 | shell process to avoid querying: |
| 1651 | |
| 1652 | @smallexample |
| 1653 | @group |
| 1654 | (set-process-query-on-exit-flag (get-process "shell") nil) |
| 1655 | @result{} nil |
| 1656 | @end group |
| 1657 | @end smallexample |
| 1658 | @end defun |
| 1659 | |
| 1660 | @node System Processes |
| 1661 | @section Accessing Other Processes |
| 1662 | @cindex system processes |
| 1663 | |
| 1664 | In addition to accessing and manipulating processes that are |
| 1665 | subprocesses of the current Emacs session, Emacs Lisp programs can |
| 1666 | also access other processes running on the same machine. We call |
| 1667 | these @dfn{system processes}, to distinguish them from Emacs |
| 1668 | subprocesses. |
| 1669 | |
| 1670 | Emacs provides several primitives for accessing system processes. |
| 1671 | Not all platforms support these primitives; on those which don't, |
| 1672 | these primitives return @code{nil}. |
| 1673 | |
| 1674 | @defun list-system-processes |
| 1675 | This function returns a list of all the processes running on the |
| 1676 | system. Each process is identified by its @acronym{PID}, a numerical |
| 1677 | process ID that is assigned by the OS and distinguishes the process |
| 1678 | from all the other processes running on the same machine at the same |
| 1679 | time. |
| 1680 | @end defun |
| 1681 | |
| 1682 | @defun process-attributes pid |
| 1683 | This function returns an alist of attributes for the process specified |
| 1684 | by its process ID @var{pid}. Each association in the alist is of the |
| 1685 | form @code{(@var{key} . @var{value})}, where @var{key} designates the |
| 1686 | attribute and @var{value} is the value of that attribute. The various |
| 1687 | attribute @var{key}s that this function can return are listed below. |
| 1688 | Not all platforms support all of these attributes; if an attribute is |
| 1689 | not supported, its association will not appear in the returned alist. |
| 1690 | Values that are numbers can be either integer or floating-point, |
| 1691 | depending on the magnitude of the value. |
| 1692 | |
| 1693 | @table @code |
| 1694 | @item euid |
| 1695 | The effective user ID of the user who invoked the process. The |
| 1696 | corresponding @var{value} is a number. If the process was invoked by |
| 1697 | the same user who runs the current Emacs session, the value is |
| 1698 | identical to what @code{user-uid} returns (@pxref{User |
| 1699 | Identification}). |
| 1700 | |
| 1701 | @item user |
| 1702 | User name corresponding to the process's effective user ID, a string. |
| 1703 | |
| 1704 | @item egid |
| 1705 | The group ID of the effective user ID, a number. |
| 1706 | |
| 1707 | @item group |
| 1708 | Group name corresponding to the effective user's group ID, a string. |
| 1709 | |
| 1710 | @item comm |
| 1711 | The name of the command that runs in the process. This is a string |
| 1712 | that usually specifies the name of the executable file of the process, |
| 1713 | without the leading directories. However, some special system |
| 1714 | processes can report strings that do not correspond to an executable |
| 1715 | file of a program. |
| 1716 | |
| 1717 | @item state |
| 1718 | The state code of the process. This is a short string that encodes |
| 1719 | the scheduling state of the process. Here's a list of the most |
| 1720 | frequently seen codes: |
| 1721 | |
| 1722 | @table @code |
| 1723 | @item "D" |
| 1724 | uninterruptible sleep (usually I/O) |
| 1725 | @item "R" |
| 1726 | running |
| 1727 | @item "S" |
| 1728 | interruptible sleep (waiting for some event) |
| 1729 | @item "T" |
| 1730 | stopped, e.g., by a job control signal |
| 1731 | @item "Z" |
| 1732 | ``zombie'': a process that terminated, but was not reaped by its parent |
| 1733 | @end table |
| 1734 | |
| 1735 | @noindent |
| 1736 | For the full list of the possible states, see the manual page of the |
| 1737 | @command{ps} command. |
| 1738 | |
| 1739 | @item ppid |
| 1740 | The process ID of the parent process, a number. |
| 1741 | |
| 1742 | @item pgrp |
| 1743 | The process group ID of the process, a number. |
| 1744 | |
| 1745 | @item sess |
| 1746 | The session ID of the process. This is a number that is the process |
| 1747 | ID of the process's @dfn{session leader}. |
| 1748 | |
| 1749 | @item ttname |
| 1750 | A string that is the name of the process's controlling terminal. On |
| 1751 | Unix and GNU systems, this is normally the file name of the |
| 1752 | corresponding terminal device, such as @file{/dev/pts65}. |
| 1753 | |
| 1754 | @item tpgid |
| 1755 | The numerical process group ID of the foreground process group that |
| 1756 | uses the process's terminal. |
| 1757 | |
| 1758 | @item minflt |
| 1759 | The number of minor page faults caused by the process since its |
| 1760 | beginning. (Minor page faults are those that don't involve reading |
| 1761 | from disk.) |
| 1762 | |
| 1763 | @item majflt |
| 1764 | The number of major page faults caused by the process since its |
| 1765 | beginning. (Major page faults require a disk to be read, and are thus |
| 1766 | more expensive than minor page faults.) |
| 1767 | |
| 1768 | @item cminflt |
| 1769 | @itemx cmajflt |
| 1770 | Like @code{minflt} and @code{majflt}, but include the number of page |
| 1771 | faults for all the child processes of the given process. |
| 1772 | |
| 1773 | @item utime |
| 1774 | Time spent by the process in the user context, for running the |
| 1775 | application's code. The corresponding @var{value} is in the |
| 1776 | @w{@code{(@var{high} @var{low} @var{microsec} @var{picosec})}} format, the same |
| 1777 | format used by functions @code{current-time} (@pxref{Time of Day, |
| 1778 | current-time}) and @code{file-attributes} (@pxref{File Attributes}). |
| 1779 | |
| 1780 | @item stime |
| 1781 | Time spent by the process in the system (kernel) context, for |
| 1782 | processing system calls. The corresponding @var{value} is in the same |
| 1783 | format as for @code{utime}. |
| 1784 | |
| 1785 | @item time |
| 1786 | The sum of @code{utime} and @code{stime}. The corresponding |
| 1787 | @var{value} is in the same format as for @code{utime}. |
| 1788 | |
| 1789 | @item cutime |
| 1790 | @itemx cstime |
| 1791 | @itemx ctime |
| 1792 | Like @code{utime}, @code{stime}, and @code{time}, but include the |
| 1793 | times of all the child processes of the given process. |
| 1794 | |
| 1795 | @item pri |
| 1796 | The numerical priority of the process. |
| 1797 | |
| 1798 | @item nice |
| 1799 | The @dfn{nice value} of the process, a number. (Processes with smaller |
| 1800 | nice values get scheduled more favorably.) |
| 1801 | |
| 1802 | @item thcount |
| 1803 | The number of threads in the process. |
| 1804 | |
| 1805 | @item start |
| 1806 | The time when the process was started, in the same |
| 1807 | @w{@code{(@var{high} @var{low} @var{microsec} @var{picosec})}} format used by |
| 1808 | @code{current-time} and by @code{file-attributes}. |
| 1809 | |
| 1810 | @item etime |
| 1811 | The time elapsed since the process started, in the @w{@code{(@var{high} |
| 1812 | @var{low} @var{microsec} @var{picosec})}} format. |
| 1813 | |
| 1814 | @item vsize |
| 1815 | The virtual memory size of the process, measured in kilobytes. |
| 1816 | |
| 1817 | @item rss |
| 1818 | The size of the process's @dfn{resident set}, the number of kilobytes |
| 1819 | occupied by the process in the machine's physical memory. |
| 1820 | |
| 1821 | @item pcpu |
| 1822 | The percentage of the CPU time used by the process since it started. |
| 1823 | The corresponding @var{value} is a floating-point number between 0 and |
| 1824 | 100. |
| 1825 | |
| 1826 | @item pmem |
| 1827 | The percentage of the total physical memory installed on the machine |
| 1828 | used by the process's resident set. The value is a floating-point |
| 1829 | number between 0 and 100. |
| 1830 | |
| 1831 | @item args |
| 1832 | The command-line with which the process was invoked. This is a string |
| 1833 | in which individual command-line arguments are separated by blanks; |
| 1834 | whitespace characters that are embedded in the arguments are quoted as |
| 1835 | appropriate for the system's shell: escaped by backslash characters on |
| 1836 | GNU and Unix, and enclosed in double quote characters on Windows. |
| 1837 | Thus, this command-line string can be directly used in primitives such |
| 1838 | as @code{shell-command}. |
| 1839 | @end table |
| 1840 | |
| 1841 | @end defun |
| 1842 | |
| 1843 | |
| 1844 | @node Transaction Queues |
| 1845 | @section Transaction Queues |
| 1846 | @cindex transaction queue |
| 1847 | |
| 1848 | @c That's not very informative. What is a transaction, and when might |
| 1849 | @c I want to use one? |
| 1850 | You can use a @dfn{transaction queue} to communicate with a subprocess |
| 1851 | using transactions. First use @code{tq-create} to create a transaction |
| 1852 | queue communicating with a specified process. Then you can call |
| 1853 | @code{tq-enqueue} to send a transaction. |
| 1854 | |
| 1855 | @defun tq-create process |
| 1856 | This function creates and returns a transaction queue communicating with |
| 1857 | @var{process}. The argument @var{process} should be a subprocess |
| 1858 | capable of sending and receiving streams of bytes. It may be a child |
| 1859 | process, or it may be a TCP connection to a server, possibly on another |
| 1860 | machine. |
| 1861 | @end defun |
| 1862 | |
| 1863 | @defun tq-enqueue queue question regexp closure fn &optional delay-question |
| 1864 | This function sends a transaction to queue @var{queue}. Specifying the |
| 1865 | queue has the effect of specifying the subprocess to talk to. |
| 1866 | |
| 1867 | The argument @var{question} is the outgoing message that starts the |
| 1868 | transaction. The argument @var{fn} is the function to call when the |
| 1869 | corresponding answer comes back; it is called with two arguments: |
| 1870 | @var{closure}, and the answer received. |
| 1871 | |
| 1872 | The argument @var{regexp} is a regular expression that should match |
| 1873 | text at the end of the entire answer, but nothing before; that's how |
| 1874 | @code{tq-enqueue} determines where the answer ends. |
| 1875 | |
| 1876 | If the argument @var{delay-question} is non-@code{nil}, delay sending |
| 1877 | this question until the process has finished replying to any previous |
| 1878 | questions. This produces more reliable results with some processes. |
| 1879 | @ignore |
| 1880 | |
| 1881 | @c Let's not mention it then. |
| 1882 | The return value of @code{tq-enqueue} itself is not meaningful. |
| 1883 | @end ignore |
| 1884 | @end defun |
| 1885 | |
| 1886 | @defun tq-close queue |
| 1887 | Shut down transaction queue @var{queue}, waiting for all pending transactions |
| 1888 | to complete, and then terminate the connection or child process. |
| 1889 | @end defun |
| 1890 | |
| 1891 | Transaction queues are implemented by means of a filter function. |
| 1892 | @xref{Filter Functions}. |
| 1893 | |
| 1894 | @node Network |
| 1895 | @section Network Connections |
| 1896 | @cindex network connection |
| 1897 | @cindex TCP |
| 1898 | @cindex UDP |
| 1899 | |
| 1900 | Emacs Lisp programs can open stream (TCP) and datagram (UDP) network |
| 1901 | connections (@pxref{Datagrams}) to other processes on the same machine |
| 1902 | or other machines. |
| 1903 | A network connection is handled by Lisp much like a subprocess, and is |
| 1904 | represented by a process object. However, the process you are |
| 1905 | communicating with is not a child of the Emacs process, has no |
| 1906 | process @acronym{ID}, and you can't kill it or send it signals. All you |
| 1907 | can do is send and receive data. @code{delete-process} closes the |
| 1908 | connection, but does not kill the program at the other end; that |
| 1909 | program must decide what to do about closure of the connection. |
| 1910 | |
| 1911 | Lisp programs can listen for connections by creating network |
| 1912 | servers. A network server is also represented by a kind of process |
| 1913 | object, but unlike a network connection, the network server never |
| 1914 | transfers data itself. When it receives a connection request, it |
| 1915 | creates a new network connection to represent the connection just |
| 1916 | made. (The network connection inherits certain information, including |
| 1917 | the process plist, from the server.) The network server then goes |
| 1918 | back to listening for more connection requests. |
| 1919 | |
| 1920 | Network connections and servers are created by calling |
| 1921 | @code{make-network-process} with an argument list consisting of |
| 1922 | keyword/argument pairs, for example @code{:server t} to create a |
| 1923 | server process, or @code{:type 'datagram} to create a datagram |
| 1924 | connection. @xref{Low-Level Network}, for details. You can also use |
| 1925 | the @code{open-network-stream} function described below. |
| 1926 | |
| 1927 | To distinguish the different types of processes, the |
| 1928 | @code{process-type} function returns the symbol @code{network} for a |
| 1929 | network connection or server, @code{serial} for a serial port |
| 1930 | connection, or @code{real} for a real subprocess. |
| 1931 | |
| 1932 | The @code{process-status} function returns @code{open}, |
| 1933 | @code{closed}, @code{connect}, or @code{failed} for network |
| 1934 | connections. For a network server, the status is always |
| 1935 | @code{listen}. None of those values is possible for a real |
| 1936 | subprocess. @xref{Process Information}. |
| 1937 | |
| 1938 | You can stop and resume operation of a network process by calling |
| 1939 | @code{stop-process} and @code{continue-process}. For a server |
| 1940 | process, being stopped means not accepting new connections. (Up to 5 |
| 1941 | connection requests will be queued for when you resume the server; you |
| 1942 | can increase this limit, unless it is imposed by the operating |
| 1943 | system---see the @code{:server} keyword of @code{make-network-process}, |
| 1944 | @ref{Network Processes}.) For a network stream connection, being |
| 1945 | stopped means not processing input (any arriving input waits until you |
| 1946 | resume the connection). For a datagram connection, some number of |
| 1947 | packets may be queued but input may be lost. You can use the function |
| 1948 | @code{process-command} to determine whether a network connection or |
| 1949 | server is stopped; a non-@code{nil} value means yes. |
| 1950 | |
| 1951 | @cindex network connection, encrypted |
| 1952 | @cindex encrypted network connections |
| 1953 | @cindex @acronym{TLS} network connections |
| 1954 | @cindex @acronym{STARTTLS} network connections |
| 1955 | Emacs can create encrypted network connections, using either built-in |
| 1956 | or external support. The built-in support uses the GnuTLS |
| 1957 | (``Transport Layer Security'') library; see |
| 1958 | @uref{http://www.gnu.org/software/gnutls/, the GnuTLS project page}. |
| 1959 | If your Emacs was compiled with GnuTLS support, the function |
| 1960 | @code{gnutls-available-p} is defined and returns non-@code{nil}. For |
| 1961 | more details, @pxref{Top,, Overview, emacs-gnutls, The Emacs-GnuTLS manual}. |
| 1962 | The external support uses the @file{starttls.el} library, which |
| 1963 | requires a helper utility such as @command{gnutls-cli} to be installed |
| 1964 | on the system. The @code{open-network-stream} function can |
| 1965 | transparently handle the details of creating encrypted connections for |
| 1966 | you, using whatever support is available. |
| 1967 | |
| 1968 | @defun open-network-stream name buffer host service &rest parameters |
| 1969 | This function opens a TCP connection, with optional encryption, and |
| 1970 | returns a process object that represents the connection. |
| 1971 | |
| 1972 | The @var{name} argument specifies the name for the process object. It |
| 1973 | is modified as necessary to make it unique. |
| 1974 | |
| 1975 | The @var{buffer} argument is the buffer to associate with the |
| 1976 | connection. Output from the connection is inserted in the buffer, |
| 1977 | unless you specify a filter function to handle the output. If |
| 1978 | @var{buffer} is @code{nil}, it means that the connection is not |
| 1979 | associated with any buffer. |
| 1980 | |
| 1981 | The arguments @var{host} and @var{service} specify where to connect to; |
| 1982 | @var{host} is the host name (a string), and @var{service} is the name of |
| 1983 | a defined network service (a string) or a port number (an integer). |
| 1984 | |
| 1985 | The remaining arguments @var{parameters} are keyword/argument pairs |
| 1986 | that are mainly relevant to encrypted connections: |
| 1987 | |
| 1988 | @table @code |
| 1989 | |
| 1990 | @item :nowait @var{boolean} |
| 1991 | If non-@code{nil}, try to make an asynchronous connection. |
| 1992 | |
| 1993 | @item :type @var{type} |
| 1994 | The type of connection. Options are: |
| 1995 | |
| 1996 | @table @code |
| 1997 | @item plain |
| 1998 | An ordinary, unencrypted connection. |
| 1999 | @item tls |
| 2000 | @itemx ssl |
| 2001 | A @acronym{TLS} (``Transport Layer Security'') connection. |
| 2002 | @item nil |
| 2003 | @itemx network |
| 2004 | Start with a plain connection, and if parameters @samp{:success} |
| 2005 | and @samp{:capability-command} are supplied, try to upgrade to an encrypted |
| 2006 | connection via @acronym{STARTTLS}. If that fails, retain the |
| 2007 | unencrypted connection. |
| 2008 | @item starttls |
| 2009 | As for @code{nil}, but if @acronym{STARTTLS} fails drop the connection. |
| 2010 | @item shell |
| 2011 | A shell connection. |
| 2012 | @end table |
| 2013 | |
| 2014 | @item :always-query-capabilities @var{boolean} |
| 2015 | If non-@code{nil}, always ask for the server's capabilities, even when |
| 2016 | doing a @samp{plain} connection. |
| 2017 | |
| 2018 | @item :capability-command @var{capability-command} |
| 2019 | Command string to query the host capabilities. |
| 2020 | |
| 2021 | @item :end-of-command @var{regexp} |
| 2022 | @itemx :end-of-capability @var{regexp} |
| 2023 | Regular expression matching the end of a command, or the end of the |
| 2024 | command @var{capability-command}. The latter defaults to the former. |
| 2025 | |
| 2026 | @item :starttls-function @var{function} |
| 2027 | Function of one argument (the response to @var{capability-command}), |
| 2028 | which returns either @code{nil}, or the command to activate @acronym{STARTTLS} |
| 2029 | if supported. |
| 2030 | |
| 2031 | @item :success @var{regexp} |
| 2032 | Regular expression matching a successful @acronym{STARTTLS} negotiation. |
| 2033 | |
| 2034 | @item :use-starttls-if-possible @var{boolean} |
| 2035 | If non-@code{nil}, do opportunistic @acronym{STARTTLS} upgrades even if Emacs |
| 2036 | doesn't have built-in @acronym{TLS} support. |
| 2037 | |
| 2038 | @item :client-certificate @var{list-or-t} |
| 2039 | Either a list of the form @code{(@var{key-file} @var{cert-file})}, |
| 2040 | naming the certificate key file and certificate file itself, or |
| 2041 | @code{t}, meaning to query @code{auth-source} for this information |
| 2042 | (@pxref{Top,,Overview, auth, The Auth-Source Manual}). |
| 2043 | Only used for @acronym{TLS} or @acronym{STARTTLS}. |
| 2044 | |
| 2045 | @item :return-list @var{cons-or-nil} |
| 2046 | The return value of this function. If omitted or @code{nil}, return a |
| 2047 | process object. Otherwise, a cons of the form @code{(@var{process-object} |
| 2048 | . @var{plist})}, where @var{plist} has keywords: |
| 2049 | |
| 2050 | @table @code |
| 2051 | @item :greeting @var{string-or-nil} |
| 2052 | If non-@code{nil}, the greeting string returned by the host. |
| 2053 | @item :capabilities @var{string-or-nil} |
| 2054 | If non-@code{nil}, the host's capability string. |
| 2055 | @item :type @var{symbol} |
| 2056 | The connection type: @samp{plain} or @samp{tls}. |
| 2057 | @end table |
| 2058 | |
| 2059 | @end table |
| 2060 | |
| 2061 | @end defun |
| 2062 | |
| 2063 | @node Network Servers |
| 2064 | @section Network Servers |
| 2065 | @cindex network servers |
| 2066 | |
| 2067 | You create a server by calling @code{make-network-process} |
| 2068 | (@pxref{Network Processes}) with @code{:server t}. The server will |
| 2069 | listen for connection requests from clients. When it accepts a client |
| 2070 | connection request, that creates a new network connection, itself a |
| 2071 | process object, with the following parameters: |
| 2072 | |
| 2073 | @itemize @bullet |
| 2074 | @item |
| 2075 | The connection's process name is constructed by concatenating the |
| 2076 | server process's @var{name} with a client identification string. The |
| 2077 | @c FIXME? What about IPv6? Say briefly what the difference is? |
| 2078 | client identification string for an IPv4 connection looks like |
| 2079 | @samp{<@var{a}.@var{b}.@var{c}.@var{d}:@var{p}>}, which represents an |
| 2080 | address and port number. Otherwise, it is a |
| 2081 | unique number in brackets, as in @samp{<@var{nnn}>}. The number |
| 2082 | is unique for each connection in the Emacs session. |
| 2083 | |
| 2084 | @item |
| 2085 | If the server's filter is non-@code{nil}, the connection process does |
| 2086 | not get a separate process buffer; otherwise, Emacs creates a new |
| 2087 | buffer for the purpose. The buffer name is the server's buffer name |
| 2088 | or process name, concatenated with the client identification string. |
| 2089 | |
| 2090 | The server's process buffer value is never used directly, but the log |
| 2091 | function can retrieve it and use it to log connections by inserting |
| 2092 | text there. |
| 2093 | |
| 2094 | @item |
| 2095 | The communication type and the process filter and sentinel are |
| 2096 | inherited from those of the server. The server never directly |
| 2097 | uses its filter and sentinel; their sole purpose is to initialize |
| 2098 | connections made to the server. |
| 2099 | |
| 2100 | @item |
| 2101 | The connection's process contact information is set according to the client's |
| 2102 | addressing information (typically an IP address and a port number). |
| 2103 | This information is associated with the @code{process-contact} |
| 2104 | keywords @code{:host}, @code{:service}, @code{:remote}. |
| 2105 | |
| 2106 | @item |
| 2107 | The connection's local address is set up according to the port |
| 2108 | number used for the connection. |
| 2109 | |
| 2110 | @item |
| 2111 | The client process's plist is initialized from the server's plist. |
| 2112 | @end itemize |
| 2113 | |
| 2114 | @node Datagrams |
| 2115 | @section Datagrams |
| 2116 | @cindex datagrams |
| 2117 | |
| 2118 | A @dfn{datagram} connection communicates with individual packets rather |
| 2119 | than streams of data. Each call to @code{process-send} sends one |
| 2120 | datagram packet (@pxref{Input to Processes}), and each datagram |
| 2121 | received results in one call to the filter function. |
| 2122 | |
| 2123 | The datagram connection doesn't have to talk with the same remote |
| 2124 | peer all the time. It has a @dfn{remote peer address} which specifies |
| 2125 | where to send datagrams to. Each time an incoming datagram is passed |
| 2126 | to the filter function, the peer address is set to the address that |
| 2127 | datagram came from; that way, if the filter function sends a datagram, |
| 2128 | it will go back to that place. You can specify the remote peer |
| 2129 | address when you create the datagram connection using the |
| 2130 | @code{:remote} keyword. You can change it later on by calling |
| 2131 | @code{set-process-datagram-address}. |
| 2132 | |
| 2133 | @defun process-datagram-address process |
| 2134 | If @var{process} is a datagram connection or server, this function |
| 2135 | returns its remote peer address. |
| 2136 | @end defun |
| 2137 | |
| 2138 | @defun set-process-datagram-address process address |
| 2139 | If @var{process} is a datagram connection or server, this function |
| 2140 | sets its remote peer address to @var{address}. |
| 2141 | @end defun |
| 2142 | |
| 2143 | @node Low-Level Network |
| 2144 | @section Low-Level Network Access |
| 2145 | |
| 2146 | You can also create network connections by operating at a lower |
| 2147 | level than that of @code{open-network-stream}, using |
| 2148 | @code{make-network-process}. |
| 2149 | |
| 2150 | @menu |
| 2151 | * Proc: Network Processes. Using @code{make-network-process}. |
| 2152 | * Options: Network Options. Further control over network connections. |
| 2153 | * Features: Network Feature Testing. |
| 2154 | Determining which network features work on |
| 2155 | the machine you are using. |
| 2156 | @end menu |
| 2157 | |
| 2158 | @node Network Processes |
| 2159 | @subsection @code{make-network-process} |
| 2160 | |
| 2161 | The basic function for creating network connections and network |
| 2162 | servers is @code{make-network-process}. It can do either of those |
| 2163 | jobs, depending on the arguments you give it. |
| 2164 | |
| 2165 | @defun make-network-process &rest args |
| 2166 | This function creates a network connection or server and returns the |
| 2167 | process object that represents it. The arguments @var{args} are a |
| 2168 | list of keyword/argument pairs. Omitting a keyword is always |
| 2169 | equivalent to specifying it with value @code{nil}, except for |
| 2170 | @code{:coding}, @code{:filter-multibyte}, and @code{:reuseaddr}. Here |
| 2171 | are the meaningful keywords (those corresponding to network options |
| 2172 | are listed in the following section): |
| 2173 | |
| 2174 | @table @asis |
| 2175 | @item :name @var{name} |
| 2176 | Use the string @var{name} as the process name. It is modified if |
| 2177 | necessary to make it unique. |
| 2178 | |
| 2179 | @item :type @var{type} |
| 2180 | Specify the communication type. A value of @code{nil} specifies a |
| 2181 | stream connection (the default); @code{datagram} specifies a datagram |
| 2182 | connection; @code{seqpacket} specifies a ``sequenced packet stream'' |
| 2183 | connection. Both connections and servers can be of these types. |
| 2184 | |
| 2185 | @item :server @var{server-flag} |
| 2186 | If @var{server-flag} is non-@code{nil}, create a server. Otherwise, |
| 2187 | create a connection. For a stream type server, @var{server-flag} may |
| 2188 | be an integer, which then specifies the length of the queue of pending |
| 2189 | connections to the server. The default queue length is 5. |
| 2190 | |
| 2191 | @item :host @var{host} |
| 2192 | Specify the host to connect to. @var{host} should be a host name or |
| 2193 | Internet address, as a string, or the symbol @code{local} to specify |
| 2194 | the local host. If you specify @var{host} for a server, it must |
| 2195 | specify a valid address for the local host, and only clients |
| 2196 | connecting to that address will be accepted. |
| 2197 | |
| 2198 | @item :service @var{service} |
| 2199 | @var{service} specifies a port number to connect to; or, for a server, |
| 2200 | the port number to listen on. It should be a service name that |
| 2201 | translates to a port number, or an integer specifying the port number |
| 2202 | directly. For a server, it can also be @code{t}, which means to let |
| 2203 | the system select an unused port number. |
| 2204 | |
| 2205 | @item :family @var{family} |
| 2206 | @var{family} specifies the address (and protocol) family for |
| 2207 | communication. @code{nil} means determine the proper address family |
| 2208 | automatically for the given @var{host} and @var{service}. |
| 2209 | @code{local} specifies a Unix socket, in which case @var{host} is |
| 2210 | ignored. @code{ipv4} and @code{ipv6} specify to use IPv4 and IPv6, |
| 2211 | respectively. |
| 2212 | |
| 2213 | @item :local @var{local-address} |
| 2214 | For a server process, @var{local-address} is the address to listen on. |
| 2215 | It overrides @var{family}, @var{host} and @var{service}, so you |
| 2216 | might as well not specify them. |
| 2217 | |
| 2218 | @item :remote @var{remote-address} |
| 2219 | For a connection, @var{remote-address} is the address to connect to. |
| 2220 | It overrides @var{family}, @var{host} and @var{service}, so you |
| 2221 | might as well not specify them. |
| 2222 | |
| 2223 | For a datagram server, @var{remote-address} specifies the initial |
| 2224 | setting of the remote datagram address. |
| 2225 | |
| 2226 | The format of @var{local-address} or @var{remote-address} depends on |
| 2227 | the address family: |
| 2228 | |
| 2229 | @itemize - |
| 2230 | @item |
| 2231 | An IPv4 address is represented as a five-element vector of four 8-bit |
| 2232 | integers and one 16-bit integer |
| 2233 | @code{[@var{a} @var{b} @var{c} @var{d} @var{p}]} corresponding to |
| 2234 | numeric IPv4 address @var{a}.@var{b}.@var{c}.@var{d} and port number |
| 2235 | @var{p}. |
| 2236 | |
| 2237 | @item |
| 2238 | An IPv6 address is represented as a nine-element vector of 16-bit |
| 2239 | integers @code{[@var{a} @var{b} @var{c} @var{d} @var{e} @var{f} |
| 2240 | @var{g} @var{h} @var{p}]} corresponding to numeric IPv6 address |
| 2241 | @var{a}:@var{b}:@var{c}:@var{d}:@var{e}:@var{f}:@var{g}:@var{h} and |
| 2242 | port number @var{p}. |
| 2243 | |
| 2244 | @item |
| 2245 | A local address is represented as a string, which specifies the address |
| 2246 | in the local address space. |
| 2247 | |
| 2248 | @item |
| 2249 | An ``unsupported family'' address is represented by a cons |
| 2250 | @code{(@var{f} . @var{av})}, where @var{f} is the family number and |
| 2251 | @var{av} is a vector specifying the socket address using one element |
| 2252 | per address data byte. Do not rely on this format in portable code, |
| 2253 | as it may depend on implementation defined constants, data sizes, and |
| 2254 | data structure alignment. |
| 2255 | @end itemize |
| 2256 | |
| 2257 | @item :nowait @var{bool} |
| 2258 | If @var{bool} is non-@code{nil} for a stream connection, return |
| 2259 | without waiting for the connection to complete. When the connection |
| 2260 | succeeds or fails, Emacs will call the sentinel function, with a |
| 2261 | second argument matching @code{"open"} (if successful) or |
| 2262 | @code{"failed"}. The default is to block, so that |
| 2263 | @code{make-network-process} does not return until the connection |
| 2264 | has succeeded or failed. |
| 2265 | |
| 2266 | @item :stop @var{stopped} |
| 2267 | If @var{stopped} is non-@code{nil}, start the network connection or |
| 2268 | server in the ``stopped'' state. |
| 2269 | |
| 2270 | @item :buffer @var{buffer} |
| 2271 | Use @var{buffer} as the process buffer. |
| 2272 | |
| 2273 | @item :coding @var{coding} |
| 2274 | Use @var{coding} as the coding system for this process. To specify |
| 2275 | different coding systems for decoding data from the connection and for |
| 2276 | encoding data sent to it, specify @code{(@var{decoding} . |
| 2277 | @var{encoding})} for @var{coding}. |
| 2278 | |
| 2279 | If you don't specify this keyword at all, the default |
| 2280 | is to determine the coding systems from the data. |
| 2281 | |
| 2282 | @item :noquery @var{query-flag} |
| 2283 | Initialize the process query flag to @var{query-flag}. |
| 2284 | @xref{Query Before Exit}. |
| 2285 | |
| 2286 | @item :filter @var{filter} |
| 2287 | Initialize the process filter to @var{filter}. |
| 2288 | |
| 2289 | @item :filter-multibyte @var{multibyte} |
| 2290 | If @var{multibyte} is non-@code{nil}, strings given to the process |
| 2291 | filter are multibyte, otherwise they are unibyte. The default is the |
| 2292 | default value of @code{enable-multibyte-characters}. |
| 2293 | |
| 2294 | @item :sentinel @var{sentinel} |
| 2295 | Initialize the process sentinel to @var{sentinel}. |
| 2296 | |
| 2297 | @item :log @var{log} |
| 2298 | Initialize the log function of a server process to @var{log}. The log |
| 2299 | function is called each time the server accepts a network connection |
| 2300 | from a client. The arguments passed to the log function are |
| 2301 | @var{server}, @var{connection}, and @var{message}; where @var{server} |
| 2302 | is the server process, @var{connection} is the new process for the |
| 2303 | connection, and @var{message} is a string describing what has |
| 2304 | happened. |
| 2305 | |
| 2306 | @item :plist @var{plist} |
| 2307 | Initialize the process plist to @var{plist}. |
| 2308 | @end table |
| 2309 | |
| 2310 | The original argument list, modified with the actual connection |
| 2311 | information, is available via the @code{process-contact} function. |
| 2312 | @end defun |
| 2313 | |
| 2314 | @node Network Options |
| 2315 | @subsection Network Options |
| 2316 | |
| 2317 | The following network options can be specified when you create a |
| 2318 | network process. Except for @code{:reuseaddr}, you can also set or |
| 2319 | modify these options later, using @code{set-network-process-option}. |
| 2320 | |
| 2321 | For a server process, the options specified with |
| 2322 | @code{make-network-process} are not inherited by the client |
| 2323 | connections, so you will need to set the necessary options for each |
| 2324 | child connection as it is created. |
| 2325 | |
| 2326 | @table @asis |
| 2327 | @item :bindtodevice @var{device-name} |
| 2328 | If @var{device-name} is a non-empty string identifying a network |
| 2329 | interface name (see @code{network-interface-list}), only handle |
| 2330 | packets received on that interface. If @var{device-name} is @code{nil} |
| 2331 | (the default), handle packets received on any interface. |
| 2332 | |
| 2333 | Using this option may require special privileges on some systems. |
| 2334 | |
| 2335 | @item :broadcast @var{broadcast-flag} |
| 2336 | If @var{broadcast-flag} is non-@code{nil} for a datagram process, the |
| 2337 | process will receive datagram packet sent to a broadcast address, and |
| 2338 | be able to send packets to a broadcast address. This is ignored for a stream |
| 2339 | connection. |
| 2340 | |
| 2341 | @item :dontroute @var{dontroute-flag} |
| 2342 | If @var{dontroute-flag} is non-@code{nil}, the process can only send |
| 2343 | to hosts on the same network as the local host. |
| 2344 | |
| 2345 | @item :keepalive @var{keepalive-flag} |
| 2346 | If @var{keepalive-flag} is non-@code{nil} for a stream connection, |
| 2347 | enable exchange of low-level keep-alive messages. |
| 2348 | |
| 2349 | @item :linger @var{linger-arg} |
| 2350 | If @var{linger-arg} is non-@code{nil}, wait for successful |
| 2351 | transmission of all queued packets on the connection before it is |
| 2352 | deleted (see @code{delete-process}). If @var{linger-arg} is an |
| 2353 | integer, it specifies the maximum time in seconds to wait for queued |
| 2354 | packets to be sent before closing the connection. The default is |
| 2355 | @code{nil}, which means to discard unsent queued packets when the |
| 2356 | process is deleted. |
| 2357 | |
| 2358 | @c FIXME Where out-of-band data is ...? |
| 2359 | @item :oobinline @var{oobinline-flag} |
| 2360 | If @var{oobinline-flag} is non-@code{nil} for a stream connection, |
| 2361 | receive out-of-band data in the normal data stream. Otherwise, ignore |
| 2362 | out-of-band data. |
| 2363 | |
| 2364 | @item :priority @var{priority} |
| 2365 | Set the priority for packets sent on this connection to the integer |
| 2366 | @var{priority}. The interpretation of this number is protocol |
| 2367 | specific; such as setting the TOS (type of service) field on IP |
| 2368 | packets sent on this connection. It may also have system dependent |
| 2369 | effects, such as selecting a specific output queue on the network |
| 2370 | interface. |
| 2371 | |
| 2372 | @item :reuseaddr @var{reuseaddr-flag} |
| 2373 | If @var{reuseaddr-flag} is non-@code{nil} (the default) for a stream |
| 2374 | server process, allow this server to reuse a specific port number (see |
| 2375 | @code{:service}), unless another process on this host is already |
| 2376 | listening on that port. If @var{reuseaddr-flag} is @code{nil}, there |
| 2377 | may be a period of time after the last use of that port (by any |
| 2378 | process on the host) where it is not possible to make a new server on |
| 2379 | that port. |
| 2380 | @end table |
| 2381 | |
| 2382 | @defun set-network-process-option process option value &optional no-error |
| 2383 | This function sets or modifies a network option for network process |
| 2384 | @var{process}. The accepted options and values are as for |
| 2385 | @code{make-network-process}. If @var{no-error} is non-@code{nil}, |
| 2386 | this function returns @code{nil} instead of signaling an error if |
| 2387 | @var{option} is not a supported option. If the function successfully |
| 2388 | completes, it returns @code{t}. |
| 2389 | |
| 2390 | The current setting of an option is available via the |
| 2391 | @code{process-contact} function. |
| 2392 | @end defun |
| 2393 | |
| 2394 | @node Network Feature Testing |
| 2395 | @subsection Testing Availability of Network Features |
| 2396 | |
| 2397 | To test for the availability of a given network feature, use |
| 2398 | @code{featurep} like this: |
| 2399 | |
| 2400 | @example |
| 2401 | (featurep 'make-network-process '(@var{keyword} @var{value})) |
| 2402 | @end example |
| 2403 | |
| 2404 | @noindent |
| 2405 | The result of this form is @code{t} if it works to specify |
| 2406 | @var{keyword} with value @var{value} in @code{make-network-process}. |
| 2407 | Here are some of the @var{keyword}---@var{value} pairs you can test in |
| 2408 | this way. |
| 2409 | |
| 2410 | @table @code |
| 2411 | @item (:nowait t) |
| 2412 | Non-@code{nil} if non-blocking connect is supported. |
| 2413 | @item (:type datagram) |
| 2414 | Non-@code{nil} if datagrams are supported. |
| 2415 | @item (:family local) |
| 2416 | Non-@code{nil} if local (a.k.a.@: ``UNIX domain'') sockets are supported. |
| 2417 | @item (:family ipv6) |
| 2418 | Non-@code{nil} if IPv6 is supported. |
| 2419 | @item (:service t) |
| 2420 | Non-@code{nil} if the system can select the port for a server. |
| 2421 | @end table |
| 2422 | |
| 2423 | To test for the availability of a given network option, use |
| 2424 | @code{featurep} like this: |
| 2425 | |
| 2426 | @example |
| 2427 | (featurep 'make-network-process '@var{keyword}) |
| 2428 | @end example |
| 2429 | |
| 2430 | @noindent |
| 2431 | The accepted @var{keyword} values are @code{:bindtodevice}, etc. |
| 2432 | For the complete list, @pxref{Network Options}. This form returns |
| 2433 | non-@code{nil} if that particular network option is supported by |
| 2434 | @code{make-network-process} (or @code{set-network-process-option}). |
| 2435 | |
| 2436 | @node Misc Network |
| 2437 | @section Misc Network Facilities |
| 2438 | |
| 2439 | These additional functions are useful for creating and operating |
| 2440 | on network connections. Note that they are supported only on some |
| 2441 | systems. |
| 2442 | |
| 2443 | @defun network-interface-list |
| 2444 | This function returns a list describing the network interfaces |
| 2445 | of the machine you are using. The value is an alist whose |
| 2446 | elements have the form @code{(@var{name} . @var{address})}. |
| 2447 | @var{address} has the same form as the @var{local-address} |
| 2448 | and @var{remote-address} arguments to @code{make-network-process}. |
| 2449 | @end defun |
| 2450 | |
| 2451 | @defun network-interface-info ifname |
| 2452 | This function returns information about the network interface named |
| 2453 | @var{ifname}. The value is a list of the form |
| 2454 | @code{(@var{addr} @var{bcast} @var{netmask} @var{hwaddr} @var{flags})}. |
| 2455 | |
| 2456 | @table @var |
| 2457 | @item addr |
| 2458 | The Internet protocol address. |
| 2459 | @item bcast |
| 2460 | The broadcast address. |
| 2461 | @item netmask |
| 2462 | The network mask. |
| 2463 | @item hwaddr |
| 2464 | The layer 2 address (Ethernet MAC address, for instance). |
| 2465 | @item flags |
| 2466 | The current flags of the interface. |
| 2467 | @end table |
| 2468 | @end defun |
| 2469 | |
| 2470 | @defun format-network-address address &optional omit-port |
| 2471 | This function converts the Lisp representation of a network address to |
| 2472 | a string. |
| 2473 | |
| 2474 | A five-element vector @code{[@var{a} @var{b} @var{c} @var{d} @var{p}]} |
| 2475 | represents an IPv4 address @var{a}.@var{b}.@var{c}.@var{d} and port |
| 2476 | number @var{p}. @code{format-network-address} converts that to the |
| 2477 | string @code{"@var{a}.@var{b}.@var{c}.@var{d}:@var{p}"}. |
| 2478 | |
| 2479 | A nine-element vector @code{[@var{a} @var{b} @var{c} @var{d} @var{e} |
| 2480 | @var{f} @var{g} @var{h} @var{p}]} represents an IPv6 address along |
| 2481 | with a port number. @code{format-network-address} converts that to |
| 2482 | the string |
| 2483 | @code{"[@var{a}:@var{b}:@var{c}:@var{d}:@var{e}:@var{f}:@var{g}:@var{h}]:@var{p}"}. |
| 2484 | |
| 2485 | If the vector does not include the port number, @var{p}, or if |
| 2486 | @var{omit-port} is non-@code{nil}, the result does not include the |
| 2487 | @code{:@var{p}} suffix. |
| 2488 | @end defun |
| 2489 | |
| 2490 | @node Serial Ports |
| 2491 | @section Communicating with Serial Ports |
| 2492 | @cindex @file{/dev/tty} |
| 2493 | @cindex @file{COM1} |
| 2494 | @cindex serial connections |
| 2495 | |
| 2496 | Emacs can communicate with serial ports. For interactive use, |
| 2497 | @kbd{M-x serial-term} opens a terminal window. In a Lisp program, |
| 2498 | @code{make-serial-process} creates a process object. |
| 2499 | |
| 2500 | The serial port can be configured at run-time, without having to |
| 2501 | close and re-open it. The function @code{serial-process-configure} |
| 2502 | lets you change the speed, bytesize, and other parameters. In a |
| 2503 | terminal window created by @code{serial-term}, you can click on the |
| 2504 | mode line for configuration. |
| 2505 | |
| 2506 | A serial connection is represented by a process object, which can be |
| 2507 | used in a similar way to a subprocess or network process. You can send and |
| 2508 | receive data, and configure the serial port. A serial process object |
| 2509 | has no process ID, however, and you can't send signals to it, and the |
| 2510 | status codes are different from other types of processes. |
| 2511 | @code{delete-process} on the process object or @code{kill-buffer} on |
| 2512 | the process buffer close the connection, but this does not affect the |
| 2513 | device connected to the serial port. |
| 2514 | |
| 2515 | The function @code{process-type} returns the symbol @code{serial} |
| 2516 | for a process object representing a serial port connection. |
| 2517 | |
| 2518 | Serial ports are available on GNU/Linux, Unix, and MS Windows systems. |
| 2519 | |
| 2520 | @deffn Command serial-term port speed |
| 2521 | Start a terminal-emulator for a serial port in a new buffer. |
| 2522 | @var{port} is the name of the serial port to connect to. For |
| 2523 | example, this could be @file{/dev/ttyS0} on Unix. On MS Windows, this |
| 2524 | could be @file{COM1}, or @file{\\.\COM10} (double the backslashes in |
| 2525 | Lisp strings). |
| 2526 | |
| 2527 | @c FIXME is 9600 still the most common value, or is it 115200 now? |
| 2528 | @c (Same value, 9600, appears below as well.) |
| 2529 | @var{speed} is the speed of the serial port in bits per second. 9600 |
| 2530 | is a common value. The buffer is in Term mode; see @ref{Term Mode,,, |
| 2531 | emacs, The GNU Emacs Manual}, for the commands to use in that buffer. |
| 2532 | You can change the speed and the configuration in the mode line menu. |
| 2533 | @end deffn |
| 2534 | |
| 2535 | @defun make-serial-process &rest args |
| 2536 | This function creates a process and a buffer. Arguments are specified |
| 2537 | as keyword/argument pairs. Here's the list of the meaningful |
| 2538 | keywords, with the first two (@var{port} and @var{speed}) being mandatory: |
| 2539 | |
| 2540 | @table @code |
| 2541 | @item :port @var{port} |
| 2542 | This is the name of the serial port. On Unix and GNU systems, this is |
| 2543 | a file name such as @file{/dev/ttyS0}. On Windows, this could be |
| 2544 | @file{COM1}, or @file{\\.\COM10} for ports higher than @file{COM9} |
| 2545 | (double the backslashes in Lisp strings). |
| 2546 | |
| 2547 | @item :speed @var{speed} |
| 2548 | The speed of the serial port in bits per second. This function calls |
| 2549 | @code{serial-process-configure} to handle the speed; see the |
| 2550 | following documentation of that function for more details. |
| 2551 | |
| 2552 | @item :name @var{name} |
| 2553 | The name of the process. If @var{name} is not given, @var{port} will |
| 2554 | serve as the process name as well. |
| 2555 | |
| 2556 | @item :buffer @var{buffer} |
| 2557 | The buffer to associate with the process. The value can be either a |
| 2558 | buffer or a string that names a buffer. Process output goes at the |
| 2559 | end of that buffer, unless you specify an output stream or filter |
| 2560 | function to handle the output. If @var{buffer} is not given, the |
| 2561 | process buffer's name is taken from the value of the @code{:name} |
| 2562 | keyword. |
| 2563 | |
| 2564 | @item :coding @var{coding} |
| 2565 | If @var{coding} is a symbol, it specifies the coding system used for |
| 2566 | both reading and writing for this process. If @var{coding} is a cons |
| 2567 | @code{(@var{decoding} . @var{encoding})}, @var{decoding} is used for |
| 2568 | reading, and @var{encoding} is used for writing. If not specified, |
| 2569 | the default is to determine the coding systems from the data itself. |
| 2570 | |
| 2571 | @item :noquery @var{query-flag} |
| 2572 | Initialize the process query flag to @var{query-flag}. @xref{Query |
| 2573 | Before Exit}. The flags defaults to @code{nil} if unspecified. |
| 2574 | |
| 2575 | @item :stop @var{bool} |
| 2576 | Start process in the ``stopped'' state if @var{bool} is |
| 2577 | non-@code{nil}. In the stopped state, a serial process does not |
| 2578 | accept incoming data, but you can send outgoing data. The stopped |
| 2579 | state is cleared by @code{continue-process} and set by |
| 2580 | @code{stop-process}. |
| 2581 | |
| 2582 | @item :filter @var{filter} |
| 2583 | Install @var{filter} as the process filter. |
| 2584 | |
| 2585 | @item :sentinel @var{sentinel} |
| 2586 | Install @var{sentinel} as the process sentinel. |
| 2587 | |
| 2588 | @item :plist @var{plist} |
| 2589 | Install @var{plist} as the initial plist of the process. |
| 2590 | |
| 2591 | @item :bytesize |
| 2592 | @itemx :parity |
| 2593 | @itemx :stopbits |
| 2594 | @itemx :flowcontrol |
| 2595 | These are handled by @code{serial-process-configure}, which is called |
| 2596 | by @code{make-serial-process}. |
| 2597 | @end table |
| 2598 | |
| 2599 | The original argument list, possibly modified by later configuration, |
| 2600 | is available via the function @code{process-contact}. |
| 2601 | |
| 2602 | Here is an example: |
| 2603 | |
| 2604 | @example |
| 2605 | (make-serial-process :port "/dev/ttyS0" :speed 9600) |
| 2606 | @end example |
| 2607 | @end defun |
| 2608 | |
| 2609 | @defun serial-process-configure &rest args |
| 2610 | @cindex baud, in serial connections |
| 2611 | @cindex bytesize, in serial connections |
| 2612 | @cindex parity, in serial connections |
| 2613 | @cindex stopbits, in serial connections |
| 2614 | @cindex flowcontrol, in serial connections |
| 2615 | |
| 2616 | This functions configures a serial port connection. Arguments are |
| 2617 | specified as keyword/argument pairs. Attributes that are not given |
| 2618 | are re-initialized from the process's current configuration (available |
| 2619 | via the function @code{process-contact}), or set to reasonable default |
| 2620 | values. The following arguments are defined: |
| 2621 | |
| 2622 | @table @code |
| 2623 | @item :process @var{process} |
| 2624 | @itemx :name @var{name} |
| 2625 | @itemx :buffer @var{buffer} |
| 2626 | @itemx :port @var{port} |
| 2627 | Any of these arguments can be given to identify the process that is to |
| 2628 | be configured. If none of these arguments is given, the current |
| 2629 | buffer's process is used. |
| 2630 | |
| 2631 | @item :speed @var{speed} |
| 2632 | The speed of the serial port in bits per second, a.k.a.@: @dfn{baud |
| 2633 | rate}. The value can be any number, but most serial ports work only |
| 2634 | at a few defined values between 1200 and 115200, with 9600 being the |
| 2635 | most common value. If @var{speed} is @code{nil}, the function ignores |
| 2636 | all other arguments and does not configure the port. This may be |
| 2637 | useful for special serial ports such as Bluetooth-to-serial converters, |
| 2638 | which can only be configured through @samp{AT} commands sent through the |
| 2639 | connection. The value of @code{nil} for @var{speed} is valid only for |
| 2640 | connections that were already opened by a previous call to |
| 2641 | @code{make-serial-process} or @code{serial-term}. |
| 2642 | |
| 2643 | @item :bytesize @var{bytesize} |
| 2644 | The number of bits per byte, which can be 7 or 8. If @var{bytesize} |
| 2645 | is not given or @code{nil}, it defaults to 8. |
| 2646 | |
| 2647 | @item :parity @var{parity} |
| 2648 | The value can be @code{nil} (don't use parity), the symbol |
| 2649 | @code{odd} (use odd parity), or the symbol @code{even} (use even |
| 2650 | parity). If @var{parity} is not given, it defaults to no parity. |
| 2651 | |
| 2652 | @item :stopbits @var{stopbits} |
| 2653 | The number of stopbits used to terminate a transmission |
| 2654 | of each byte. @var{stopbits} can be 1 or 2. If @var{stopbits} is not |
| 2655 | given or @code{nil}, it defaults to 1. |
| 2656 | |
| 2657 | @item :flowcontrol @var{flowcontrol} |
| 2658 | The type of flow control to use for this connection, which is either |
| 2659 | @code{nil} (don't use flow control), the symbol @code{hw} (use RTS/CTS |
| 2660 | hardware flow control), or the symbol @code{sw} (use XON/XOFF software |
| 2661 | flow control). If @var{flowcontrol} is not given, it defaults to no |
| 2662 | flow control. |
| 2663 | @end table |
| 2664 | |
| 2665 | Internally, @code{make-serial-process} calls |
| 2666 | @code{serial-process-configure} for the initial configuration of the |
| 2667 | serial port. |
| 2668 | @end defun |
| 2669 | |
| 2670 | @node Byte Packing |
| 2671 | @section Packing and Unpacking Byte Arrays |
| 2672 | @cindex byte packing and unpacking |
| 2673 | |
| 2674 | This section describes how to pack and unpack arrays of bytes, |
| 2675 | usually for binary network protocols. These functions convert byte arrays |
| 2676 | to alists, and vice versa. The byte array can be represented as a |
| 2677 | @c FIXME? No multibyte? |
| 2678 | unibyte string or as a vector of integers, while the alist associates |
| 2679 | symbols either with fixed-size objects or with recursive sub-alists. |
| 2680 | To use the functions referred to in this section, load the |
| 2681 | @code{bindat} library. |
| 2682 | @c It doesn't have any autoloads. |
| 2683 | |
| 2684 | @cindex serializing |
| 2685 | @cindex deserializing |
| 2686 | @cindex packing |
| 2687 | @cindex unpacking |
| 2688 | Conversion from byte arrays to nested alists is also known as |
| 2689 | @dfn{deserializing} or @dfn{unpacking}, while going in the opposite |
| 2690 | direction is also known as @dfn{serializing} or @dfn{packing}. |
| 2691 | |
| 2692 | @menu |
| 2693 | * Bindat Spec:: Describing data layout. |
| 2694 | * Bindat Functions:: Doing the unpacking and packing. |
| 2695 | * Bindat Examples:: Samples of what bindat.el can do for you! |
| 2696 | @end menu |
| 2697 | |
| 2698 | @node Bindat Spec |
| 2699 | @subsection Describing Data Layout |
| 2700 | |
| 2701 | To control unpacking and packing, you write a @dfn{data layout |
| 2702 | specification}, a special nested list describing named and typed |
| 2703 | @dfn{fields}. This specification controls the length of each field to be |
| 2704 | processed, and how to pack or unpack it. We normally keep bindat specs |
| 2705 | in variables whose names end in @samp{-bindat-spec}; that kind of name |
| 2706 | is automatically recognized as ``risky''. |
| 2707 | |
| 2708 | @cindex endianness |
| 2709 | @cindex big endian |
| 2710 | @cindex little endian |
| 2711 | @cindex network byte ordering |
| 2712 | A field's @dfn{type} describes the size (in bytes) of the object |
| 2713 | that the field represents and, in the case of multibyte fields, how |
| 2714 | the bytes are ordered within the field. The two possible orderings |
| 2715 | are ``big endian'' (also known as ``network byte ordering'') and |
| 2716 | ``little endian''. For instance, the number @code{#x23cd} (decimal |
| 2717 | 9165) in big endian would be the two bytes @code{#x23} @code{#xcd}; |
| 2718 | and in little endian, @code{#xcd} @code{#x23}. Here are the possible |
| 2719 | type values: |
| 2720 | |
| 2721 | @table @code |
| 2722 | @item u8 |
| 2723 | @itemx byte |
| 2724 | Unsigned byte, with length 1. |
| 2725 | |
| 2726 | @item u16 |
| 2727 | @itemx word |
| 2728 | @itemx short |
| 2729 | Unsigned integer in network byte order, with length 2. |
| 2730 | |
| 2731 | @item u24 |
| 2732 | Unsigned integer in network byte order, with length 3. |
| 2733 | |
| 2734 | @item u32 |
| 2735 | @itemx dword |
| 2736 | @itemx long |
| 2737 | Unsigned integer in network byte order, with length 4. |
| 2738 | Note: These values may be limited by Emacs's integer implementation limits. |
| 2739 | |
| 2740 | @item u16r |
| 2741 | @itemx u24r |
| 2742 | @itemx u32r |
| 2743 | Unsigned integer in little endian order, with length 2, 3 and 4, respectively. |
| 2744 | |
| 2745 | @item str @var{len} |
| 2746 | String of length @var{len}. |
| 2747 | |
| 2748 | @item strz @var{len} |
| 2749 | Zero-terminated string, in a fixed-size field with length @var{len}. |
| 2750 | |
| 2751 | @item vec @var{len} [@var{type}] |
| 2752 | Vector of @var{len} elements of type @var{type}, defaulting to bytes. |
| 2753 | The @var{type} is any of the simple types above, or another vector |
| 2754 | specified as a list of the form @code{(vec @var{len} [@var{type}])}. |
| 2755 | |
| 2756 | @item ip |
| 2757 | @c FIXME? IPv6? |
| 2758 | Four-byte vector representing an Internet address. For example: |
| 2759 | @code{[127 0 0 1]} for localhost. |
| 2760 | |
| 2761 | @item bits @var{len} |
| 2762 | List of set bits in @var{len} bytes. The bytes are taken in big |
| 2763 | endian order and the bits are numbered starting with @code{8 * |
| 2764 | @var{len} @minus{} 1} and ending with zero. For example: @code{bits |
| 2765 | 2} unpacks @code{#x28} @code{#x1c} to @code{(2 3 4 11 13)} and |
| 2766 | @code{#x1c} @code{#x28} to @code{(3 5 10 11 12)}. |
| 2767 | |
| 2768 | @item (eval @var{form}) |
| 2769 | @var{form} is a Lisp expression evaluated at the moment the field is |
| 2770 | unpacked or packed. The result of the evaluation should be one of the |
| 2771 | above-listed type specifications. |
| 2772 | @end table |
| 2773 | |
| 2774 | For a fixed-size field, the length @var{len} is given as an integer |
| 2775 | specifying the number of bytes in the field. |
| 2776 | |
| 2777 | When the length of a field is not fixed, it typically depends on the |
| 2778 | value of a preceding field. In this case, the length @var{len} can be |
| 2779 | given either as a list @code{(@var{name} ...)} identifying a |
| 2780 | @dfn{field name} in the format specified for @code{bindat-get-field} |
| 2781 | below, or by an expression @code{(eval @var{form})} where @var{form} |
| 2782 | should evaluate to an integer, specifying the field length. |
| 2783 | |
| 2784 | A field specification generally has the form @code{([@var{name}] |
| 2785 | @var{handler})}, where @var{name} is optional. Don't use names that |
| 2786 | are symbols meaningful as type specifications (above) or handler |
| 2787 | specifications (below), since that would be ambiguous. @var{name} can |
| 2788 | be a symbol or an expression @code{(eval @var{form})}, in which case |
| 2789 | @var{form} should evaluate to a symbol. |
| 2790 | |
| 2791 | @var{handler} describes how to unpack or pack the field and can be one |
| 2792 | of the following: |
| 2793 | |
| 2794 | @table @code |
| 2795 | @item @var{type} |
| 2796 | Unpack/pack this field according to the type specification @var{type}. |
| 2797 | |
| 2798 | @item eval @var{form} |
| 2799 | Evaluate @var{form}, a Lisp expression, for side-effect only. If the |
| 2800 | field name is specified, the value is bound to that field name. |
| 2801 | |
| 2802 | @item fill @var{len} |
| 2803 | Skip @var{len} bytes. In packing, this leaves them unchanged, |
| 2804 | which normally means they remain zero. In unpacking, this means |
| 2805 | they are ignored. |
| 2806 | |
| 2807 | @item align @var{len} |
| 2808 | Skip to the next multiple of @var{len} bytes. |
| 2809 | |
| 2810 | @item struct @var{spec-name} |
| 2811 | Process @var{spec-name} as a sub-specification. This describes a |
| 2812 | structure nested within another structure. |
| 2813 | |
| 2814 | @item union @var{form} (@var{tag} @var{spec})@dots{} |
| 2815 | @c ??? I don't see how one would actually use this. |
| 2816 | @c ??? what kind of expression would be useful for @var{form}? |
| 2817 | Evaluate @var{form}, a Lisp expression, find the first @var{tag} |
| 2818 | that matches it, and process its associated data layout specification |
| 2819 | @var{spec}. Matching can occur in one of three ways: |
| 2820 | |
| 2821 | @itemize |
| 2822 | @item |
| 2823 | If a @var{tag} has the form @code{(eval @var{expr})}, evaluate |
| 2824 | @var{expr} with the variable @code{tag} dynamically bound to the value |
| 2825 | of @var{form}. A non-@code{nil} result indicates a match. |
| 2826 | |
| 2827 | @item |
| 2828 | @var{tag} matches if it is @code{equal} to the value of @var{form}. |
| 2829 | |
| 2830 | @item |
| 2831 | @var{tag} matches unconditionally if it is @code{t}. |
| 2832 | @end itemize |
| 2833 | |
| 2834 | @item repeat @var{count} @var{field-specs}@dots{} |
| 2835 | Process the @var{field-specs} recursively, in order, then repeat |
| 2836 | starting from the first one, processing all the specifications @var{count} |
| 2837 | times overall. The @var{count} is given using the same formats as a |
| 2838 | field length---if an @code{eval} form is used, it is evaluated just once. |
| 2839 | For correct operation, each specification in @var{field-specs} must |
| 2840 | include a name. |
| 2841 | @end table |
| 2842 | |
| 2843 | For the @code{(eval @var{form})} forms used in a bindat specification, |
| 2844 | the @var{form} can access and update these dynamically bound variables |
| 2845 | during evaluation: |
| 2846 | |
| 2847 | @table @code |
| 2848 | @item last |
| 2849 | Value of the last field processed. |
| 2850 | |
| 2851 | @item bindat-raw |
| 2852 | The data as a byte array. |
| 2853 | |
| 2854 | @item bindat-idx |
| 2855 | Current index (within @code{bindat-raw}) for unpacking or packing. |
| 2856 | |
| 2857 | @item struct |
| 2858 | The alist containing the structured data that have been unpacked so |
| 2859 | far, or the entire structure being packed. You can use |
| 2860 | @code{bindat-get-field} to access specific fields of this structure. |
| 2861 | |
| 2862 | @item count |
| 2863 | @itemx index |
| 2864 | Inside a @code{repeat} block, these contain the maximum number of |
| 2865 | repetitions (as specified by the @var{count} parameter), and the |
| 2866 | current repetition number (counting from 0). Setting @code{count} to |
| 2867 | zero will terminate the inner-most repeat block after the current |
| 2868 | repetition has completed. |
| 2869 | @end table |
| 2870 | |
| 2871 | @node Bindat Functions |
| 2872 | @subsection Functions to Unpack and Pack Bytes |
| 2873 | |
| 2874 | In the following documentation, @var{spec} refers to a data layout |
| 2875 | specification, @code{bindat-raw} to a byte array, and @var{struct} to an |
| 2876 | alist representing unpacked field data. |
| 2877 | |
| 2878 | @defun bindat-unpack spec bindat-raw &optional bindat-idx |
| 2879 | @c FIXME? Again, no multibyte? |
| 2880 | This function unpacks data from the unibyte string or byte |
| 2881 | array @code{bindat-raw} |
| 2882 | according to @var{spec}. Normally, this starts unpacking at the |
| 2883 | beginning of the byte array, but if @var{bindat-idx} is non-@code{nil}, it |
| 2884 | specifies a zero-based starting position to use instead. |
| 2885 | |
| 2886 | The value is an alist or nested alist in which each element describes |
| 2887 | one unpacked field. |
| 2888 | @end defun |
| 2889 | |
| 2890 | @defun bindat-get-field struct &rest name |
| 2891 | This function selects a field's data from the nested alist |
| 2892 | @var{struct}. Usually @var{struct} was returned by |
| 2893 | @code{bindat-unpack}. If @var{name} corresponds to just one argument, |
| 2894 | that means to extract a top-level field value. Multiple @var{name} |
| 2895 | arguments specify repeated lookup of sub-structures. An integer name |
| 2896 | acts as an array index. |
| 2897 | |
| 2898 | For example, if @var{name} is @code{(a b 2 c)}, that means to find |
| 2899 | field @code{c} in the third element of subfield @code{b} of field |
| 2900 | @code{a}. (This corresponds to @code{struct.a.b[2].c} in C.) |
| 2901 | @end defun |
| 2902 | |
| 2903 | Although packing and unpacking operations change the organization of |
| 2904 | data (in memory), they preserve the data's @dfn{total length}, which is |
| 2905 | the sum of all the fields' lengths, in bytes. This value is not |
| 2906 | generally inherent in either the specification or alist alone; instead, |
| 2907 | both pieces of information contribute to its calculation. Likewise, the |
| 2908 | length of a string or array being unpacked may be longer than the data's |
| 2909 | total length as described by the specification. |
| 2910 | |
| 2911 | @defun bindat-length spec struct |
| 2912 | This function returns the total length of the data in @var{struct}, |
| 2913 | according to @var{spec}. |
| 2914 | @end defun |
| 2915 | |
| 2916 | @defun bindat-pack spec struct &optional bindat-raw bindat-idx |
| 2917 | This function returns a byte array packed according to @var{spec} from |
| 2918 | the data in the alist @var{struct}. It normally creates and fills a |
| 2919 | new byte array starting at the beginning. However, if @var{bindat-raw} |
| 2920 | is non-@code{nil}, it specifies a pre-allocated unibyte string or vector to |
| 2921 | pack into. If @var{bindat-idx} is non-@code{nil}, it specifies the starting |
| 2922 | offset for packing into @code{bindat-raw}. |
| 2923 | |
| 2924 | When pre-allocating, you should make sure @code{(length @var{bindat-raw})} |
| 2925 | meets or exceeds the total length to avoid an out-of-range error. |
| 2926 | @end defun |
| 2927 | |
| 2928 | @defun bindat-ip-to-string ip |
| 2929 | Convert the Internet address vector @var{ip} to a string in the usual |
| 2930 | dotted notation. |
| 2931 | @c FIXME? Does it do IPv6? |
| 2932 | |
| 2933 | @example |
| 2934 | (bindat-ip-to-string [127 0 0 1]) |
| 2935 | @result{} "127.0.0.1" |
| 2936 | @end example |
| 2937 | @end defun |
| 2938 | |
| 2939 | @node Bindat Examples |
| 2940 | @subsection Examples of Byte Unpacking and Packing |
| 2941 | @c FIXME? This seems a very long example for something that is not used |
| 2942 | @c very often. As of 24.1, gdb-mi.el is the only user of bindat.el in Emacs. |
| 2943 | @c Maybe one or both of these examples should just be moved to the |
| 2944 | @c commentary of bindat.el. |
| 2945 | |
| 2946 | Here is a complete example of byte unpacking and packing: |
| 2947 | |
| 2948 | @lisp |
| 2949 | (require 'bindat) |
| 2950 | |
| 2951 | (defvar fcookie-index-spec |
| 2952 | '((:version u32) |
| 2953 | (:count u32) |
| 2954 | (:longest u32) |
| 2955 | (:shortest u32) |
| 2956 | (:flags u32) |
| 2957 | (:delim u8) |
| 2958 | (:ignored fill 3) |
| 2959 | (:offset repeat (:count) (:foo u32))) |
| 2960 | "Description of a fortune cookie index file's contents.") |
| 2961 | |
| 2962 | (defun fcookie (cookies &optional index) |
| 2963 | "Display a random fortune cookie from file COOKIES. |
| 2964 | Optional second arg INDEX specifies the associated index |
| 2965 | filename, by default \"COOKIES.dat\". Display cookie text |
| 2966 | in buffer \"*Fortune Cookie: BASENAME*\", where BASENAME |
| 2967 | is COOKIES without the directory part." |
| 2968 | (interactive "fCookies file: ") |
| 2969 | (let* ((info (with-temp-buffer |
| 2970 | (insert-file-contents-literally |
| 2971 | (or index (concat cookies ".dat"))) |
| 2972 | (bindat-unpack fcookie-index-spec |
| 2973 | (buffer-string)))) |
| 2974 | (sel (random (bindat-get-field info :count))) |
| 2975 | (beg (cdar (bindat-get-field info :offset sel))) |
| 2976 | (end (or (cdar (bindat-get-field info |
| 2977 | :offset (1+ sel))) |
| 2978 | (nth 7 (file-attributes cookies))))) |
| 2979 | (switch-to-buffer |
| 2980 | (get-buffer-create |
| 2981 | (format "*Fortune Cookie: %s*" |
| 2982 | (file-name-nondirectory cookies)))) |
| 2983 | (erase-buffer) |
| 2984 | (insert-file-contents-literally |
| 2985 | cookies nil beg (- end 3)))) |
| 2986 | |
| 2987 | (defun fcookie-create-index (cookies &optional index delim) |
| 2988 | "Scan file COOKIES, and write out its index file. |
| 2989 | Optional arg INDEX specifies the index filename, which by |
| 2990 | default is \"COOKIES.dat\". Optional arg DELIM specifies the |
| 2991 | unibyte character that, when found on a line of its own in |
| 2992 | COOKIES, indicates the border between entries." |
| 2993 | (interactive "fCookies file: ") |
| 2994 | (setq delim (or delim ?%)) |
| 2995 | (let ((delim-line (format "\n%c\n" delim)) |
| 2996 | (count 0) |
| 2997 | (max 0) |
| 2998 | min p q len offsets) |
| 2999 | (unless (= 3 (string-bytes delim-line)) |
| 3000 | (error "Delimiter cannot be represented in one byte")) |
| 3001 | (with-temp-buffer |
| 3002 | (insert-file-contents-literally cookies) |
| 3003 | (while (and (setq p (point)) |
| 3004 | (search-forward delim-line (point-max) t) |
| 3005 | (setq len (- (point) 3 p))) |
| 3006 | (setq count (1+ count) |
| 3007 | max (max max len) |
| 3008 | min (min (or min max) len) |
| 3009 | offsets (cons (1- p) offsets)))) |
| 3010 | (with-temp-buffer |
| 3011 | (set-buffer-multibyte nil) |
| 3012 | (insert |
| 3013 | (bindat-pack |
| 3014 | fcookie-index-spec |
| 3015 | `((:version . 2) |
| 3016 | (:count . ,count) |
| 3017 | (:longest . ,max) |
| 3018 | (:shortest . ,min) |
| 3019 | (:flags . 0) |
| 3020 | (:delim . ,delim) |
| 3021 | (:offset . ,(mapcar (lambda (o) |
| 3022 | (list (cons :foo o))) |
| 3023 | (nreverse offsets)))))) |
| 3024 | (let ((coding-system-for-write 'raw-text-unix)) |
| 3025 | (write-file (or index (concat cookies ".dat"))))))) |
| 3026 | @end lisp |
| 3027 | |
| 3028 | The following is an example of defining and unpacking a complex |
| 3029 | structure. Consider the following C structures: |
| 3030 | |
| 3031 | @example |
| 3032 | struct header @{ |
| 3033 | unsigned long dest_ip; |
| 3034 | unsigned long src_ip; |
| 3035 | unsigned short dest_port; |
| 3036 | unsigned short src_port; |
| 3037 | @}; |
| 3038 | |
| 3039 | struct data @{ |
| 3040 | unsigned char type; |
| 3041 | unsigned char opcode; |
| 3042 | unsigned short length; /* in network byte order */ |
| 3043 | unsigned char id[8]; /* null-terminated string */ |
| 3044 | unsigned char data[/* (length + 3) & ~3 */]; |
| 3045 | @}; |
| 3046 | |
| 3047 | struct packet @{ |
| 3048 | struct header header; |
| 3049 | unsigned long counters[2]; /* in little endian order */ |
| 3050 | unsigned char items; |
| 3051 | unsigned char filler[3]; |
| 3052 | struct data item[/* items */]; |
| 3053 | |
| 3054 | @}; |
| 3055 | @end example |
| 3056 | |
| 3057 | The corresponding data layout specification is: |
| 3058 | |
| 3059 | @lisp |
| 3060 | (setq header-spec |
| 3061 | '((dest-ip ip) |
| 3062 | (src-ip ip) |
| 3063 | (dest-port u16) |
| 3064 | (src-port u16))) |
| 3065 | |
| 3066 | (setq data-spec |
| 3067 | '((type u8) |
| 3068 | (opcode u8) |
| 3069 | (length u16) ; network byte order |
| 3070 | (id strz 8) |
| 3071 | (data vec (length)) |
| 3072 | (align 4))) |
| 3073 | |
| 3074 | (setq packet-spec |
| 3075 | '((header struct header-spec) |
| 3076 | (counters vec 2 u32r) ; little endian order |
| 3077 | (items u8) |
| 3078 | (fill 3) |
| 3079 | (item repeat (items) |
| 3080 | (struct data-spec)))) |
| 3081 | @end lisp |
| 3082 | |
| 3083 | A binary data representation is: |
| 3084 | |
| 3085 | @lisp |
| 3086 | (setq binary-data |
| 3087 | [ 192 168 1 100 192 168 1 101 01 28 21 32 |
| 3088 | 160 134 1 0 5 1 0 0 2 0 0 0 |
| 3089 | 2 3 0 5 ?A ?B ?C ?D ?E ?F 0 0 1 2 3 4 5 0 0 0 |
| 3090 | 1 4 0 7 ?B ?C ?D ?E ?F ?G 0 0 6 7 8 9 10 11 12 0 ]) |
| 3091 | @end lisp |
| 3092 | |
| 3093 | The corresponding decoded structure is: |
| 3094 | |
| 3095 | @lisp |
| 3096 | (setq decoded (bindat-unpack packet-spec binary-data)) |
| 3097 | @result{} |
| 3098 | ((header |
| 3099 | (dest-ip . [192 168 1 100]) |
| 3100 | (src-ip . [192 168 1 101]) |
| 3101 | (dest-port . 284) |
| 3102 | (src-port . 5408)) |
| 3103 | (counters . [100000 261]) |
| 3104 | (items . 2) |
| 3105 | (item ((data . [1 2 3 4 5]) |
| 3106 | (id . "ABCDEF") |
| 3107 | (length . 5) |
| 3108 | (opcode . 3) |
| 3109 | (type . 2)) |
| 3110 | ((data . [6 7 8 9 10 11 12]) |
| 3111 | (id . "BCDEFG") |
| 3112 | (length . 7) |
| 3113 | (opcode . 4) |
| 3114 | (type . 1)))) |
| 3115 | @end lisp |
| 3116 | |
| 3117 | An example of fetching data from this structure: |
| 3118 | |
| 3119 | @lisp |
| 3120 | (bindat-get-field decoded 'item 1 'id) |
| 3121 | @result{} "BCDEFG" |
| 3122 | @end lisp |