6558
|
1 @c -*-texinfo-*-
|
|
2 @c This is part of the GNU Emacs Lisp Reference Manual.
|
62245
|
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1998, 1999, 2005
|
49600
|
4 @c Free Software Foundation, Inc.
|
6558
|
5 @c See the file elisp.texi for copying conditions.
|
|
6 @setfilename ../info/processes
|
21682
|
7 @node Processes, Display, Abbrevs, Top
|
6558
|
8 @chapter Processes
|
|
9 @cindex child process
|
|
10 @cindex parent process
|
|
11 @cindex subprocess
|
|
12 @cindex process
|
|
13
|
|
14 In the terminology of operating systems, a @dfn{process} is a space in
|
|
15 which a program can execute. Emacs runs in a process. Emacs Lisp
|
|
16 programs can invoke other programs in processes of their own. These are
|
|
17 called @dfn{subprocesses} or @dfn{child processes} of the Emacs process,
|
|
18 which is their @dfn{parent process}.
|
|
19
|
|
20 A subprocess of Emacs may be @dfn{synchronous} or @dfn{asynchronous},
|
|
21 depending on how it is created. When you create a synchronous
|
|
22 subprocess, the Lisp program waits for the subprocess to terminate
|
|
23 before continuing execution. When you create an asynchronous
|
|
24 subprocess, it can run in parallel with the Lisp program. This kind of
|
|
25 subprocess is represented within Emacs by a Lisp object which is also
|
|
26 called a ``process''. Lisp programs can use this object to communicate
|
|
27 with the subprocess or to control it. For example, you can send
|
|
28 signals, obtain status information, receive output from the process, or
|
|
29 send input to it.
|
|
30
|
|
31 @defun processp object
|
|
32 This function returns @code{t} if @var{object} is a process,
|
|
33 @code{nil} otherwise.
|
|
34 @end defun
|
|
35
|
|
36 @menu
|
|
37 * Subprocess Creation:: Functions that start subprocesses.
|
22138
|
38 * Shell Arguments:: Quoting an argument to pass it to a shell.
|
6558
|
39 * Synchronous Processes:: Details of using synchronous subprocesses.
|
|
40 * Asynchronous Processes:: Starting up an asynchronous subprocess.
|
|
41 * Deleting Processes:: Eliminating an asynchronous subprocess.
|
|
42 * Process Information:: Accessing run-status and other attributes.
|
|
43 * Input to Processes:: Sending input to an asynchronous subprocess.
|
|
44 * Signals to Processes:: Stopping, continuing or interrupting
|
|
45 an asynchronous subprocess.
|
|
46 * Output from Processes:: Collecting output from an asynchronous subprocess.
|
|
47 * Sentinels:: Sentinels run when process run-status changes.
|
46340
|
48 * Query Before Exit:: Whether to query if exiting will kill a process.
|
6558
|
49 * Transaction Queues:: Transaction-based communication with subprocesses.
|
12098
|
50 * Network:: Opening network connections.
|
52542
|
51 * Network Servers:: Network servers let Emacs accept net connections.
|
62245
|
52 * Datagrams:: UDP network connections.
|
52542
|
53 * Low-Level Network:: Lower-level but more general function
|
|
54 to create connections and servers.
|
63542
|
55 * Byte Packing:: Using bindat to pack and unpack binary data.
|
6558
|
56 @end menu
|
|
57
|
|
58 @node Subprocess Creation
|
|
59 @section Functions that Create Subprocesses
|
|
60
|
|
61 There are three functions that create a new subprocess in which to run
|
|
62 a program. One of them, @code{start-process}, creates an asynchronous
|
|
63 process and returns a process object (@pxref{Asynchronous Processes}).
|
|
64 The other two, @code{call-process} and @code{call-process-region},
|
|
65 create a synchronous process and do not return a process object
|
|
66 (@pxref{Synchronous Processes}).
|
|
67
|
25751
|
68 Synchronous and asynchronous processes are explained in the following
|
6558
|
69 sections. Since the three functions are all called in a similar
|
|
70 fashion, their common arguments are described here.
|
|
71
|
|
72 @cindex execute program
|
|
73 @cindex @code{PATH} environment variable
|
|
74 @cindex @code{HOME} environment variable
|
|
75 In all cases, the function's @var{program} argument specifies the
|
|
76 program to be run. An error is signaled if the file is not found or
|
|
77 cannot be executed. If the file name is relative, the variable
|
|
78 @code{exec-path} contains a list of directories to search. Emacs
|
|
79 initializes @code{exec-path} when it starts up, based on the value of
|
|
80 the environment variable @code{PATH}. The standard file name
|
60270
|
81 constructs, @samp{~}, @samp{.}, and @samp{..}, are interpreted as
|
|
82 usual in @code{exec-path}, but environment variable substitutions
|
6558
|
83 (@samp{$HOME}, etc.) are not recognized; use
|
|
84 @code{substitute-in-file-name} to perform them (@pxref{File Name
|
60270
|
85 Expansion}). @code{nil} in this list refers to
|
|
86 @code{default-directory}.
|
6558
|
87
|
51922
|
88 Executing a program can also try adding suffixes to the specified
|
|
89 name:
|
|
90
|
|
91 @defvar exec-suffixes
|
|
92 This variable is a list of suffixes (strings) to try adding to the
|
|
93 specified program file name. The list should include @code{""} if you
|
|
94 want the name to be tried exactly as specified. The default value is
|
|
95 system-dependent.
|
|
96 @end defvar
|
|
97
|
60270
|
98 @strong{Please note:} The argument @var{program} contains only the
|
|
99 name of the program; it may not contain any command-line arguments. You
|
|
100 must use @var{args} to provide those.
|
|
101
|
6558
|
102 Each of the subprocess-creating functions has a @var{buffer-or-name}
|
|
103 argument which specifies where the standard output from the program will
|
22252
|
104 go. It should be a buffer or a buffer name; if it is a buffer name,
|
|
105 that will create the buffer if it does not already exist. It can also
|
|
106 be @code{nil}, which says to discard the output unless a filter function
|
|
107 handles it. (@xref{Filter Functions}, and @ref{Read and Print}.)
|
|
108 Normally, you should avoid having multiple processes send output to the
|
|
109 same buffer because their output would be intermixed randomly.
|
6558
|
110
|
|
111 @cindex program arguments
|
|
112 All three of the subprocess-creating functions have a @code{&rest}
|
|
113 argument, @var{args}. The @var{args} must all be strings, and they are
|
|
114 supplied to @var{program} as separate command line arguments. Wildcard
|
21007
|
115 characters and other shell constructs have no special meanings in these
|
60270
|
116 strings, since the strings are passed directly to the specified program.
|
6558
|
117
|
|
118 The subprocess gets its current directory from the value of
|
|
119 @code{default-directory} (@pxref{File Name Expansion}).
|
|
120
|
|
121 @cindex environment variables, subprocesses
|
22252
|
122 The subprocess inherits its environment from Emacs, but you can
|
6558
|
123 specify overrides for it with @code{process-environment}. @xref{System
|
|
124 Environment}.
|
|
125
|
49600
|
126 @defvar exec-directory
|
17611
1b2afa6391ca
(exec-directory): Wakeup no longer exists, so use movemail as example.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
127 @pindex movemail
|
25751
|
128 The value of this variable is a string, the name of a directory that
|
22252
|
129 contains programs that come with GNU Emacs, programs intended for Emacs
|
17611
1b2afa6391ca
(exec-directory): Wakeup no longer exists, so use movemail as example.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
130 to invoke. The program @code{movemail} is an example of such a program;
|
1b2afa6391ca
(exec-directory): Wakeup no longer exists, so use movemail as example.
Richard M. Stallman <rms@gnu.org>
diff
changeset
|
131 Rmail uses it to fetch new mail from an inbox.
|
6558
|
132 @end defvar
|
|
133
|
|
134 @defopt exec-path
|
|
135 The value of this variable is a list of directories to search for
|
|
136 programs to run in subprocesses. Each element is either the name of a
|
|
137 directory (i.e., a string), or @code{nil}, which stands for the default
|
|
138 directory (which is the value of @code{default-directory}).
|
|
139 @cindex program directories
|
|
140
|
|
141 The value of @code{exec-path} is used by @code{call-process} and
|
|
142 @code{start-process} when the @var{program} argument is not an absolute
|
|
143 file name.
|
|
144 @end defopt
|
|
145
|
21682
|
146 @node Shell Arguments
|
|
147 @section Shell Arguments
|
|
148
|
|
149 Lisp programs sometimes need to run a shell and give it a command
|
25751
|
150 that contains file names that were specified by the user. These
|
21682
|
151 programs ought to be able to support any valid file name. But the shell
|
|
152 gives special treatment to certain characters, and if these characters
|
|
153 occur in the file name, they will confuse the shell. To handle these
|
|
154 characters, use the function @code{shell-quote-argument}:
|
|
155
|
|
156 @defun shell-quote-argument argument
|
|
157 This function returns a string which represents, in shell syntax,
|
|
158 an argument whose actual contents are @var{argument}. It should
|
|
159 work reliably to concatenate the return value into a shell command
|
|
160 and then pass it to a shell for execution.
|
|
161
|
|
162 Precisely what this function does depends on your operating system. The
|
25751
|
163 function is designed to work with the syntax of your system's standard
|
|
164 shell; if you use an unusual shell, you will need to redefine this
|
|
165 function.
|
21682
|
166
|
|
167 @example
|
|
168 ;; @r{This example shows the behavior on GNU and Unix systems.}
|
|
169 (shell-quote-argument "foo > bar")
|
|
170 @result{} "foo\\ \\>\\ bar"
|
25751
|
171
|
63583
|
172 ;; @r{This example shows the behavior on MS-DOS and MS-Windows.}
|
25751
|
173 (shell-quote-argument "foo > bar")
|
|
174 @result{} "\"foo > bar\""
|
21682
|
175 @end example
|
|
176
|
|
177 Here's an example of using @code{shell-quote-argument} to construct
|
|
178 a shell command:
|
|
179
|
|
180 @example
|
|
181 (concat "diff -c "
|
|
182 (shell-quote-argument oldfile)
|
|
183 " "
|
|
184 (shell-quote-argument newfile))
|
|
185 @end example
|
|
186 @end defun
|
|
187
|
6558
|
188 @node Synchronous Processes
|
|
189 @section Creating a Synchronous Process
|
|
190 @cindex synchronous subprocess
|
|
191
|
|
192 After a @dfn{synchronous process} is created, Emacs waits for the
|
25751
|
193 process to terminate before continuing. Starting Dired on GNU or
|
|
194 Unix@footnote{On other systems, Emacs uses a Lisp emulation of
|
|
195 @code{ls}; see @ref{Contents of Directories}.} is an example of this: it
|
|
196 runs @code{ls} in a synchronous process, then modifies the output
|
|
197 slightly. Because the process is synchronous, the entire directory
|
|
198 listing arrives in the buffer before Emacs tries to do anything with it.
|
6558
|
199
|
|
200 While Emacs waits for the synchronous subprocess to terminate, the
|
|
201 user can quit by typing @kbd{C-g}. The first @kbd{C-g} tries to kill
|
|
202 the subprocess with a @code{SIGINT} signal; but it waits until the
|
|
203 subprocess actually terminates before quitting. If during that time the
|
|
204 user types another @kbd{C-g}, that kills the subprocess instantly with
|
25751
|
205 @code{SIGKILL} and quits immediately (except on MS-DOS, where killing
|
|
206 other processes doesn't work). @xref{Quitting}.
|
6558
|
207
|
21682
|
208 The synchronous subprocess functions return an indication of how the
|
|
209 process terminated.
|
21007
|
210
|
|
211 The output from a synchronous subprocess is generally decoded using a
|
|
212 coding system, much like text read from a file. The input sent to a
|
|
213 subprocess by @code{call-process-region} is encoded using a coding
|
|
214 system, much like text written into a file. @xref{Coding Systems}.
|
6558
|
215
|
12067
|
216 @defun call-process program &optional infile destination display &rest args
|
6558
|
217 This function calls @var{program} in a separate process and waits for
|
|
218 it to finish.
|
|
219
|
|
220 The standard input for the process comes from file @var{infile} if
|
25751
|
221 @var{infile} is not @code{nil}, and from the null device otherwise.
|
12067
|
222 The argument @var{destination} says where to put the process output.
|
|
223 Here are the possibilities:
|
|
224
|
|
225 @table @asis
|
|
226 @item a buffer
|
|
227 Insert the output in that buffer, before point. This includes both the
|
|
228 standard output stream and the standard error stream of the process.
|
|
229
|
|
230 @item a string
|
21682
|
231 Insert the output in a buffer with that name, before point.
|
12067
|
232
|
|
233 @item @code{t}
|
|
234 Insert the output in the current buffer, before point.
|
|
235
|
|
236 @item @code{nil}
|
|
237 Discard the output.
|
6558
|
238
|
12067
|
239 @item 0
|
25751
|
240 Discard the output, and return @code{nil} immediately without waiting
|
12067
|
241 for the subprocess to finish.
|
|
242
|
|
243 In this case, the process is not truly synchronous, since it can run in
|
|
244 parallel with Emacs; but you can think of it as synchronous in that
|
|
245 Emacs is essentially finished with the subprocess as soon as this
|
|
246 function returns.
|
|
247
|
25751
|
248 MS-DOS doesn't support asynchronous subprocesses, so this option doesn't
|
|
249 work there.
|
|
250
|
22252
|
251 @item @code{(@var{real-destination} @var{error-destination})}
|
12067
|
252 Keep the standard output stream separate from the standard error stream;
|
|
253 deal with the ordinary output as specified by @var{real-destination},
|
|
254 and dispose of the error output according to @var{error-destination}.
|
21682
|
255 If @var{error-destination} is @code{nil}, that means to discard the
|
|
256 error output, @code{t} means mix it with the ordinary output, and a
|
|
257 string specifies a file name to redirect error output into.
|
12067
|
258
|
|
259 You can't directly specify a buffer to put the error output in; that is
|
|
260 too difficult to implement. But you can achieve this result by sending
|
|
261 the error output to a temporary file and then inserting the file into a
|
|
262 buffer.
|
|
263 @end table
|
6558
|
264
|
|
265 If @var{display} is non-@code{nil}, then @code{call-process} redisplays
|
22138
|
266 the buffer as output is inserted. (However, if the coding system chosen
|
|
267 for decoding output is @code{undecided}, meaning deduce the encoding
|
|
268 from the actual data, then redisplay sometimes cannot continue once
|
52978
|
269 non-@acronym{ASCII} characters are encountered. There are fundamental
|
25751
|
270 reasons why it is hard to fix this; see @ref{Output from Processes}.)
|
|
271
|
|
272 Otherwise the function @code{call-process} does no redisplay, and the
|
|
273 results become visible on the screen only when Emacs redisplays that
|
|
274 buffer in the normal course of events.
|
6558
|
275
|
|
276 The remaining arguments, @var{args}, are strings that specify command
|
|
277 line arguments for the program.
|
|
278
|
|
279 The value returned by @code{call-process} (unless you told it not to
|
|
280 wait) indicates the reason for process termination. A number gives the
|
|
281 exit status of the subprocess; 0 means success, and any other value
|
|
282 means failure. If the process terminated with a signal,
|
|
283 @code{call-process} returns a string describing the signal.
|
|
284
|
|
285 In the examples below, the buffer @samp{foo} is current.
|
|
286
|
|
287 @smallexample
|
|
288 @group
|
|
289 (call-process "pwd" nil t)
|
25751
|
290 @result{} 0
|
6558
|
291
|
|
292 ---------- Buffer: foo ----------
|
|
293 /usr/user/lewis/manual
|
|
294 ---------- Buffer: foo ----------
|
|
295 @end group
|
|
296
|
|
297 @group
|
|
298 (call-process "grep" nil "bar" nil "lewis" "/etc/passwd")
|
25751
|
299 @result{} 0
|
6558
|
300
|
|
301 ---------- Buffer: bar ----------
|
|
302 lewis:5LTsHm66CSWKg:398:21:Bil Lewis:/user/lewis:/bin/csh
|
|
303
|
|
304 ---------- Buffer: bar ----------
|
|
305 @end group
|
|
306 @end smallexample
|
|
307
|
21682
|
308 Here is a good example of the use of @code{call-process}, which used to
|
|
309 be found in the definition of @code{insert-directory}:
|
6558
|
310
|
|
311 @smallexample
|
|
312 @group
|
21682
|
313 (call-process insert-directory-program nil t nil @var{switches}
|
6558
|
314 (if full-directory-p
|
|
315 (concat (file-name-as-directory file) ".")
|
|
316 file))
|
|
317 @end group
|
|
318 @end smallexample
|
|
319 @end defun
|
|
320
|
57670
|
321 @defun process-file program &optional infile buffer display &rest args
|
|
322 This function processes files synchronously in a separate process. It
|
|
323 is similar to @code{call-process} but may invoke a file handler based
|
|
324 on the value of the variable @code{default-directory}. The current
|
|
325 working directory of the subprocess is @code{default-directory}.
|
|
326
|
|
327 The arguments are handled in almost the same way as for
|
|
328 @code{call-process}, with the following differences:
|
|
329
|
|
330 Some file handlers may not support all combinations and forms of the
|
|
331 arguments @var{infile}, @var{buffer}, and @var{display}. For example,
|
58500
|
332 some file handlers might behave as if @var{display} were @code{nil},
|
57670
|
333 regardless of the value actually passed. As another example, some
|
|
334 file handlers might not support separating standard output and error
|
|
335 output by way of the @var{buffer} argument.
|
|
336
|
|
337 If a file handler is invoked, it determines the program to run based
|
|
338 on the first argument @var{program}. For instance, consider that a
|
|
339 handler for remote files is invoked. Then the path that is used for
|
|
340 searching the program might be different than @code{exec-path}.
|
|
341
|
|
342 The second argument @var{infile} may invoke a file handler. The file
|
|
343 handler could be different from the handler chosen for the
|
|
344 @code{process-file} function itself. (For example,
|
|
345 @code{default-directory} could be on a remote host, whereas
|
|
346 @var{infile} is on another remote host. Or @code{default-directory}
|
|
347 could be non-special, whereas @var{infile} is on a remote host.)
|
|
348
|
|
349 If @var{buffer} has the form @code{(@var{real-destination}
|
|
350 @var{error-destination})}, and @var{error-destination} names a file,
|
|
351 then the same remarks as for @var{infile} apply.
|
|
352
|
|
353 The remaining arguments (@var{args}) will be passed to the process
|
|
354 verbatim. Emacs is not involved in processing file names that are
|
|
355 present in @var{args}. To avoid confusion, it may be best to avoid
|
|
356 absolute file names in @var{args}, but rather to specify all file
|
|
357 names as relative to @code{default-directory}. The function
|
|
358 @code{file-relative-name} is useful for constructing such relative
|
|
359 file names.
|
|
360 @end defun
|
|
361
|
12067
|
362 @defun call-process-region start end program &optional delete destination display &rest args
|
25751
|
363 This function sends the text from @var{start} to @var{end} as
|
6558
|
364 standard input to a process running @var{program}. It deletes the text
|
21007
|
365 sent if @var{delete} is non-@code{nil}; this is useful when
|
|
366 @var{destination} is @code{t}, to insert the output in the current
|
|
367 buffer in place of the input.
|
6558
|
368
|
12067
|
369 The arguments @var{destination} and @var{display} control what to do
|
6558
|
370 with the output from the subprocess, and whether to update the display
|
|
371 as it comes in. For details, see the description of
|
12067
|
372 @code{call-process}, above. If @var{destination} is the integer 0,
|
6558
|
373 @code{call-process-region} discards the output and returns @code{nil}
|
25751
|
374 immediately, without waiting for the subprocess to finish (this only
|
27370
|
375 works if asynchronous subprocesses are supported).
|
6558
|
376
|
|
377 The remaining arguments, @var{args}, are strings that specify command
|
|
378 line arguments for the program.
|
|
379
|
|
380 The return value of @code{call-process-region} is just like that of
|
|
381 @code{call-process}: @code{nil} if you told it to return without
|
|
382 waiting; otherwise, a number or string which indicates how the
|
|
383 subprocess terminated.
|
|
384
|
|
385 In the following example, we use @code{call-process-region} to run the
|
|
386 @code{cat} utility, with standard input being the first five characters
|
|
387 in buffer @samp{foo} (the word @samp{input}). @code{cat} copies its
|
|
388 standard input into its standard output. Since the argument
|
12067
|
389 @var{destination} is @code{t}, this output is inserted in the current
|
6558
|
390 buffer.
|
|
391
|
|
392 @smallexample
|
|
393 @group
|
|
394 ---------- Buffer: foo ----------
|
|
395 input@point{}
|
|
396 ---------- Buffer: foo ----------
|
|
397 @end group
|
|
398
|
|
399 @group
|
|
400 (call-process-region 1 6 "cat" nil t)
|
25751
|
401 @result{} 0
|
6558
|
402
|
|
403 ---------- Buffer: foo ----------
|
|
404 inputinput@point{}
|
|
405 ---------- Buffer: foo ----------
|
|
406 @end group
|
|
407 @end smallexample
|
|
408
|
|
409 The @code{shell-command-on-region} command uses
|
|
410 @code{call-process-region} like this:
|
|
411
|
|
412 @smallexample
|
|
413 @group
|
49600
|
414 (call-process-region
|
|
415 start end
|
6558
|
416 shell-file-name ; @r{Name of program.}
|
|
417 nil ; @r{Do not delete region.}
|
|
418 buffer ; @r{Send output to @code{buffer}.}
|
|
419 nil ; @r{No redisplay during output.}
|
|
420 "-c" command) ; @r{Arguments for the shell.}
|
|
421 @end group
|
|
422 @end smallexample
|
|
423 @end defun
|
|
424
|
52542
|
425 @defun call-process-shell-command command &optional infile destination display &rest args
|
|
426 This function executes the shell command @var{command} synchronously
|
54265
|
427 in a separate process. The final arguments @var{args} are additional
|
52542
|
428 arguments to add at the end of @var{command}. The other arguments
|
|
429 are handled as in @code{call-process}.
|
|
430 @end defun
|
|
431
|
22138
|
432 @defun shell-command-to-string command
|
21007
|
433 This function executes @var{command} (a string) as a shell command,
|
|
434 then returns the command's output as a string.
|
|
435 @end defun
|
|
436
|
6558
|
437 @node Asynchronous Processes
|
|
438 @section Creating an Asynchronous Process
|
|
439 @cindex asynchronous subprocess
|
|
440
|
22252
|
441 After an @dfn{asynchronous process} is created, Emacs and the subprocess
|
|
442 both continue running immediately. The process thereafter runs
|
22138
|
443 in parallel with Emacs, and the two can communicate with each other
|
25751
|
444 using the functions described in the following sections. However,
|
22138
|
445 communication is only partially asynchronous: Emacs sends data to the
|
|
446 process only when certain functions are called, and Emacs accepts data
|
|
447 from the process only when Emacs is waiting for input or for a time
|
|
448 delay.
|
|
449
|
|
450 Here we describe how to create an asynchronous process.
|
6558
|
451
|
|
452 @defun start-process name buffer-or-name program &rest args
|
|
453 This function creates a new asynchronous subprocess and starts the
|
|
454 program @var{program} running in it. It returns a process object that
|
|
455 stands for the new subprocess in Lisp. The argument @var{name}
|
|
456 specifies the name for the process object; if a process with this name
|
21007
|
457 already exists, then @var{name} is modified (by appending @samp{<1>},
|
|
458 etc.) to be unique. The buffer @var{buffer-or-name} is the buffer to
|
6558
|
459 associate with the process.
|
|
460
|
|
461 The remaining arguments, @var{args}, are strings that specify command
|
|
462 line arguments for the program.
|
|
463
|
|
464 In the example below, the first process is started and runs (rather,
|
|
465 sleeps) for 100 seconds. Meanwhile, the second process is started, and
|
|
466 given the name @samp{my-process<1>} for the sake of uniqueness. It
|
|
467 inserts the directory listing at the end of the buffer @samp{foo},
|
|
468 before the first process finishes. Then it finishes, and a message to
|
|
469 that effect is inserted in the buffer. Much later, the first process
|
|
470 finishes, and another message is inserted in the buffer for it.
|
|
471
|
|
472 @smallexample
|
|
473 @group
|
|
474 (start-process "my-process" "foo" "sleep" "100")
|
|
475 @result{} #<process my-process>
|
|
476 @end group
|
|
477
|
|
478 @group
|
|
479 (start-process "my-process" "foo" "ls" "-l" "/user/lewis/bin")
|
|
480 @result{} #<process my-process<1>>
|
|
481
|
|
482 ---------- Buffer: foo ----------
|
|
483 total 2
|
|
484 lrwxrwxrwx 1 lewis 14 Jul 22 10:12 gnuemacs --> /emacs
|
|
485 -rwxrwxrwx 1 lewis 19 Jul 30 21:02 lemon
|
|
486
|
|
487 Process my-process<1> finished
|
|
488
|
|
489 Process my-process finished
|
|
490 ---------- Buffer: foo ----------
|
|
491 @end group
|
|
492 @end smallexample
|
|
493 @end defun
|
|
494
|
|
495 @defun start-process-shell-command name buffer-or-name command &rest command-args
|
|
496 This function is like @code{start-process} except that it uses a shell
|
|
497 to execute the specified command. The argument @var{command} is a shell
|
|
498 command name, and @var{command-args} are the arguments for the shell
|
21007
|
499 command. The variable @code{shell-file-name} specifies which shell to
|
|
500 use.
|
21682
|
501
|
|
502 The point of running a program through the shell, rather than directly
|
|
503 with @code{start-process}, is so that you can employ shell features such
|
|
504 as wildcards in the arguments. It follows that if you include an
|
25751
|
505 arbitrary user-specified arguments in the command, you should quote it
|
21682
|
506 with @code{shell-quote-argument} first, so that any special shell
|
25751
|
507 characters do @emph{not} have their special shell meanings. @xref{Shell
|
|
508 Arguments}.
|
6558
|
509 @end defun
|
|
510
|
|
511 @defvar process-connection-type
|
|
512 @cindex pipes
|
52978
|
513 @cindex @acronym{PTY}s
|
6558
|
514 This variable controls the type of device used to communicate with
|
52978
|
515 asynchronous subprocesses. If it is non-@code{nil}, then @acronym{PTY}s are
|
12098
|
516 used, when available. Otherwise, pipes are used.
|
6558
|
517
|
52978
|
518 @acronym{PTY}s are usually preferable for processes visible to the user, as
|
6558
|
519 in Shell mode, because they allow job control (@kbd{C-c}, @kbd{C-z},
|
21007
|
520 etc.) to work between the process and its children, whereas pipes do
|
|
521 not. For subprocesses used for internal purposes by programs, it is
|
|
522 often better to use a pipe, because they are more efficient. In
|
52978
|
523 addition, the total number of @acronym{PTY}s is limited on many systems and
|
21007
|
524 it is good not to waste them.
|
6558
|
525
|
46340
|
526 The value of @code{process-connection-type} takes effect when
|
6558
|
527 @code{start-process} is called. So you can specify how to communicate
|
|
528 with one subprocess by binding the variable around the call to
|
|
529 @code{start-process}.
|
|
530
|
|
531 @smallexample
|
|
532 @group
|
|
533 (let ((process-connection-type nil)) ; @r{Use a pipe.}
|
|
534 (start-process @dots{}))
|
|
535 @end group
|
|
536 @end smallexample
|
12067
|
537
|
|
538 To determine whether a given subprocess actually got a pipe or a
|
52978
|
539 @acronym{PTY}, use the function @code{process-tty-name} (@pxref{Process
|
12067
|
540 Information}).
|
6558
|
541 @end defvar
|
|
542
|
|
543 @node Deleting Processes
|
|
544 @section Deleting Processes
|
|
545 @cindex deleting processes
|
|
546
|
|
547 @dfn{Deleting a process} disconnects Emacs immediately from the
|
44345
|
548 subprocess. Processes are deleted automatically after they terminate,
|
|
549 but not necessarily right away. You can delete a process explicitly
|
|
550 at any time. If you delete a terminated process explicitly before it
|
60270
|
551 is deleted automatically, no harm results. Deleting a running
|
46340
|
552 process sends a signal to terminate it (and its child processes if
|
60270
|
553 any), and calls the process sentinel if it has one. @xref{Sentinels}.
|
6558
|
554
|
60270
|
555 When a process is deleted, the process object itself continues to
|
|
556 exist as long as other Lisp objects point to it. All the Lisp
|
|
557 primitives that work on process objects accept deleted processes, but
|
|
558 those that do I/O or send signals will report an error. The process
|
|
559 mark continues to point to the same place as before, usually into a
|
|
560 buffer where output from the process was being inserted.
|
6558
|
561
|
22252
|
562 @defopt delete-exited-processes
|
6558
|
563 This variable controls automatic deletion of processes that have
|
|
564 terminated (due to calling @code{exit} or to a signal). If it is
|
|
565 @code{nil}, then they continue to exist until the user runs
|
|
566 @code{list-processes}. Otherwise, they are deleted immediately after
|
|
567 they exit.
|
22252
|
568 @end defopt
|
6558
|
569
|
60270
|
570 @defun delete-process process
|
|
571 This function deletes a process, killing it with a @code{SIGKILL}
|
|
572 signal. The argument may be a process, the name of a process, a
|
|
573 buffer, or the name of a buffer. (A buffer or buffer-name stands for
|
|
574 the process that @code{get-buffer-process} returns.) Calling
|
|
575 @code{delete-process} on a running process terminates it, updates the
|
|
576 process status, and runs the sentinel (if any) immediately. If the
|
|
577 process has already terminated, calling @code{delete-process} has no
|
|
578 effect on its status, or on the running of its sentinel (which will
|
|
579 happen sooner or later).
|
6558
|
580
|
|
581 @smallexample
|
|
582 @group
|
|
583 (delete-process "*shell*")
|
|
584 @result{} nil
|
|
585 @end group
|
|
586 @end smallexample
|
|
587 @end defun
|
|
588
|
|
589 @node Process Information
|
|
590 @section Process Information
|
|
591
|
|
592 Several functions return information about processes.
|
|
593 @code{list-processes} is provided for interactive use.
|
|
594
|
52542
|
595 @deffn Command list-processes &optional query-only
|
6558
|
596 This command displays a listing of all living processes. In addition,
|
|
597 it finally deletes any process whose status was @samp{Exited} or
|
|
598 @samp{Signaled}. It returns @code{nil}.
|
52542
|
599
|
|
600 If @var{query-only} is non-@code{nil} then it lists only processes
|
|
601 whose query flag is non-@code{nil}. @xref{Query Before Exit}.
|
6558
|
602 @end deffn
|
|
603
|
|
604 @defun process-list
|
|
605 This function returns a list of all processes that have not been deleted.
|
|
606
|
|
607 @smallexample
|
|
608 @group
|
|
609 (process-list)
|
|
610 @result{} (#<process display-time> #<process shell>)
|
|
611 @end group
|
|
612 @end smallexample
|
|
613 @end defun
|
|
614
|
|
615 @defun get-process name
|
|
616 This function returns the process named @var{name}, or @code{nil} if
|
|
617 there is none. An error is signaled if @var{name} is not a string.
|
|
618
|
|
619 @smallexample
|
|
620 @group
|
|
621 (get-process "shell")
|
|
622 @result{} #<process shell>
|
|
623 @end group
|
|
624 @end smallexample
|
|
625 @end defun
|
|
626
|
|
627 @defun process-command process
|
|
628 This function returns the command that was executed to start
|
|
629 @var{process}. This is a list of strings, the first string being the
|
|
630 program executed and the rest of the strings being the arguments that
|
|
631 were given to the program.
|
|
632
|
|
633 @smallexample
|
|
634 @group
|
|
635 (process-command (get-process "shell"))
|
|
636 @result{} ("/bin/csh" "-i")
|
|
637 @end group
|
|
638 @end smallexample
|
|
639 @end defun
|
|
640
|
|
641 @defun process-id process
|
52978
|
642 This function returns the @acronym{PID} of @var{process}. This is an
|
9009
|
643 integer that distinguishes the process @var{process} from all other
|
6558
|
644 processes running on the same computer at the current time. The
|
52978
|
645 @acronym{PID} of a process is chosen by the operating system kernel when the
|
6558
|
646 process is started and remains constant as long as the process exists.
|
|
647 @end defun
|
|
648
|
|
649 @defun process-name process
|
|
650 This function returns the name of @var{process}.
|
|
651 @end defun
|
|
652
|
|
653 @defun process-status process-name
|
|
654 This function returns the status of @var{process-name} as a symbol.
|
|
655 The argument @var{process-name} must be a process, a buffer, a
|
|
656 process name (string) or a buffer name (string).
|
|
657
|
|
658 The possible values for an actual subprocess are:
|
|
659
|
|
660 @table @code
|
|
661 @item run
|
|
662 for a process that is running.
|
|
663 @item stop
|
|
664 for a process that is stopped but continuable.
|
|
665 @item exit
|
|
666 for a process that has exited.
|
|
667 @item signal
|
|
668 for a process that has received a fatal signal.
|
|
669 @item open
|
|
670 for a network connection that is open.
|
|
671 @item closed
|
|
672 for a network connection that is closed. Once a connection
|
|
673 is closed, you cannot reopen it, though you might be able to open
|
|
674 a new connection to the same place.
|
52542
|
675 @item connect
|
|
676 for a non-blocking connection that is waiting to complete.
|
|
677 @item failed
|
|
678 for a non-blocking connection that has failed to complete.
|
|
679 @item listen
|
|
680 for a network server that is listening.
|
6558
|
681 @item nil
|
|
682 if @var{process-name} is not the name of an existing process.
|
|
683 @end table
|
|
684
|
|
685 @smallexample
|
|
686 @group
|
|
687 (process-status "shell")
|
|
688 @result{} run
|
|
689 @end group
|
|
690 @group
|
|
691 (process-status (get-buffer "*shell*"))
|
|
692 @result{} run
|
|
693 @end group
|
|
694 @group
|
|
695 x
|
|
696 @result{} #<process xx<1>>
|
|
697 (process-status x)
|
|
698 @result{} exit
|
|
699 @end group
|
|
700 @end smallexample
|
|
701
|
|
702 For a network connection, @code{process-status} returns one of the symbols
|
|
703 @code{open} or @code{closed}. The latter means that the other side
|
|
704 closed the connection, or Emacs did @code{delete-process}.
|
|
705 @end defun
|
|
706
|
|
707 @defun process-exit-status process
|
|
708 This function returns the exit status of @var{process} or the signal
|
|
709 number that killed it. (Use the result of @code{process-status} to
|
|
710 determine which of those it is.) If @var{process} has not yet
|
|
711 terminated, the value is 0.
|
|
712 @end defun
|
|
713
|
12067
|
714 @defun process-tty-name process
|
|
715 This function returns the terminal name that @var{process} is using for
|
|
716 its communication with Emacs---or @code{nil} if it is using pipes
|
|
717 instead of a terminal (see @code{process-connection-type} in
|
|
718 @ref{Asynchronous Processes}).
|
|
719 @end defun
|
|
720
|
56215
|
721 @defun process-coding-system process
|
53292
|
722 @anchor{Coding systems for a subprocess}
|
21007
|
723 This function returns a cons cell describing the coding systems in use
|
|
724 for decoding output from @var{process} and for encoding input to
|
|
725 @var{process} (@pxref{Coding Systems}). The value has this form:
|
|
726
|
|
727 @example
|
21682
|
728 (@var{coding-system-for-decoding} . @var{coding-system-for-encoding})
|
21007
|
729 @end example
|
|
730 @end defun
|
|
731
|
60270
|
732 @defun set-process-coding-system process &optional decoding-system encoding-system
|
21007
|
733 This function specifies the coding systems to use for subsequent output
|
|
734 from and input to @var{process}. It will use @var{decoding-system} to
|
|
735 decode subprocess output, and @var{encoding-system} to encode subprocess
|
|
736 input.
|
|
737 @end defun
|
|
738
|
52542
|
739 Every process also has a property list that you can use to store
|
|
740 miscellaneous values associated with the process.
|
|
741
|
|
742 @defun process-get process propname
|
|
743 This function returns the value of the @var{propname} property
|
|
744 of @var{process}.
|
|
745 @end defun
|
|
746
|
|
747 @defun process-put process propname value
|
|
748 This function sets the value of the @var{propname} property
|
|
749 of @var{process} to @var{value}.
|
|
750 @end defun
|
|
751
|
|
752 @defun process-plist process
|
|
753 This function returns the process plist of @var{process}.
|
|
754 @end defun
|
|
755
|
|
756 @defun set-process-plist process plist
|
|
757 This function sets the process plist of @var{process} to @var{plist}.
|
|
758 @end defun
|
|
759
|
6558
|
760 @node Input to Processes
|
|
761 @section Sending Input to Processes
|
|
762 @cindex process input
|
|
763
|
|
764 Asynchronous subprocesses receive input when it is sent to them by
|
|
765 Emacs, which is done with the functions in this section. You must
|
|
766 specify the process to send input to, and the input data to send. The
|
|
767 data appears on the ``standard input'' of the subprocess.
|
|
768
|
|
769 Some operating systems have limited space for buffered input in a
|
63560
|
770 @acronym{PTY}. On these systems, Emacs sends an @acronym{EOF}
|
|
771 periodically amidst the other characters, to force them through. For
|
|
772 most programs, these @acronym{EOF}s do no harm.
|
6558
|
773
|
21007
|
774 Subprocess input is normally encoded using a coding system before the
|
22138
|
775 subprocess receives it, much like text written into a file. You can use
|
|
776 @code{set-process-coding-system} to specify which coding system to use
|
|
777 (@pxref{Process Information}). Otherwise, the coding system comes from
|
|
778 @code{coding-system-for-write}, if that is non-@code{nil}; or else from
|
|
779 the defaulting mechanism (@pxref{Default Coding Systems}).
|
21007
|
780
|
24951
|
781 Sometimes the system is unable to accept input for that process,
|
|
782 because the input buffer is full. When this happens, the send functions
|
|
783 wait a short while, accepting output from subprocesses, and then try
|
|
784 again. This gives the subprocess a chance to read more of its pending
|
|
785 input and make space in the buffer. It also allows filters, sentinels
|
|
786 and timers to run---so take account of that in writing your code.
|
|
787
|
60270
|
788 In these functions, the @var{process} argument can be a process or
|
|
789 the name of a process, or a buffer or buffer name (which stands
|
|
790 for a process via @code{get-buffer-process}). @code{nil} means
|
|
791 the current buffer's process.
|
|
792
|
|
793 @defun process-send-string process string
|
|
794 This function sends @var{process} the contents of @var{string} as
|
|
795 standard input. If it is @code{nil}, the current buffer's process is used.
|
6558
|
796
|
|
797 The function returns @code{nil}.
|
|
798
|
|
799 @smallexample
|
|
800 @group
|
|
801 (process-send-string "shell<1>" "ls\n")
|
|
802 @result{} nil
|
|
803 @end group
|
|
804
|
|
805
|
|
806 @group
|
|
807 ---------- Buffer: *shell* ----------
|
|
808 ...
|
|
809 introduction.texi syntax-tables.texi~
|
|
810 introduction.texi~ text.texi
|
|
811 introduction.txt text.texi~
|
|
812 ...
|
|
813 ---------- Buffer: *shell* ----------
|
|
814 @end group
|
|
815 @end smallexample
|
|
816 @end defun
|
|
817
|
60270
|
818 @defun process-send-region process start end
|
6558
|
819 This function sends the text in the region defined by @var{start} and
|
60270
|
820 @var{end} as standard input to @var{process}.
|
6558
|
821
|
|
822 An error is signaled unless both @var{start} and @var{end} are
|
|
823 integers or markers that indicate positions in the current buffer. (It
|
|
824 is unimportant which number is larger.)
|
25751
|
825 @end defun
|
6558
|
826
|
60270
|
827 @defun process-send-eof &optional process
|
|
828 This function makes @var{process} see an end-of-file in its
|
52978
|
829 input. The @acronym{EOF} comes after any text already sent to it.
|
6558
|
830
|
60270
|
831 The function returns @var{process}.
|
6558
|
832
|
|
833 @smallexample
|
|
834 @group
|
|
835 (process-send-eof "shell")
|
|
836 @result{} "shell"
|
|
837 @end group
|
|
838 @end smallexample
|
|
839 @end defun
|
|
840
|
24951
|
841 @defun process-running-child-p process
|
|
842 @tindex process-running-child-p process
|
|
843 This function will tell you whether a subprocess has given control of
|
|
844 its terminal to its own child process. The value is @code{t} if this is
|
|
845 true, or if Emacs cannot tell; it is @code{nil} if Emacs can be certain
|
|
846 that this is not so.
|
|
847 @end defun
|
|
848
|
6558
|
849 @node Signals to Processes
|
|
850 @section Sending Signals to Processes
|
|
851 @cindex process signals
|
|
852 @cindex sending signals
|
|
853 @cindex signals
|
|
854
|
|
855 @dfn{Sending a signal} to a subprocess is a way of interrupting its
|
|
856 activities. There are several different signals, each with its own
|
|
857 meaning. The set of signals and their names is defined by the operating
|
|
858 system. For example, the signal @code{SIGINT} means that the user has
|
|
859 typed @kbd{C-c}, or that some analogous thing has happened.
|
|
860
|
|
861 Each signal has a standard effect on the subprocess. Most signals
|
|
862 kill the subprocess, but some stop or resume execution instead. Most
|
|
863 signals can optionally be handled by programs; if the program handles
|
|
864 the signal, then we can say nothing in general about its effects.
|
|
865
|
|
866 You can send signals explicitly by calling the functions in this
|
|
867 section. Emacs also sends signals automatically at certain times:
|
|
868 killing a buffer sends a @code{SIGHUP} signal to all its associated
|
|
869 processes; killing Emacs sends a @code{SIGHUP} signal to all remaining
|
|
870 processes. (@code{SIGHUP} is a signal that usually indicates that the
|
|
871 user hung up the phone.)
|
|
872
|
|
873 Each of the signal-sending functions takes two optional arguments:
|
62229
|
874 @var{process} and @var{current-group}.
|
6558
|
875
|
60270
|
876 The argument @var{process} must be either a process, a process
|
|
877 name, a buffer, a buffer name, or @code{nil}. A buffer or buffer name
|
|
878 stands for a process through @code{get-buffer-process}. @code{nil}
|
|
879 stands for the process associated with the current buffer. An error
|
|
880 is signaled if @var{process} does not identify a process.
|
6558
|
881
|
|
882 The argument @var{current-group} is a flag that makes a difference
|
|
883 when you are running a job-control shell as an Emacs subprocess. If it
|
|
884 is non-@code{nil}, then the signal is sent to the current process-group
|
9009
|
885 of the terminal that Emacs uses to communicate with the subprocess. If
|
6558
|
886 the process is a job-control shell, this means the shell's current
|
|
887 subjob. If it is @code{nil}, the signal is sent to the process group of
|
|
888 the immediate subprocess of Emacs. If the subprocess is a job-control
|
|
889 shell, this is the shell itself.
|
|
890
|
|
891 The flag @var{current-group} has no effect when a pipe is used to
|
|
892 communicate with the subprocess, because the operating system does not
|
|
893 support the distinction in the case of pipes. For the same reason,
|
|
894 job-control shells won't work when a pipe is used. See
|
|
895 @code{process-connection-type} in @ref{Asynchronous Processes}.
|
|
896
|
60270
|
897 @defun interrupt-process &optional process current-group
|
|
898 This function interrupts the process @var{process} by sending the
|
6558
|
899 signal @code{SIGINT}. Outside of Emacs, typing the ``interrupt
|
|
900 character'' (normally @kbd{C-c} on some systems, and @code{DEL} on
|
|
901 others) sends this signal. When the argument @var{current-group} is
|
|
902 non-@code{nil}, you can think of this function as ``typing @kbd{C-c}''
|
|
903 on the terminal by which Emacs talks to the subprocess.
|
|
904 @end defun
|
|
905
|
60270
|
906 @defun kill-process &optional process current-group
|
|
907 This function kills the process @var{process} by sending the
|
6558
|
908 signal @code{SIGKILL}. This signal kills the subprocess immediately,
|
|
909 and cannot be handled by the subprocess.
|
|
910 @end defun
|
|
911
|
60270
|
912 @defun quit-process &optional process current-group
|
6558
|
913 This function sends the signal @code{SIGQUIT} to the process
|
60270
|
914 @var{process}. This signal is the one sent by the ``quit
|
6558
|
915 character'' (usually @kbd{C-b} or @kbd{C-\}) when you are not inside
|
|
916 Emacs.
|
|
917 @end defun
|
|
918
|
60270
|
919 @defun stop-process &optional process current-group
|
|
920 This function stops the process @var{process} by sending the
|
6558
|
921 signal @code{SIGTSTP}. Use @code{continue-process} to resume its
|
|
922 execution.
|
|
923
|
21682
|
924 Outside of Emacs, on systems with job control, the ``stop character''
|
21007
|
925 (usually @kbd{C-z}) normally sends this signal. When
|
|
926 @var{current-group} is non-@code{nil}, you can think of this function as
|
|
927 ``typing @kbd{C-z}'' on the terminal Emacs uses to communicate with the
|
|
928 subprocess.
|
6558
|
929 @end defun
|
|
930
|
60270
|
931 @defun continue-process &optional process current-group
|
6558
|
932 This function resumes execution of the process @var{process} by sending
|
60270
|
933 it the signal @code{SIGCONT}. This presumes that @var{process} was
|
6558
|
934 stopped previously.
|
|
935 @end defun
|
|
936
|
|
937 @c Emacs 19 feature
|
52542
|
938 @defun signal-process process signal
|
|
939 This function sends a signal to process @var{process}. The argument
|
|
940 @var{signal} specifies which signal to send; it should be an integer.
|
|
941
|
60270
|
942 The @var{process} argument can be a system process @acronym{ID}; that
|
|
943 allows you to send signals to processes that are not children of
|
|
944 Emacs.
|
6558
|
945 @end defun
|
|
946
|
|
947 @node Output from Processes
|
|
948 @section Receiving Output from Processes
|
|
949 @cindex process output
|
|
950 @cindex output from processes
|
|
951
|
|
952 There are two ways to receive the output that a subprocess writes to
|
|
953 its standard output stream. The output can be inserted in a buffer,
|
|
954 which is called the associated buffer of the process, or a function
|
9009
|
955 called the @dfn{filter function} can be called to act on the output. If
|
|
956 the process has no buffer and no filter function, its output is
|
|
957 discarded.
|
49600
|
958
|
46340
|
959 When a subprocess terminates, Emacs reads any pending output,
|
|
960 then stops reading output from that subprocess. Therefore, if the
|
|
961 subprocess has children that are still live and still producing
|
|
962 output, Emacs won't receive that output.
|
|
963
|
22138
|
964 Output from a subprocess can arrive only while Emacs is waiting: when
|
|
965 reading terminal input, in @code{sit-for} and @code{sleep-for}
|
|
966 (@pxref{Waiting}), and in @code{accept-process-output} (@pxref{Accepting
|
|
967 Output}). This minimizes the problem of timing errors that usually
|
|
968 plague parallel programming. For example, you can safely create a
|
|
969 process and only then specify its buffer or filter function; no output
|
|
970 can arrive before you finish, if the code in between does not call any
|
|
971 primitive that waits.
|
|
972
|
56704
|
973 @defvar process-adaptive-read-buffering
|
|
974 On some systems, when Emacs reads the output from a subprocess, the
|
|
975 output data is read in very small blocks, potentially resulting in
|
63560
|
976 very poor performance. This behavior can be remedied to some extent
|
56704
|
977 by setting the variable @var{process-adaptive-read-buffering} to a
|
58405
|
978 non-@code{nil} value (the default), as it will automatically delay reading
|
56704
|
979 from such processes, thus allowing them to produce more output before
|
|
980 Emacs tries to read it.
|
|
981 @end defvar
|
|
982
|
27259
|
983 It is impossible to separate the standard output and standard error
|
|
984 streams of the subprocess, because Emacs normally spawns the subprocess
|
|
985 inside a pseudo-TTY, and a pseudo-TTY has only one output channel. If
|
|
986 you want to keep the output to those streams separate, you should
|
54916
|
987 redirect one of them to a file---for example, by using an appropriate
|
27259
|
988 shell command.
|
|
989
|
6558
|
990 @menu
|
51993
|
991 * Process Buffers:: If no filter, output is put in a buffer.
|
|
992 * Filter Functions:: Filter functions accept output from the process.
|
51994
|
993 * Decoding Output:: Filters can get unibyte or multibyte strings.
|
51993
|
994 * Accepting Output:: How to wait until process output arrives.
|
6558
|
995 @end menu
|
|
996
|
|
997 @node Process Buffers
|
|
998 @subsection Process Buffers
|
|
999
|
|
1000 A process can (and usually does) have an @dfn{associated buffer},
|
|
1001 which is an ordinary Emacs buffer that is used for two purposes: storing
|
|
1002 the output from the process, and deciding when to kill the process. You
|
|
1003 can also use the buffer to identify a process to operate on, since in
|
|
1004 normal practice only one process is associated with any given buffer.
|
|
1005 Many applications of processes also use the buffer for editing input to
|
|
1006 be sent to the process, but this is not built into Emacs Lisp.
|
|
1007
|
|
1008 Unless the process has a filter function (@pxref{Filter Functions}),
|
|
1009 its output is inserted in the associated buffer. The position to insert
|
9009
|
1010 the output is determined by the @code{process-mark}, which is then
|
|
1011 updated to point to the end of the text just inserted. Usually, but not
|
|
1012 always, the @code{process-mark} is at the end of the buffer.
|
6558
|
1013
|
|
1014 @defun process-buffer process
|
|
1015 This function returns the associated buffer of the process
|
|
1016 @var{process}.
|
|
1017
|
|
1018 @smallexample
|
|
1019 @group
|
|
1020 (process-buffer (get-process "shell"))
|
|
1021 @result{} #<buffer *shell*>
|
|
1022 @end group
|
|
1023 @end smallexample
|
|
1024 @end defun
|
|
1025
|
|
1026 @defun process-mark process
|
|
1027 This function returns the process marker for @var{process}, which is the
|
|
1028 marker that says where to insert output from the process.
|
|
1029
|
|
1030 If @var{process} does not have a buffer, @code{process-mark} returns a
|
|
1031 marker that points nowhere.
|
|
1032
|
|
1033 Insertion of process output in a buffer uses this marker to decide where
|
|
1034 to insert, and updates it to point after the inserted text. That is why
|
|
1035 successive batches of output are inserted consecutively.
|
|
1036
|
|
1037 Filter functions normally should use this marker in the same fashion
|
|
1038 as is done by direct insertion of output in the buffer. A good
|
|
1039 example of a filter function that uses @code{process-mark} is found at
|
|
1040 the end of the following section.
|
|
1041
|
|
1042 When the user is expected to enter input in the process buffer for
|
21007
|
1043 transmission to the process, the process marker separates the new input
|
|
1044 from previous output.
|
6558
|
1045 @end defun
|
|
1046
|
|
1047 @defun set-process-buffer process buffer
|
|
1048 This function sets the buffer associated with @var{process} to
|
|
1049 @var{buffer}. If @var{buffer} is @code{nil}, the process becomes
|
|
1050 associated with no buffer.
|
|
1051 @end defun
|
|
1052
|
|
1053 @defun get-buffer-process buffer-or-name
|
44345
|
1054 This function returns a nondeleted process associated with the buffer
|
|
1055 specified by @var{buffer-or-name}. If there are several processes
|
|
1056 associated with it, this function chooses one (currently, the one most
|
|
1057 recently created, but don't count on that). Deletion of a process
|
|
1058 (see @code{delete-process}) makes it ineligible for this function to
|
|
1059 return.
|
|
1060
|
|
1061 It is usually a bad idea to have more than one process associated with
|
|
1062 the same buffer.
|
6558
|
1063
|
|
1064 @smallexample
|
|
1065 @group
|
|
1066 (get-buffer-process "*shell*")
|
|
1067 @result{} #<process shell>
|
|
1068 @end group
|
|
1069 @end smallexample
|
|
1070
|
|
1071 Killing the process's buffer deletes the process, which kills the
|
|
1072 subprocess with a @code{SIGHUP} signal (@pxref{Signals to Processes}).
|
|
1073 @end defun
|
|
1074
|
|
1075 @node Filter Functions
|
|
1076 @subsection Process Filter Functions
|
|
1077 @cindex filter function
|
|
1078 @cindex process filter
|
|
1079
|
|
1080 A process @dfn{filter function} is a function that receives the
|
|
1081 standard output from the associated process. If a process has a filter,
|
9009
|
1082 then @emph{all} output from that process is passed to the filter. The
|
|
1083 process buffer is used directly for output from the process only when
|
|
1084 there is no filter.
|
6558
|
1085
|
22138
|
1086 The filter function can only be called when Emacs is waiting for
|
|
1087 something, because process output arrives only at such times. Emacs
|
|
1088 waits when reading terminal input, in @code{sit-for} and
|
|
1089 @code{sleep-for} (@pxref{Waiting}), and in @code{accept-process-output}
|
|
1090 (@pxref{Accepting Output}).
|
|
1091
|
21007
|
1092 A filter function must accept two arguments: the associated process
|
|
1093 and a string, which is output just received from it. The function is
|
|
1094 then free to do whatever it chooses with the output.
|
6558
|
1095
|
|
1096 Quitting is normally inhibited within a filter function---otherwise,
|
|
1097 the effect of typing @kbd{C-g} at command level or to quit a user
|
|
1098 command would be unpredictable. If you want to permit quitting inside a
|
|
1099 filter function, bind @code{inhibit-quit} to @code{nil}.
|
|
1100 @xref{Quitting}.
|
|
1101
|
12067
|
1102 If an error happens during execution of a filter function, it is
|
|
1103 caught automatically, so that it doesn't stop the execution of whatever
|
12125
|
1104 program was running when the filter function was started. However, if
|
12067
|
1105 @code{debug-on-error} is non-@code{nil}, the error-catching is turned
|
|
1106 off. This makes it possible to use the Lisp debugger to debug the
|
|
1107 filter function. @xref{Debugger}.
|
|
1108
|
6558
|
1109 Many filter functions sometimes or always insert the text in the
|
|
1110 process's buffer, mimicking the actions of Emacs when there is no
|
|
1111 filter. Such filter functions need to use @code{set-buffer} in order to
|
|
1112 be sure to insert in that buffer. To avoid setting the current buffer
|
21007
|
1113 semipermanently, these filter functions must save and restore the
|
|
1114 current buffer. They should also update the process marker, and in some
|
|
1115 cases update the value of point. Here is how to do these things:
|
6558
|
1116
|
|
1117 @smallexample
|
|
1118 @group
|
|
1119 (defun ordinary-insertion-filter (proc string)
|
21007
|
1120 (with-current-buffer (process-buffer proc)
|
|
1121 (let ((moving (= (point) (process-mark proc))))
|
6558
|
1122 @end group
|
|
1123 @group
|
21007
|
1124 (save-excursion
|
|
1125 ;; @r{Insert the text, advancing the process marker.}
|
|
1126 (goto-char (process-mark proc))
|
|
1127 (insert string)
|
|
1128 (set-marker (process-mark proc) (point)))
|
|
1129 (if moving (goto-char (process-mark proc))))))
|
6558
|
1130 @end group
|
|
1131 @end smallexample
|
|
1132
|
|
1133 @noindent
|
21007
|
1134 The reason to use @code{with-current-buffer}, rather than using
|
|
1135 @code{save-excursion} to save and restore the current buffer, is so as
|
|
1136 to preserve the change in point made by the second call to
|
|
1137 @code{goto-char}.
|
6558
|
1138
|
|
1139 To make the filter force the process buffer to be visible whenever new
|
|
1140 text arrives, insert the following line just before the
|
21007
|
1141 @code{with-current-buffer} construct:
|
6558
|
1142
|
|
1143 @smallexample
|
|
1144 (display-buffer (process-buffer proc))
|
|
1145 @end smallexample
|
|
1146
|
21007
|
1147 To force point to the end of the new output, no matter where it was
|
|
1148 previously, eliminate the variable @code{moving} and call
|
6558
|
1149 @code{goto-char} unconditionally.
|
|
1150
|
21007
|
1151 In earlier Emacs versions, every filter function that did regular
|
|
1152 expression searching or matching had to explicitly save and restore the
|
|
1153 match data. Now Emacs does this automatically for filter functions;
|
|
1154 they never need to do it explicitly. @xref{Match Data}.
|
6558
|
1155
|
|
1156 A filter function that writes the output into the buffer of the
|
12098
|
1157 process should check whether the buffer is still alive. If it tries to
|
21007
|
1158 insert into a dead buffer, it will get an error. The expression
|
|
1159 @code{(buffer-name (process-buffer @var{process}))} returns @code{nil}
|
|
1160 if the buffer is dead.
|
6558
|
1161
|
|
1162 The output to the function may come in chunks of any size. A program
|
21007
|
1163 that produces the same output twice in a row may send it as one batch of
|
|
1164 200 characters one time, and five batches of 40 characters the next. If
|
|
1165 the filter looks for certain text strings in the subprocess output, make
|
|
1166 sure to handle the case where one of these strings is split across two
|
|
1167 or more batches of output.
|
6558
|
1168
|
|
1169 @defun set-process-filter process filter
|
|
1170 This function gives @var{process} the filter function @var{filter}. If
|
|
1171 @var{filter} is @code{nil}, it gives the process no filter.
|
|
1172 @end defun
|
|
1173
|
|
1174 @defun process-filter process
|
|
1175 This function returns the filter function of @var{process}, or @code{nil}
|
|
1176 if it has none.
|
|
1177 @end defun
|
|
1178
|
|
1179 Here is an example of use of a filter function:
|
|
1180
|
|
1181 @smallexample
|
|
1182 @group
|
|
1183 (defun keep-output (process output)
|
|
1184 (setq kept (cons output kept)))
|
|
1185 @result{} keep-output
|
|
1186 @end group
|
|
1187 @group
|
|
1188 (setq kept nil)
|
|
1189 @result{} nil
|
|
1190 @end group
|
|
1191 @group
|
|
1192 (set-process-filter (get-process "shell") 'keep-output)
|
|
1193 @result{} keep-output
|
|
1194 @end group
|
|
1195 @group
|
|
1196 (process-send-string "shell" "ls ~/other\n")
|
|
1197 @result{} nil
|
|
1198 kept
|
|
1199 @result{} ("lewis@@slug[8] % "
|
|
1200 @end group
|
|
1201 @group
|
|
1202 "FINAL-W87-SHORT.MSS backup.otl kolstad.mss~
|
|
1203 address.txt backup.psf kolstad.psf
|
|
1204 backup.bib~ david.mss resume-Dec-86.mss~
|
|
1205 backup.err david.psf resume-Dec.psf
|
|
1206 backup.mss dland syllabus.mss
|
|
1207 "
|
|
1208 "#backups.mss# backup.mss~ kolstad.mss
|
|
1209 ")
|
|
1210 @end group
|
|
1211 @end smallexample
|
|
1212
|
|
1213 @ignore @c The code in this example doesn't show the right way to do things.
|
|
1214 Here is another, more realistic example, which demonstrates how to use
|
|
1215 the process mark to do insertion in the same fashion as is done when
|
|
1216 there is no filter function:
|
|
1217
|
|
1218 @smallexample
|
|
1219 @group
|
|
1220 ;; @r{Insert input in the buffer specified by @code{my-shell-buffer}}
|
|
1221 ;; @r{and make sure that buffer is shown in some window.}
|
|
1222 (defun my-process-filter (proc str)
|
21007
|
1223 (let ((cur (selected-window))
|
|
1224 (pop-up-windows t))
|
|
1225 (pop-to-buffer my-shell-buffer)
|
6558
|
1226 @end group
|
|
1227 @group
|
21007
|
1228 (goto-char (point-max))
|
|
1229 (insert str)
|
|
1230 (set-marker (process-mark proc) (point-max))
|
|
1231 (select-window cur)))
|
6558
|
1232 @end group
|
|
1233 @end smallexample
|
|
1234 @end ignore
|
|
1235
|
51993
|
1236 @node Decoding Output
|
|
1237 @subsection Decoding Process Output
|
|
1238
|
|
1239 When Emacs writes process output directly into a multibyte buffer,
|
|
1240 it decodes the output according to the process output coding system.
|
|
1241 If the coding system is @code{raw-text} or @code{no-conversion}, Emacs
|
|
1242 converts the unibyte output to multibyte using
|
60270
|
1243 @code{string-to-multibyte}, and inserts the resulting multibyte text.
|
51993
|
1244
|
|
1245 You can use @code{set-process-coding-system} to specify which coding
|
|
1246 system to use (@pxref{Process Information}). Otherwise, the coding
|
|
1247 system comes from @code{coding-system-for-read}, if that is
|
|
1248 non-@code{nil}; or else from the defaulting mechanism (@pxref{Default
|
|
1249 Coding Systems}).
|
|
1250
|
|
1251 @strong{Warning:} Coding systems such as @code{undecided} which
|
|
1252 determine the coding system from the data do not work entirely
|
|
1253 reliably with asynchronous subprocess output. This is because Emacs
|
|
1254 has to process asynchronous subprocess output in batches, as it
|
|
1255 arrives. Emacs must try to detect the proper coding system from one
|
|
1256 batch at a time, and this does not always work. Therefore, if at all
|
|
1257 possible, specify a coding system that determines both the character
|
|
1258 code conversion and the end of line conversion---that is, one like
|
|
1259 @code{latin-1-unix}, rather than @code{undecided} or @code{latin-1}.
|
|
1260
|
|
1261 @cindex filter multibyte flag, of process
|
|
1262 @cindex process filter multibyte flag
|
|
1263 When Emacs calls a process filter function, it provides the process
|
|
1264 output as a multibyte string or as a unibyte string according to the
|
|
1265 process's filter multibyte flag. If the flag is non-@code{nil}, Emacs
|
|
1266 decodes the output according to the process output coding system to
|
|
1267 produce a multibyte string, and passes that to the process. If the
|
|
1268 flag is @code{nil}, Emacs puts the output into a unibyte string, with
|
|
1269 no decoding, and passes that.
|
|
1270
|
|
1271 When you create a process, the filter multibyte flag takes its
|
|
1272 initial value from @code{default-enable-multibyte-characters}. If you
|
|
1273 want to change the flag later on, use
|
|
1274 @code{set-process-filter-multibyte}.
|
|
1275
|
|
1276 @defun set-process-filter-multibyte process multibyte
|
|
1277 This function sets the filter multibyte flag of @var{process}
|
|
1278 to @var{multibyte}.
|
|
1279 @end defun
|
|
1280
|
|
1281 @defun process-filter-multibyte-p process
|
|
1282 This function returns the filter multibyte flag of @var{process}.
|
|
1283 @end defun
|
|
1284
|
6558
|
1285 @node Accepting Output
|
|
1286 @subsection Accepting Output from Processes
|
|
1287
|
|
1288 Output from asynchronous subprocesses normally arrives only while
|
|
1289 Emacs is waiting for some sort of external event, such as elapsed time
|
|
1290 or terminal input. Occasionally it is useful in a Lisp program to
|
|
1291 explicitly permit output to arrive at a specific point, or even to wait
|
|
1292 until output arrives from a process.
|
|
1293
|
56703
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1294 @defun accept-process-output &optional process seconds millisec just-this-one
|
6558
|
1295 This function allows Emacs to read pending output from processes. The
|
|
1296 output is inserted in the associated buffers or given to their filter
|
|
1297 functions. If @var{process} is non-@code{nil} then this function does
|
|
1298 not return until some output has been received from @var{process}.
|
|
1299
|
|
1300 @c Emacs 19 feature
|
|
1301 The arguments @var{seconds} and @var{millisec} let you specify timeout
|
|
1302 periods. The former specifies a period measured in seconds and the
|
|
1303 latter specifies one measured in milliseconds. The two time periods
|
|
1304 thus specified are added together, and @code{accept-process-output}
|
|
1305 returns after that much time whether or not there has been any
|
|
1306 subprocess output.
|
|
1307
|
12098
|
1308 The argument @var{seconds} need not be an integer. If it is a floating
|
|
1309 point number, this function waits for a fractional number of seconds.
|
|
1310 Some systems support only a whole number of seconds; on these systems,
|
22252
|
1311 @var{seconds} is rounded down.
|
12098
|
1312
|
6558
|
1313 Not all operating systems support waiting periods other than multiples
|
|
1314 of a second; on those that do not, you get an error if you specify
|
|
1315 nonzero @var{millisec}.
|
|
1316
|
59996
|
1317 @c Emacs 22.1 feature
|
56703
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1318 If @var{process} is a process, and the argument @var{just-this-one} is
|
58405
|
1319 non-@code{nil}, only output from that process is handled, suspending output
|
56703
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1320 from other processes until some output has been received from that
|
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1321 process or the timeout expires. If @var{just-this-one} is an integer,
|
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1322 also inhibit running timers. This feature is generally not
|
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1323 recommended, but may be necessary for specific applications, such as
|
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1324 speech synthesis.
|
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1325
|
6558
|
1326 The function @code{accept-process-output} returns non-@code{nil} if it
|
|
1327 did get some output, or @code{nil} if the timeout expired before output
|
|
1328 arrived.
|
|
1329 @end defun
|
|
1330
|
|
1331 @node Sentinels
|
|
1332 @section Sentinels: Detecting Process Status Changes
|
|
1333 @cindex process sentinel
|
|
1334 @cindex sentinel
|
|
1335
|
|
1336 A @dfn{process sentinel} is a function that is called whenever the
|
|
1337 associated process changes status for any reason, including signals
|
|
1338 (whether sent by Emacs or caused by the process's own actions) that
|
44345
|
1339 terminate, stop, or continue the process. The process sentinel is
|
|
1340 also called if the process exits. The sentinel receives two
|
|
1341 arguments: the process for which the event occurred, and a string
|
|
1342 describing the type of event.
|
6558
|
1343
|
|
1344 The string describing the event looks like one of the following:
|
|
1345
|
|
1346 @itemize @bullet
|
49600
|
1347 @item
|
6558
|
1348 @code{"finished\n"}.
|
|
1349
|
|
1350 @item
|
|
1351 @code{"exited abnormally with code @var{exitcode}\n"}.
|
|
1352
|
|
1353 @item
|
|
1354 @code{"@var{name-of-signal}\n"}.
|
|
1355
|
|
1356 @item
|
|
1357 @code{"@var{name-of-signal} (core dumped)\n"}.
|
|
1358 @end itemize
|
|
1359
|
44345
|
1360 A sentinel runs only while Emacs is waiting (e.g., for terminal
|
|
1361 input, or for time to elapse, or for process output). This avoids the
|
|
1362 timing errors that could result from running them at random places in
|
|
1363 the middle of other Lisp programs. A program can wait, so that
|
|
1364 sentinels will run, by calling @code{sit-for} or @code{sleep-for}
|
9009
|
1365 (@pxref{Waiting}), or @code{accept-process-output} (@pxref{Accepting
|
22138
|
1366 Output}). Emacs also allows sentinels to run when the command loop is
|
44345
|
1367 reading input. @code{delete-process} calls the sentinel when it
|
|
1368 terminates a running process.
|
|
1369
|
|
1370 Emacs does not keep a queue of multiple reasons to call the sentinel
|
|
1371 of one process; it records just the current status and the fact that
|
|
1372 there has been a change. Therefore two changes in status, coming in
|
|
1373 quick succession, can call the sentinel just once. However, process
|
|
1374 termination will always run the sentinel exactly once. This is
|
|
1375 because the process status can't change again after termination.
|
6558
|
1376
|
|
1377 Quitting is normally inhibited within a sentinel---otherwise, the
|
|
1378 effect of typing @kbd{C-g} at command level or to quit a user command
|
|
1379 would be unpredictable. If you want to permit quitting inside a
|
|
1380 sentinel, bind @code{inhibit-quit} to @code{nil}. @xref{Quitting}.
|
|
1381
|
|
1382 A sentinel that writes the output into the buffer of the process
|
12098
|
1383 should check whether the buffer is still alive. If it tries to insert
|
6558
|
1384 into a dead buffer, it will get an error. If the buffer is dead,
|
|
1385 @code{(buffer-name (process-buffer @var{process}))} returns @code{nil}.
|
|
1386
|
12067
|
1387 If an error happens during execution of a sentinel, it is caught
|
|
1388 automatically, so that it doesn't stop the execution of whatever
|
|
1389 programs was running when the sentinel was started. However, if
|
|
1390 @code{debug-on-error} is non-@code{nil}, the error-catching is turned
|
|
1391 off. This makes it possible to use the Lisp debugger to debug the
|
|
1392 sentinel. @xref{Debugger}.
|
|
1393
|
44428
|
1394 While a sentinel is running, the process sentinel is temporarily
|
|
1395 set to @code{nil} so that the sentinel won't run recursively.
|
|
1396 For this reason it is not possible for a sentinel to specify
|
|
1397 a new sentinel.
|
|
1398
|
21007
|
1399 In earlier Emacs versions, every sentinel that did regular expression
|
|
1400 searching or matching had to explicitly save and restore the match data.
|
|
1401 Now Emacs does this automatically for sentinels; they never need to do
|
|
1402 it explicitly. @xref{Match Data}.
|
12098
|
1403
|
6558
|
1404 @defun set-process-sentinel process sentinel
|
|
1405 This function associates @var{sentinel} with @var{process}. If
|
|
1406 @var{sentinel} is @code{nil}, then the process will have no sentinel.
|
|
1407 The default behavior when there is no sentinel is to insert a message in
|
|
1408 the process's buffer when the process status changes.
|
|
1409
|
44345
|
1410 Changes in process sentinel take effect immediately---if the sentinel
|
|
1411 is slated to be run but has not been called yet, and you specify a new
|
|
1412 sentinel, the eventual call to the sentinel will use the new one.
|
|
1413
|
6558
|
1414 @smallexample
|
|
1415 @group
|
|
1416 (defun msg-me (process event)
|
|
1417 (princ
|
|
1418 (format "Process: %s had the event `%s'" process event)))
|
|
1419 (set-process-sentinel (get-process "shell") 'msg-me)
|
|
1420 @result{} msg-me
|
|
1421 @end group
|
|
1422 @group
|
|
1423 (kill-process (get-process "shell"))
|
|
1424 @print{} Process: #<process shell> had the event `killed'
|
|
1425 @result{} #<process shell>
|
|
1426 @end group
|
|
1427 @end smallexample
|
|
1428 @end defun
|
|
1429
|
|
1430 @defun process-sentinel process
|
|
1431 This function returns the sentinel of @var{process}, or @code{nil} if it
|
|
1432 has none.
|
|
1433 @end defun
|
|
1434
|
|
1435 @defun waiting-for-user-input-p
|
|
1436 While a sentinel or filter function is running, this function returns
|
|
1437 non-@code{nil} if Emacs was waiting for keyboard input from the user at
|
|
1438 the time the sentinel or filter function was called, @code{nil} if it
|
|
1439 was not.
|
|
1440 @end defun
|
|
1441
|
46340
|
1442 @node Query Before Exit
|
49600
|
1443 @section Querying Before Exit
|
46340
|
1444
|
|
1445 When Emacs exits, it terminates all its subprocesses by sending them
|
60270
|
1446 the @code{SIGHUP} signal. Because subprocesses may be doing
|
46340
|
1447 valuable work, Emacs normally asks the user to confirm that it is ok
|
|
1448 to terminate them. Each process has a query flag which, if
|
|
1449 non-@code{nil}, says that Emacs should ask for confirmation before
|
|
1450 exiting and thus killing that process. The default for the query flag
|
|
1451 is @code{t}, meaning @emph{do} query.
|
|
1452
|
|
1453 @tindex process-query-on-exit-flag
|
|
1454 @defun process-query-on-exit-flag process
|
|
1455 This returns the query flag of @var{process}.
|
|
1456 @end defun
|
|
1457
|
|
1458 @tindex set-process-query-on-exit-flag
|
|
1459 @defun set-process-query-on-exit-flag process flag
|
|
1460 This function sets the query flag of @var{process} to @var{flag}. It
|
|
1461 returns @var{flag}.
|
|
1462
|
|
1463 @smallexample
|
|
1464 @group
|
|
1465 ;; @r{Don't query about the shell process}
|
|
1466 (set-process-query-on-exit-flag (get-process "shell") nil)
|
|
1467 @result{} t
|
|
1468 @end group
|
|
1469 @end smallexample
|
|
1470 @end defun
|
|
1471
|
|
1472 @defun process-kill-without-query process &optional do-query
|
|
1473 This function clears the query flag of @var{process}, so that
|
|
1474 Emacs will not query the user on account of that process.
|
|
1475
|
|
1476 Actually, the function does more than that: it returns the old value of
|
|
1477 the process's query flag, and sets the query flag to @var{do-query}.
|
|
1478 Please don't use this function to do those things any more---please
|
|
1479 use the newer, cleaner functions @code{process-query-on-exit-flag} and
|
|
1480 @code{set-process-query-on-exit-flag} in all but the simplest cases.
|
|
1481 The only way you should use @code{process-kill-without-query} nowadays
|
|
1482 is like this:
|
|
1483
|
|
1484 @smallexample
|
|
1485 @group
|
|
1486 ;; @r{Don't query about the shell process}
|
|
1487 (process-kill-without-query (get-process "shell"))
|
|
1488 @end group
|
|
1489 @end smallexample
|
|
1490 @end defun
|
|
1491
|
6558
|
1492 @node Transaction Queues
|
|
1493 @section Transaction Queues
|
|
1494 @cindex transaction queue
|
|
1495
|
21007
|
1496 You can use a @dfn{transaction queue} to communicate with a subprocess
|
|
1497 using transactions. First use @code{tq-create} to create a transaction
|
|
1498 queue communicating with a specified process. Then you can call
|
|
1499 @code{tq-enqueue} to send a transaction.
|
6558
|
1500
|
|
1501 @defun tq-create process
|
|
1502 This function creates and returns a transaction queue communicating with
|
|
1503 @var{process}. The argument @var{process} should be a subprocess
|
|
1504 capable of sending and receiving streams of bytes. It may be a child
|
9009
|
1505 process, or it may be a TCP connection to a server, possibly on another
|
6558
|
1506 machine.
|
|
1507 @end defun
|
|
1508
|
|
1509 @defun tq-enqueue queue question regexp closure fn
|
|
1510 This function sends a transaction to queue @var{queue}. Specifying the
|
|
1511 queue has the effect of specifying the subprocess to talk to.
|
|
1512
|
9009
|
1513 The argument @var{question} is the outgoing message that starts the
|
6558
|
1514 transaction. The argument @var{fn} is the function to call when the
|
|
1515 corresponding answer comes back; it is called with two arguments:
|
|
1516 @var{closure}, and the answer received.
|
|
1517
|
39426
|
1518 The argument @var{regexp} is a regular expression that should match
|
|
1519 text at the end of the entire answer, but nothing before; that's how
|
|
1520 @code{tq-enqueue} determines where the answer ends.
|
6558
|
1521
|
|
1522 The return value of @code{tq-enqueue} itself is not meaningful.
|
|
1523 @end defun
|
|
1524
|
|
1525 @defun tq-close queue
|
|
1526 Shut down transaction queue @var{queue}, waiting for all pending transactions
|
|
1527 to complete, and then terminate the connection or child process.
|
|
1528 @end defun
|
|
1529
|
|
1530 Transaction queues are implemented by means of a filter function.
|
|
1531 @xref{Filter Functions}.
|
|
1532
|
12098
|
1533 @node Network
|
|
1534 @section Network Connections
|
|
1535 @cindex network connection
|
6558
|
1536 @cindex TCP
|
52596
|
1537 @cindex UDP
|
6558
|
1538
|
52596
|
1539 Emacs Lisp programs can open stream (TCP) and datagram (UDP) network
|
|
1540 connections to other processes on the same machine or other machines.
|
|
1541 A network connection is handled by Lisp much like a subprocess, and is
|
52542
|
1542 represented by a process object. However, the process you are
|
|
1543 communicating with is not a child of the Emacs process, so it has no
|
52978
|
1544 process @acronym{ID}, and you can't kill it or send it signals. All you
|
52542
|
1545 can do is send and receive data. @code{delete-process} closes the
|
|
1546 connection, but does not kill the program at the other end; that
|
|
1547 program must decide what to do about closure of the connection.
|
|
1548
|
|
1549 Lisp programs can listen for connections by creating network
|
|
1550 servers. A network server is also represented by a kind of process
|
|
1551 object, but unlike a network connection, the network server never
|
|
1552 transfers data itself. When it receives a connection request, it
|
|
1553 creates a new network connection to represent the connection just
|
|
1554 made. (The network connection inherits certain information, including
|
|
1555 the process plist, from the server.) The network server then goes
|
|
1556 back to listening for more connection requests.
|
6558
|
1557
|
52818
|
1558 Network connections and servers are created by calling
|
|
1559 @code{make-network-process} with an argument list consisting of
|
|
1560 keyword/argument pairs, for example @code{:server t} to create a
|
|
1561 server process, or @code{:type 'datagram} to create a datagram
|
52830
|
1562 connection. @xref{Low-Level Network}, for details. You can also use
|
63560
|
1563 the @code{open-network-stream} function described below.
|
52818
|
1564
|
6558
|
1565 You can distinguish process objects representing network connections
|
52542
|
1566 and servers from those representing subprocesses with the
|
|
1567 @code{process-status} function. The possible status values for
|
|
1568 network connections are @code{open}, @code{closed}, @code{connect},
|
|
1569 and @code{failed}. For a network server, the status is always
|
|
1570 @code{listen}. None of those values is possible for a real
|
|
1571 subprocess. @xref{Process Information}.
|
|
1572
|
54265
|
1573 You can stop and resume operation of a network process by calling
|
52542
|
1574 @code{stop-process} and @code{continue-process}. For a server
|
|
1575 process, being stopped means not accepting new connections. (Up to 5
|
52596
|
1576 connection requests will be queued for when you resume the server; you
|
|
1577 can increase this limit, unless it is imposed by the operating
|
64720
|
1578 system.) For a network stream connection, being stopped means not
|
52596
|
1579 processing input (any arriving input waits until you resume the
|
52695
|
1580 connection). For a datagram connection, some number of packets may be
|
|
1581 queued but input may be lost. You can use the function
|
|
1582 @code{process-command} to determine whether a network connection or
|
|
1583 server is stopped; a non-@code{nil} value means yes.
|
6558
|
1584
|
|
1585 @defun open-network-stream name buffer-or-name host service
|
52542
|
1586 This function opens a TCP connection, and returns a process object
|
|
1587 that represents the connection.
|
6558
|
1588
|
|
1589 The @var{name} argument specifies the name for the process object. It
|
|
1590 is modified as necessary to make it unique.
|
|
1591
|
|
1592 The @var{buffer-or-name} argument is the buffer to associate with the
|
|
1593 connection. Output from the connection is inserted in the buffer,
|
|
1594 unless you specify a filter function to handle the output. If
|
|
1595 @var{buffer-or-name} is @code{nil}, it means that the connection is not
|
|
1596 associated with any buffer.
|
|
1597
|
|
1598 The arguments @var{host} and @var{service} specify where to connect to;
|
|
1599 @var{host} is the host name (a string), and @var{service} is the name of
|
|
1600 a defined network service (a string) or a port number (an integer).
|
|
1601 @end defun
|
52401
|
1602
|
52542
|
1603 @defun process-contact process &optional key
|
|
1604 This function returns information about how a network process was set
|
|
1605 up. For a connection, when @var{key} is @code{nil}, it returns
|
|
1606 @code{(@var{hostname} @var{service})} which specifies what you
|
|
1607 connected to.
|
|
1608
|
|
1609 If @var{key} is @code{t}, the value is the complete status information
|
|
1610 for the connection or server; that is, the list of keywords and values
|
|
1611 specified in @code{make-network-process}, except that some of the
|
|
1612 values represent the current status instead of what you specified:
|
|
1613
|
|
1614 @table @code
|
|
1615 @item :buffer
|
|
1616 The associated value is the process buffer.
|
|
1617 @item :filter
|
|
1618 The associated value is the process filter function.
|
|
1619 @item :sentinel
|
52596
|
1620 The associated value is the process sentinel function.
|
52542
|
1621 @item :remote
|
|
1622 In a connection, this is the address in internal format of the remote peer.
|
|
1623 @item :local
|
|
1624 The local address, in internal format.
|
|
1625 @item :service
|
|
1626 In a server, if you specified @code{t} for @var{service},
|
|
1627 this value is the actual port number.
|
|
1628 @end table
|
|
1629
|
|
1630 @code{:local} and @code{:remote} are included even if they were not
|
|
1631 specified explicitly in @code{make-network-process}.
|
|
1632
|
|
1633 If @var{key} is a keyword, the function returns the value corresponding
|
|
1634 to that keyword.
|
|
1635
|
|
1636 For an ordinary child process, this function always returns @code{t}.
|
|
1637 @end defun
|
|
1638
|
|
1639 @node Network Servers
|
|
1640 @section Network Servers
|
|
1641
|
|
1642 You create a server by calling @code{make-network-process} with
|
|
1643 @code{:server t}. The server will listen for connection requests from
|
|
1644 clients. When it accepts a client connection request, that creates a
|
|
1645 new network connection, itself a process object, with the following
|
|
1646 parameters:
|
|
1647
|
|
1648 @itemize @bullet
|
|
1649 @item
|
|
1650 The connection's process name is constructed by concatenating the
|
|
1651 server process' @var{name} with a client identification string. The
|
|
1652 client identification string for an IPv4 connection looks like
|
|
1653 @samp{<@var{a}.@var{b}.@var{c}.@var{d}:@var{p}>}. Otherwise, it is a
|
52596
|
1654 unique number in brackets, as in @samp{<@var{nnn}>}. The number
|
52542
|
1655 is unique for each connection in the Emacs session.
|
|
1656
|
|
1657 @item
|
|
1658 If the server's filter is non-@code{nil}, the connection process does
|
52596
|
1659 not get a separate process buffer; otherwise, Emacs creates a new
|
52542
|
1660 buffer for the purpose. The buffer name is the server's buffer name
|
|
1661 or process name, concatenated with the client identification string.
|
|
1662
|
|
1663 The server's process buffer value is never used directly by Emacs, but
|
|
1664 it is passed to the log function, which can log connections by
|
|
1665 inserting text there.
|
|
1666
|
|
1667 @item
|
|
1668 The communication type and the process filter and sentinel are
|
|
1669 inherited from those of the server. The server never directly
|
|
1670 uses its filter and sentinel; their sole purpose is to initialize
|
|
1671 connections made to the server.
|
|
1672
|
|
1673 @item
|
|
1674 The connection's process contact info is set according to the client's
|
|
1675 addressing information (typically an IP address and a port number).
|
|
1676 This information is associated with the @code{process-contact}
|
|
1677 keywords @code{:host}, @code{:service}, @code{:remote}.
|
|
1678
|
|
1679 @item
|
|
1680 The connection's local address is set up according to the port
|
|
1681 number used for the connection.
|
|
1682
|
|
1683 @item
|
|
1684 The client process' plist is initialized from the server's plist.
|
|
1685 @end itemize
|
|
1686
|
|
1687 @node Datagrams
|
56703
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1688 @section Datagrams
|
52542
|
1689 @cindex datagrams
|
|
1690
|
54265
|
1691 A datagram connection communicates with individual packets rather
|
|
1692 than streams of data. Each call to @code{process-send} sends one
|
|
1693 datagram packet (@pxref{Input to Processes}), and each datagram
|
|
1694 received results in one call to the filter function.
|
52542
|
1695
|
|
1696 The datagram connection doesn't have to talk with the same remote
|
|
1697 peer all the time. It has a @dfn{remote peer address} which specifies
|
|
1698 where to send datagrams to. Each time an incoming datagram is passed
|
|
1699 to the filter function, the peer address is set to the address that
|
|
1700 datagram came from; that way, if the filter function sends a datagram,
|
|
1701 it will go back to that place. You can specify the remote peer
|
|
1702 address when you create the datagram connection using the
|
|
1703 @code{:remote} keyword. You can change it later on by calling
|
|
1704 @code{set-process-datagram-address}.
|
|
1705
|
|
1706 @defun process-datagram-address process
|
|
1707 If @var{process} is a datagram connection or server, this function
|
|
1708 returns its remote peer address.
|
|
1709 @end defun
|
|
1710
|
|
1711 @defun set-process-datagram-address process address
|
|
1712 If @var{process} is a datagram connection or server, this function
|
|
1713 sets its remote peer address to @var{address}.
|
|
1714 @end defun
|
|
1715
|
|
1716 @node Low-Level Network
|
|
1717 @section Low-Level Network Access
|
|
1718
|
|
1719 The basic function for creating network connections and network
|
|
1720 servers is @code{make-network-process}. It can do either of those
|
|
1721 jobs, depending on the arguments you give it.
|
|
1722
|
|
1723 @defun make-network-process &rest args
|
|
1724 This function creates a network connection or server and returns the
|
|
1725 process object that represents it. The arguments @var{args} are a
|
|
1726 list of keyword/argument pairs. Omitting a keyword is always
|
|
1727 equivalent to specifying it with value @code{nil}, except for
|
52596
|
1728 @code{:coding}, @code{:filter-multibyte}, and @code{:reuseaddr}. Here
|
|
1729 are the meaningful keywords:
|
52542
|
1730
|
|
1731 @table @asis
|
62230
|
1732 @item :name @var{name}
|
52542
|
1733 Use the string @var{name} as the process name. It is modified if
|
|
1734 necessary to make it unique.
|
|
1735
|
|
1736 @item :type @var{type}
|
|
1737 Specify the communication type. A value of @code{nil} specifies a
|
|
1738 stream connection (the default); @code{datagram} specifies a datagram
|
|
1739 connection. Both connections and servers can be of either type.
|
|
1740
|
|
1741 @item :server @var{server-flag}
|
|
1742 If @var{server-flag} is non-@code{nil}, create a server. Otherwise,
|
52596
|
1743 create a connection. For a stream type server, @var{server-flag} may
|
|
1744 be an integer which then specifies the length of the queue of pending
|
|
1745 connections to the server. The default queue length is 5.
|
52542
|
1746
|
|
1747 @item :host @var{host}
|
|
1748 Specify the host to connect to. @var{host} should be a host name or
|
|
1749 internet address, as a string, or the symbol @code{local} to specify
|
|
1750 the local host. If you specify @var{host} for a server, it must
|
|
1751 specify a valid address for the local host, and only clients
|
|
1752 connecting to that address will be accepted.
|
|
1753
|
|
1754 @item :service @var{service}
|
|
1755 @var{service} specifies a port number to connect to, or, for a server,
|
|
1756 the port number to listen on. It should be a service name that
|
|
1757 translates to a port number, or an integer specifying the port number
|
|
1758 directly. For a server, it can also be @code{t}, which means to let
|
|
1759 the system select an unused port number.
|
|
1760
|
|
1761 @item :family @var{family}
|
|
1762 @var{family} specifies the address (and protocol) family for
|
|
1763 communication. @code{nil} stands for IPv4. @code{local} specifies a
|
|
1764 Unix socket, in which case @var{host} is ignored.
|
|
1765
|
|
1766 @item :local @var{local-address}
|
|
1767 For a server process, @var{local-address} is the address to listen on.
|
|
1768 It overrides @var{family}, @var{host} and @var{service}, and you
|
|
1769 may as well not specify them.
|
|
1770
|
|
1771 @item :remote @var{remote-address}
|
|
1772 For a connection, @var{remote-address} is the address to connect to.
|
|
1773 It overrides @var{family}, @var{host} and @var{service}, and you
|
|
1774 may as well not specify them.
|
|
1775
|
|
1776 For a datagram server, @var{remote-address} specifies the initial
|
|
1777 setting of the remote datagram address.
|
|
1778
|
|
1779 The format of @var{local-address} or @var{remote-address} depends on
|
|
1780 the address family:
|
|
1781
|
|
1782 @itemize -
|
|
1783 @item
|
|
1784 An IPv4 address is represented as a vector of integers @code{[@var{a}
|
|
1785 @var{b} @var{c} @var{d} @var{p}]} corresponding to numeric IP address
|
|
1786 @var{a}.@var{b}.@var{c}.@var{d} and port number @var{p}.
|
|
1787
|
|
1788 @item
|
|
1789 A local address is represented as a string which specifies the address
|
|
1790 in the local address space.
|
|
1791
|
|
1792 @item
|
|
1793 An ``unsupported family'' address is represented by a cons
|
|
1794 @code{(@var{f} . @var{av})}, where @var{f} is the family number and
|
54265
|
1795 @var{av} is a vector specifying the socket address using one element
|
|
1796 per address data byte. Do not rely on this format in portable code,
|
|
1797 as it may depend on implementation defined constants, data sizes, and
|
|
1798 data structure alignment.
|
52542
|
1799 @end itemize
|
|
1800
|
|
1801 @item :nowait @var{bool}
|
|
1802 If @var{bool} is non-@code{nil} for a stream connection, return
|
|
1803 without waiting for the connection to complete. When the connection
|
|
1804 succeeds or fails, Emacs will call the sentinel function, with a
|
|
1805 second argument matching @code{"open"} (if successful) or
|
|
1806 @code{"failed"}. The default is to block, so that
|
|
1807 @code{make-network-process} does not return until the connection
|
|
1808 has succeeded or failed.
|
|
1809
|
|
1810 @item :stop @var{stopped}
|
|
1811 Start the network connection or server in the `stopped' state if
|
|
1812 @var{stopped} is non-@code{nil}.
|
|
1813
|
|
1814 @item :buffer @var{buffer}
|
|
1815 Use @var{buffer} as the process buffer.
|
|
1816
|
|
1817 @item :coding @var{coding}
|
|
1818 Use @var{coding} as the coding system for this process. To specify
|
|
1819 different coding systems for decoding data from the connection and for
|
|
1820 encoding data sent to it, specify @code{(@var{decoding} .
|
|
1821 @var{encoding})} for @var{coding}.
|
|
1822
|
|
1823 If you don't specify this keyword at all, the default
|
52596
|
1824 is to determine the coding systems from the data.
|
52542
|
1825
|
|
1826 @item :noquery @var{query-flag}
|
63560
|
1827 Initialize the process query flag to @var{query-flag}.
|
|
1828 @xref{Query Before Exit}.
|
52542
|
1829
|
|
1830 @item :filter @var{filter}
|
|
1831 Initialize the process filter to @var{filter}.
|
|
1832
|
|
1833 @item :filter-multibyte @var{bool}
|
|
1834 If @var{bool} is non-@code{nil}, strings given to the process filter
|
|
1835 are multibyte, otherwise they are unibyte. If you don't specify this
|
|
1836 keyword at all, the default is that the strings are multibyte if
|
|
1837 @code{default-enable-multibyte-characters} is non-@code{nil}.
|
|
1838
|
|
1839 @item :sentinel @var{sentinel}
|
|
1840 Initialize the process sentinel to @var{sentinel}.
|
|
1841
|
|
1842 @item :log @var{log}
|
|
1843 Initialize the log function of a server process to @var{log}. The log
|
|
1844 function is called each time the server accepts a network connection
|
|
1845 from a client. The arguments passed to the log function are
|
|
1846 @var{server}, @var{connection}, and @var{message}, where @var{server}
|
|
1847 is the server process, @var{connection} is the new process for the
|
|
1848 connection, and @var{message} is a string describing what has
|
|
1849 happened.
|
|
1850
|
|
1851 @item :plist @var{plist}
|
|
1852 Initialize the process plist to @var{plist}.
|
|
1853 @end table
|
|
1854
|
52596
|
1855 The following network options can be specified for the network
|
|
1856 process. Except for @code{:reuseaddr}, you can set or modify these
|
|
1857 options later using @code{set-network-process-option}.
|
|
1858
|
|
1859 For a server process, the options specified with
|
|
1860 @code{make-network-process} are not inherited by the client
|
|
1861 connections, so you will need to set the necessary options for each
|
|
1862 child connection as they are created.
|
|
1863
|
52598
|
1864 @table @asis
|
52596
|
1865 @item :bindtodevice @var{device-name}
|
|
1866 If @var{device-name} is a non-empty string identifying a network
|
|
1867 interface name (see @code{network-interface-list}), only handle
|
54777
|
1868 packets received on that interface. If @var{device-name} is @code{nil}
|
|
1869 (the default), handle packets received on any interface.
|
52596
|
1870
|
|
1871 Using this option may require special privileges on some systems.
|
|
1872
|
|
1873 @item :broadcast @var{broadcast-flag}
|
|
1874 If @var{broadcast-flag} is non-@code{nil} for a datagram process, the
|
|
1875 process will receive datagram packet sent to a broadcast address, and
|
|
1876 be able to send packets to a broadcast address. Ignored for a stream
|
|
1877 connection.
|
|
1878
|
|
1879 @item :dontroute @var{dontroute-flag}
|
|
1880 If @var{dontroute-flag} is non-@code{nil}, the process can only send
|
|
1881 to hosts on the same network as the local host.
|
|
1882
|
|
1883 @item :keepalive @var{keepalive-flag}
|
|
1884 If @var{keepalive-flag} is non-@code{nil} for a stream connection,
|
54004
|
1885 enable exchange of low-level keep-alive messages.
|
52596
|
1886
|
|
1887 @item :linger @var{linger-arg}
|
|
1888 If @var{linger-arg} is non-@code{nil}, wait for successful
|
|
1889 transmission of all queued packets on the connection before it is
|
|
1890 deleted (see @code{delete-process}). If @var{linger-arg} is an
|
|
1891 integer, it specifies the maximum time in seconds to wait for queued
|
|
1892 packets to be sent before closing the connection. Default is
|
|
1893 @code{nil} which means to discard unsent queued packets when the
|
|
1894 process is deleted.
|
|
1895
|
|
1896 @item :oobinline @var{oobinline-flag}
|
|
1897 If @var{oobinline-flag} is non-@code{nil} for a stream connection,
|
|
1898 receive out-of-band data in the normal data stream. Otherwise, ignore
|
|
1899 out-of-band data.
|
|
1900
|
|
1901 @item :priority @var{priority}
|
|
1902 Set the priority for packets sent on this connection to the integer
|
|
1903 @var{priority}. The interpretation of this number is protocol
|
|
1904 specific, such as setting the TOS (type of service) field on IP
|
|
1905 packets sent on this connection. It may also have system dependent
|
|
1906 effects, such as selecting a specific output queue on the network
|
|
1907 interface.
|
|
1908
|
|
1909 @item :reuseaddr @var{reuseaddr-flag}
|
|
1910 If @var{reuseaddr-flag} is non-@code{nil} (the default) for a stream
|
|
1911 server process, allow this server to reuse a specific port number (see
|
|
1912 @code{:service}) unless another process on this host is already
|
|
1913 listening on that port. If @var{reuseaddr-flag} is @code{nil}, there
|
|
1914 may be a period of time after the last use of that port (by any
|
|
1915 process on the host), where it is not possible to make a new server on
|
|
1916 that port.
|
|
1917
|
|
1918 @end table
|
|
1919
|
52542
|
1920 The original argument list, modified with the actual connection
|
54864
|
1921 information, is available via the @code{process-contact} function.
|
52542
|
1922 @end defun
|
|
1923
|
52596
|
1924 @defun set-network-process-option process option value
|
|
1925 This function sets or modifies a network option for network process
|
|
1926 @var{process}. See @code{make-network-process} for details of options
|
|
1927 @var{option} and their corresponding values @var{value}.
|
|
1928
|
|
1929 The current setting of an option is available via the
|
54864
|
1930 @code{process-contact} function.
|
52596
|
1931 @end defun
|
|
1932
|
52542
|
1933 @defun network-interface-list
|
|
1934 This function returns a list describing the network interfaces
|
|
1935 of the machine you are using. The value is an alist whose
|
|
1936 elements have the form @code{(@var{name} . @var{address})}.
|
|
1937 @var{address} has the same form as the @var{local-address}
|
|
1938 and @var{remote-address} arguments to @code{make-network-process}.
|
|
1939 @end defun
|
|
1940
|
|
1941 @defun network-interface-info ifname
|
|
1942 This function returns information about the network interface named
|
63560
|
1943 @var{ifname}. The value is a list of the form
|
|
1944 @code{(@var{addr} @var{bcast} @var{netmask} @var{hwaddr} @var{flags})}.
|
52542
|
1945
|
|
1946 @table @var
|
|
1947 @item addr
|
|
1948 The internet protocol address.
|
|
1949 @item bcast
|
|
1950 The broadcast address.
|
|
1951 @item netmask
|
|
1952 The network mask.
|
|
1953 @item hwaddr
|
|
1954 The layer 2 address (Ethernet MAC address, for instance).
|
|
1955 @item flags
|
|
1956 The current flags of the interface.
|
|
1957 @end table
|
|
1958 @end defun
|
|
1959
|
|
1960 @defun format-network-address address &optional omit-port
|
52759
|
1961 This function converts the Lisp representation of a network address to
|
52542
|
1962 a string. For example, a five-element vector @code{[@var{a} @var{b}
|
|
1963 @var{c} @var{d} @var{p}]} represents an IP address
|
|
1964 @var{a}.@var{b}.@var{c}.@var{d} and port number @var{p}.
|
|
1965 @code{format-network-address} converts that to the string
|
|
1966 @code{"@var{a}.@var{b}.@var{c}.@var{d}:@var{p}"}.
|
|
1967
|
|
1968 If @var{omit-port} is non-@code{nil}, the value does not include
|
|
1969 the port number.
|
|
1970 @end defun
|
|
1971
|
|
1972 To test for the availability of a given network feature, use
|
|
1973 @code{featurep} like this:
|
|
1974
|
|
1975 @example
|
|
1976 (featurep 'make-network-process '(@var{keyword} @var{value}))
|
56703
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
1977 @end example
|
52542
|
1978
|
|
1979 @noindent
|
52596
|
1980 The result of the first form is @code{t} if it works to specify
|
|
1981 @var{keyword} with value @var{value} in @code{make-network-process}.
|
|
1982 The result of the second form is @code{t} if @var{keyword} is
|
|
1983 supported by @code{make-network-process}. Here are some of the
|
|
1984 @var{keyword}---@var{value} pairs you can test in
|
|
1985 this way.
|
52542
|
1986
|
|
1987 @table @code
|
|
1988 @item (:nowait t)
|
|
1989 Non-@code{nil} if non-blocking connect is supported.
|
|
1990 @item (:type datagram)
|
|
1991 Non-@code{nil} if datagrams are supported.
|
|
1992 @item (:family local)
|
|
1993 Non-@code{nil} if local (aka ``UNIX domain'') sockets are supported.
|
|
1994 @item (:service t)
|
|
1995 Non-@code{nil} if the system can select the port for a server.
|
52596
|
1996 @end table
|
|
1997
|
|
1998 To test for the availability of a given network option, use
|
|
1999 @code{featurep} like this:
|
|
2000
|
|
2001 @example
|
|
2002 (featurep 'make-network-process '@var{keyword})
|
56703
fdf8546f215b
(Accepting Output): Add `just-this-one' arg to `accept-process-output'.
Kim F. Storm <storm@cua.dk>
diff
changeset
|
2003 @end example
|
52596
|
2004
|
|
2005 Here are some of the option @var{keyword}s you can test in
|
|
2006 this way.
|
|
2007
|
|
2008 @table @code
|
|
2009 @item :bindtodevice
|
|
2010 @itemx :broadcast
|
|
2011 @itemx :dontroute
|
|
2012 @itemx :keepalive
|
|
2013 @itemx :linger
|
|
2014 @itemx :oobinline
|
|
2015 @itemx :priority
|
|
2016 @itemx :reuseaddr
|
|
2017 That particular network option is supported by
|
|
2018 @code{make-network-process} and @code{set-network-process-option}.
|
52542
|
2019 @end table
|
|
2020
|
63542
|
2021 @node Byte Packing
|
|
2022 @section Packing and Unpacking Byte Arrays
|
|
2023
|
|
2024 This section describes how to pack and unpack arrays of bytes,
|
63563
|
2025 usually for binary network protocols. These functions convert byte arrays
|
|
2026 to alists, and vice versa. The byte array can be represented as a
|
63542
|
2027 unibyte string or as a vector of integers, while the alist associates
|
|
2028 symbols either with fixed-size objects or with recursive sub-alists.
|
|
2029
|
|
2030 @cindex serializing
|
|
2031 @cindex deserializing
|
|
2032 @cindex packing
|
|
2033 @cindex unpacking
|
|
2034 Conversion from byte arrays to nested alists is also known as
|
|
2035 @dfn{deserializing} or @dfn{unpacking}, while going in the opposite
|
|
2036 direction is also known as @dfn{serializing} or @dfn{packing}.
|
|
2037
|
|
2038 @menu
|
|
2039 * Bindat Spec:: Describing data layout.
|
|
2040 * Bindat Functions:: Doing the unpacking and packing.
|
|
2041 * Bindat Examples:: Samples of what bindat.el can do for you!
|
|
2042 @end menu
|
|
2043
|
|
2044 @node Bindat Spec
|
|
2045 @subsection Describing Data Layout
|
|
2046
|
|
2047 To control unpacking and packing, you write a @dfn{data layout
|
|
2048 specification}, a special nested list describing named and typed
|
63568
|
2049 @dfn{fields}. This specification controls length of each field to be
|
63542
|
2050 processed, and how to pack or unpack it.
|
|
2051
|
|
2052 @cindex endianness
|
|
2053 @cindex big endian
|
|
2054 @cindex little endian
|
|
2055 @cindex network byte ordering
|
|
2056 A field's @dfn{type} describes the size (in bytes) of the object
|
|
2057 that the field represents and, in the case of multibyte fields, how
|
63560
|
2058 the bytes are ordered within the field. The two possible orderings
|
63542
|
2059 are ``big endian'' (also known as ``network byte ordering'') and
|
|
2060 ``little endian''. For instance, the number @code{#x23cd} (decimal
|
|
2061 9165) in big endian would be the two bytes @code{#x23} @code{#xcd};
|
|
2062 and in little endian, @code{#xcd} @code{#x23}. Here are the possible
|
|
2063 type values:
|
|
2064
|
|
2065 @table @code
|
|
2066 @item u8
|
|
2067 @itemx byte
|
|
2068 Unsigned byte, with length 1.
|
|
2069
|
|
2070 @item u16
|
|
2071 @itemx word
|
|
2072 @itemx short
|
|
2073 Unsigned integer in network byte order, with length 2.
|
|
2074
|
|
2075 @item u24
|
|
2076 Unsigned integer in network byte order, with length 3.
|
|
2077
|
|
2078 @item u32
|
|
2079 @itemx dword
|
|
2080 @itemx long
|
|
2081 Unsigned integer in network byte order, with length 4.
|
|
2082 Note: These values may be limited by Emacs' integer implementation limits.
|
|
2083
|
|
2084 @item u16r
|
|
2085 @itemx u24r
|
|
2086 @itemx u32r
|
|
2087 Unsigned integer in little endian order, with length 2, 3 and 4, respectively.
|
|
2088
|
|
2089 @item str @var{len}
|
|
2090 String of length @var{len}.
|
|
2091
|
|
2092 @item strz @var{len}
|
|
2093 Zero-terminated string of length @var{len}.
|
|
2094
|
|
2095 @item vec @var{len}
|
|
2096 Vector of @var{len} bytes.
|
|
2097
|
|
2098 @item ip
|
|
2099 Four-byte vector representing an Internet address. For example:
|
|
2100 @code{[127 0 0 1]} for localhost.
|
|
2101
|
|
2102 @item bits @var{len}
|
|
2103 List of set bits in @var{len} bytes. The bytes are taken in big
|
|
2104 endian order and the bits are numbered starting with @code{8 *
|
63560
|
2105 @var{len} @minus{} 1} and ending with zero. For example: @code{bits
|
63542
|
2106 2} unpacks @code{#x28} @code{#x1c} to @code{(2 3 4 11 13)} and
|
|
2107 @code{#x1c} @code{#x28} to @code{(3 5 10 11 12)}.
|
|
2108
|
|
2109 @item (eval @var{form})
|
|
2110 @var{form} is a Lisp expression evaluated at the moment the field is
|
|
2111 unpacked or packed. The result of the evaluation should be one of the
|
|
2112 above-listed type specifications.
|
|
2113 @end table
|
|
2114
|
|
2115 A field specification generally has the form @code{([@var{name}]
|
|
2116 @var{handler})}. The square braces indicate that @var{name} is
|
|
2117 optional. (Don't use names that are symbols meaningful as type
|
|
2118 specifications (above) or handler specifications (below), since that
|
|
2119 would be ambiguous.) @var{name} can be a symbol or the expression
|
|
2120 @code{(eval @var{form})}, in which case @var{form} should evaluate to
|
|
2121 a symbol.
|
|
2122
|
|
2123 @var{handler} describes how to unpack or pack the field and can be one
|
|
2124 of the following:
|
|
2125
|
|
2126 @table @code
|
|
2127 @item @var{type}
|
|
2128 Unpack/pack this field according to the type specification @var{type}.
|
|
2129
|
|
2130 @item eval @var{form}
|
|
2131 Evaluate @var{form}, a Lisp expression, for side-effect only. If the
|
|
2132 field name is specified, the value is bound to that field name.
|
|
2133 @var{form} can access and update these dynamically bound variables:
|
|
2134
|
|
2135 @table @code
|
|
2136 @item raw-data
|
|
2137 The data as a byte array.
|
|
2138
|
|
2139 @item pos
|
|
2140 Current position of the unpacking or packing operation.
|
|
2141
|
|
2142 @item struct
|
|
2143 Alist.
|
|
2144
|
|
2145 @item last
|
|
2146 Value of the last field processed.
|
|
2147 @end table
|
|
2148
|
|
2149 @item fill @var{len}
|
|
2150 Skip @var{len} bytes. In packing, this leaves them unchanged,
|
|
2151 which normally means they remain zero. In unpacking, this means
|
|
2152 they are ignored.
|
|
2153
|
|
2154 @item align @var{len}
|
|
2155 Skip to the next multiple of @var{len} bytes.
|
|
2156
|
|
2157 @item struct @var{spec-name}
|
63560
|
2158 Process @var{spec-name} as a sub-specification. This describes a
|
63542
|
2159 structure nested within another structure.
|
|
2160
|
|
2161 @item union @var{form} (@var{tag} @var{spec})@dots{}
|
|
2162 @c ??? I don't see how one would actually use this.
|
|
2163 @c ??? what kind of expression would be useful for @var{form}?
|
|
2164 Evaluate @var{form}, a Lisp expression, find the first @var{tag}
|
|
2165 that matches it, and process its associated data layout specification
|
|
2166 @var{spec}. Matching can occur in one of three ways:
|
|
2167
|
|
2168 @itemize
|
|
2169 @item
|
|
2170 If a @var{tag} has the form @code{(eval @var{expr})}, evaluate
|
|
2171 @var{expr} with the variable @code{tag} dynamically bound to the value
|
|
2172 of @var{form}. A non-@code{nil} result indicates a match.
|
|
2173
|
|
2174 @item
|
|
2175 @var{tag} matches if it is @code{equal} to the value of @var{form}.
|
|
2176
|
|
2177 @item
|
|
2178 @var{tag} matches unconditionally if it is @code{t}.
|
|
2179 @end itemize
|
|
2180
|
|
2181 @item repeat @var{count} @var{field-spec}@dots{}
|
|
2182 @var{count} may be an integer, or a list of one element naming a
|
|
2183 previous field. For correct operation, each @var{field-spec} must
|
|
2184 include a name.
|
|
2185 @c ??? What does it MEAN?
|
|
2186 @end table
|
|
2187
|
|
2188 @node Bindat Functions
|
|
2189 @subsection Functions to Unpack and Pack Bytes
|
|
2190
|
|
2191 In the following documentation, @var{spec} refers to a data layout
|
|
2192 specification, @code{raw-data} to a byte array, and @var{struct} to an
|
|
2193 alist representing unpacked field data.
|
|
2194
|
|
2195 @defun bindat-unpack spec raw-data &optional pos
|
|
2196 This function unpacks data from the byte array @code{raw-data}
|
|
2197 according to @var{spec}. Normally this starts unpacking at the
|
|
2198 beginning of the byte array, but if @var{pos} is non-@code{nil}, it
|
|
2199 specifies a zero-based starting position to use instead.
|
|
2200
|
|
2201 The value is an alist or nested alist in which each element describes
|
|
2202 one unpacked field.
|
|
2203 @end defun
|
|
2204
|
|
2205 @defun bindat-get-field struct &rest name
|
|
2206 This function selects a field's data from the nested alist
|
|
2207 @var{struct}. Usually @var{struct} was returned by
|
|
2208 @code{bindat-unpack}. If @var{name} corresponds to just one argument,
|
|
2209 that means to extract a top-level field value. Multiple @var{name}
|
|
2210 arguments specify repeated lookup of sub-structures. An integer name
|
|
2211 acts as an array index.
|
|
2212
|
|
2213 For example, if @var{name} is @code{(a b 2 c)}, that means to find
|
|
2214 field @code{c} in the second element of subfield @code{b} of field
|
|
2215 @code{a}. (This corresponds to @code{struct.a.b[2].c} in C.)
|
|
2216 @end defun
|
|
2217
|
|
2218 @defun bindat-length spec struct
|
|
2219 @c ??? I don't understand this at all -- rms
|
|
2220 This function returns the length in bytes of @var{struct}, according
|
|
2221 to @var{spec}.
|
|
2222 @end defun
|
|
2223
|
|
2224 @defun bindat-pack spec struct &optional raw-data pos
|
|
2225 This function returns a byte array packed according to @var{spec} from
|
|
2226 the data in the alist @var{struct}. Normally it creates and fills a
|
|
2227 new byte array starting at the beginning. However, if @var{raw-data}
|
63560
|
2228 is non-@code{nil}, it specifies a pre-allocated string or vector to
|
63542
|
2229 pack into. If @var{pos} is non-@code{nil}, it specifies the starting
|
|
2230 offset for packing into @code{raw-data}.
|
|
2231
|
63560
|
2232 @c ??? Isn't this a bug? Shouldn't it always be unibyte?
|
63542
|
2233 Note: The result is a multibyte string; use @code{string-make-unibyte}
|
|
2234 on it to make it unibyte if necessary.
|
|
2235 @end defun
|
|
2236
|
|
2237 @defun bindat-ip-to-string ip
|
|
2238 Convert the Internet address vector @var{ip} to a string in the usual
|
|
2239 dotted notation.
|
|
2240
|
|
2241 @example
|
|
2242 (bindat-ip-to-string [127 0 0 1])
|
|
2243 @result{} "127.0.0.1"
|
|
2244 @end example
|
|
2245 @end defun
|
|
2246
|
|
2247 @node Bindat Examples
|
|
2248 @subsection Examples of Byte Unpacking and Packing
|
|
2249
|
|
2250 Here is a complete example of byte unpacking and packing:
|
|
2251
|
63569
bd65461db3b8
(Bindat Examples): Move @lisp to beginning of line. (Whitespace change.)
Luc Teirlinck <teirllm@auburn.edu>
diff
changeset
|
2252 @lisp
|
63542
|
2253 (defvar fcookie-index-spec
|
|
2254 '((:version u32)
|
|
2255 (:count u32)
|
|
2256 (:longest u32)
|
|
2257 (:shortest u32)
|
|
2258 (:flags u32)
|
|
2259 (:delim u8)
|
|
2260 (:ignored fill 3)
|
|
2261 (:offset repeat (:count)
|
|
2262 (:foo u32)))
|
|
2263 "Description of a fortune cookie index file's contents.")
|
|
2264
|
|
2265 (defun fcookie (cookies &optional index)
|
|
2266 "Display a random fortune cookie from file COOKIES.
|
|
2267 Optional second arg INDEX specifies the associated index
|
|
2268 filename, which is by default constructed by appending
|
|
2269 \".dat\" to COOKIES. Display cookie text in possibly
|
|
2270 new buffer \"*Fortune Cookie: BASENAME*\" where BASENAME
|
|
2271 is COOKIES without the directory part."
|
|
2272 (interactive "fCookies file: ")
|
|
2273 (let* ((info (with-temp-buffer
|
|
2274 (insert-file-contents-literally
|
|
2275 (or index (concat cookies ".dat")))
|
|
2276 (bindat-unpack fcookie-index-spec
|
|
2277 (buffer-string))))
|
|
2278 (sel (random (bindat-get-field info :count)))
|
|
2279 (beg (cdar (bindat-get-field info :offset sel)))
|
63583
|
2280 (end (or (cdar (bindat-get-field info
|
|
2281 :offset (1+ sel)))
|
63542
|
2282 (nth 7 (file-attributes cookies)))))
|
63583
|
2283 (switch-to-buffer
|
|
2284 (get-buffer-create
|
|
2285 (format "*Fortune Cookie: %s*"
|
|
2286 (file-name-nondirectory cookies))))
|
63542
|
2287 (erase-buffer)
|
63583
|
2288 (insert-file-contents-literally
|
|
2289 cookies nil beg (- end 3))))
|
63542
|
2290
|
|
2291 (defun fcookie-create-index (cookies &optional index delim)
|
|
2292 "Scan file COOKIES, and write out its index file.
|
|
2293 Optional second arg INDEX specifies the index filename,
|
|
2294 which is by default constructed by appending \".dat\" to
|
|
2295 COOKIES. Optional third arg DELIM specifies the unibyte
|
|
2296 character which, when found on a line of its own in
|
|
2297 COOKIES, indicates the border between entries."
|
|
2298 (interactive "fCookies file: ")
|
|
2299 (setq delim (or delim ?%))
|
|
2300 (let ((delim-line (format "\n%c\n" delim))
|
|
2301 (count 0)
|
|
2302 (max 0)
|
|
2303 min p q len offsets)
|
|
2304 (unless (= 3 (string-bytes delim-line))
|
|
2305 (error "Delimiter cannot be represented in one byte"))
|
|
2306 (with-temp-buffer
|
|
2307 (insert-file-contents-literally cookies)
|
|
2308 (while (and (setq p (point))
|
|
2309 (search-forward delim-line (point-max) t)
|
|
2310 (setq len (- (point) 3 p)))
|
|
2311 (setq count (1+ count)
|
|
2312 max (max max len)
|
|
2313 min (min (or min max) len)
|
|
2314 offsets (cons (1- p) offsets))))
|
|
2315 (with-temp-buffer
|
|
2316 (set-buffer-multibyte nil)
|
63583
|
2317 (insert
|
|
2318 (string-make-unibyte
|
|
2319 (bindat-pack
|
|
2320 fcookie-index-spec
|
|
2321 `((:version . 2)
|
|
2322 (:count . ,count)
|
|
2323 (:longest . ,max)
|
|
2324 (:shortest . ,min)
|
|
2325 (:flags . 0)
|
|
2326 (:delim . ,delim)
|
|
2327 (:offset . ,(mapcar (lambda (o)
|
|
2328 (list (cons :foo o)))
|
|
2329 (nreverse offsets)))))))
|
63542
|
2330 (let ((coding-system-for-write 'raw-text-unix))
|
|
2331 (write-file (or index (concat cookies ".dat")))))))
|
|
2332 @end lisp
|
|
2333
|
|
2334 Following is an example of defining and unpacking a complex structure.
|
|
2335 Consider the following C structures:
|
|
2336
|
|
2337 @example
|
|
2338 struct header @{
|
|
2339 unsigned long dest_ip;
|
|
2340 unsigned long src_ip;
|
|
2341 unsigned short dest_port;
|
|
2342 unsigned short src_port;
|
|
2343 @};
|
|
2344
|
|
2345 struct data @{
|
|
2346 unsigned char type;
|
|
2347 unsigned char opcode;
|
|
2348 unsigned long length; /* In little endian order */
|
63560
|
2349 unsigned char id[8]; /* null-terminated string */
|
63542
|
2350 unsigned char data[/* (length + 3) & ~3 */];
|
|
2351 @};
|
|
2352
|
|
2353 struct packet @{
|
|
2354 struct header header;
|
|
2355 unsigned char items;
|
|
2356 unsigned char filler[3];
|
|
2357 struct data item[/* items */];
|
|
2358
|
|
2359 @};
|
|
2360 @end example
|
|
2361
|
|
2362 The corresponding data layout specification:
|
|
2363
|
|
2364 @lisp
|
|
2365 (setq header-spec
|
|
2366 '((dest-ip ip)
|
|
2367 (src-ip ip)
|
|
2368 (dest-port u16)
|
|
2369 (src-port u16)))
|
|
2370
|
|
2371 (setq data-spec
|
|
2372 '((type u8)
|
|
2373 (opcode u8)
|
|
2374 (length u16r) ;; little endian order
|
|
2375 (id strz 8)
|
|
2376 (data vec (length))
|
|
2377 (align 4)))
|
|
2378
|
|
2379 (setq packet-spec
|
|
2380 '((header struct header-spec)
|
|
2381 (items u8)
|
|
2382 (fill 3)
|
|
2383 (item repeat (items)
|
|
2384 (struct data-spec))))
|
|
2385 @end lisp
|
|
2386
|
|
2387 A binary data representation:
|
|
2388
|
|
2389 @lisp
|
|
2390 (setq binary-data
|
|
2391 [ 192 168 1 100 192 168 1 101 01 28 21 32 2 0 0 0
|
|
2392 2 3 5 0 ?A ?B ?C ?D ?E ?F 0 0 1 2 3 4 5 0 0 0
|
|
2393 1 4 7 0 ?B ?C ?D ?E ?F ?G 0 0 6 7 8 9 10 11 12 0 ])
|
|
2394 @end lisp
|
|
2395
|
|
2396 The corresponding decoded structure:
|
|
2397
|
|
2398 @lisp
|
63583
|
2399 (setq decoded (bindat-unpack packet-spec binary-data))
|
63542
|
2400 @result{}
|
|
2401 ((header
|
|
2402 (dest-ip . [192 168 1 100])
|
|
2403 (src-ip . [192 168 1 101])
|
|
2404 (dest-port . 284)
|
|
2405 (src-port . 5408))
|
|
2406 (items . 2)
|
|
2407 (item ((data . [1 2 3 4 5])
|
|
2408 (id . "ABCDEF")
|
|
2409 (length . 5)
|
|
2410 (opcode . 3)
|
|
2411 (type . 2))
|
|
2412 ((data . [6 7 8 9 10 11 12])
|
|
2413 (id . "BCDEFG")
|
|
2414 (length . 7)
|
|
2415 (opcode . 4)
|
|
2416 (type . 1))))
|
|
2417 @end lisp
|
|
2418
|
|
2419 Fetching data from this structure:
|
|
2420
|
|
2421 @lisp
|
63583
|
2422 (bindat-get-field decoded 'item 1 'id)
|
63542
|
2423 @result{} "BCDEFG"
|
|
2424 @end lisp
|
|
2425
|
52401
|
2426 @ignore
|
|
2427 arch-tag: ba9da253-e65f-4e7f-b727-08fba0a1df7a
|
|
2428 @end ignore
|