Mercurial > emacs
annotate lispref/processes.texi @ 8414:8a8d2cdd4218
(xmenu_show): Ignore any geometry resource from the user.
author | Richard M. Stallman <rms@gnu.org> |
---|---|
date | Mon, 01 Aug 1994 21:29:46 +0000 |
parents | 7db892210924 |
children | 7cdfcd5e71ff |
rev | line source |
---|---|
6558 | 1 @c -*-texinfo-*- |
2 @c This is part of the GNU Emacs Lisp Reference Manual. | |
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. | |
4 @c See the file elisp.texi for copying conditions. | |
5 @setfilename ../info/processes | |
6 @node Processes, System Interface, Abbrevs, Top | |
7 @chapter Processes | |
8 @cindex child process | |
9 @cindex parent process | |
10 @cindex subprocess | |
11 @cindex process | |
12 | |
13 In the terminology of operating systems, a @dfn{process} is a space in | |
14 which a program can execute. Emacs runs in a process. Emacs Lisp | |
15 programs can invoke other programs in processes of their own. These are | |
16 called @dfn{subprocesses} or @dfn{child processes} of the Emacs process, | |
17 which is their @dfn{parent process}. | |
18 | |
19 A subprocess of Emacs may be @dfn{synchronous} or @dfn{asynchronous}, | |
20 depending on how it is created. When you create a synchronous | |
21 subprocess, the Lisp program waits for the subprocess to terminate | |
22 before continuing execution. When you create an asynchronous | |
23 subprocess, it can run in parallel with the Lisp program. This kind of | |
24 subprocess is represented within Emacs by a Lisp object which is also | |
25 called a ``process''. Lisp programs can use this object to communicate | |
26 with the subprocess or to control it. For example, you can send | |
27 signals, obtain status information, receive output from the process, or | |
28 send input to it. | |
29 | |
30 @defun processp object | |
31 This function returns @code{t} if @var{object} is a process, | |
32 @code{nil} otherwise. | |
33 @end defun | |
34 | |
35 @menu | |
36 * Subprocess Creation:: Functions that start subprocesses. | |
37 * Synchronous Processes:: Details of using synchronous subprocesses. | |
7411
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
38 * MS-DOS Subprocesses:: On MS-DOS, you must indicate text vs binary |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
39 for data sent to and from a subprocess. |
6558 | 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. | |
48 * Transaction Queues:: Transaction-based communication with subprocesses. | |
49 * TCP:: Opening network connections. | |
50 @end menu | |
51 | |
52 @node Subprocess Creation | |
53 @section Functions that Create Subprocesses | |
54 | |
55 There are three functions that create a new subprocess in which to run | |
56 a program. One of them, @code{start-process}, creates an asynchronous | |
57 process and returns a process object (@pxref{Asynchronous Processes}). | |
58 The other two, @code{call-process} and @code{call-process-region}, | |
59 create a synchronous process and do not return a process object | |
60 (@pxref{Synchronous Processes}). | |
61 | |
62 Synchronous and asynchronous processes are explained in following | |
63 sections. Since the three functions are all called in a similar | |
64 fashion, their common arguments are described here. | |
65 | |
66 @cindex execute program | |
67 @cindex @code{PATH} environment variable | |
68 @cindex @code{HOME} environment variable | |
69 In all cases, the function's @var{program} argument specifies the | |
70 program to be run. An error is signaled if the file is not found or | |
71 cannot be executed. If the file name is relative, the variable | |
72 @code{exec-path} contains a list of directories to search. Emacs | |
73 initializes @code{exec-path} when it starts up, based on the value of | |
74 the environment variable @code{PATH}. The standard file name | |
75 constructs, @samp{~}, @samp{.}, and @samp{..}, are interpreted as usual | |
76 in @code{exec-path}, but environment variable substitutions | |
77 (@samp{$HOME}, etc.) are not recognized; use | |
78 @code{substitute-in-file-name} to perform them (@pxref{File Name | |
79 Expansion}). | |
80 | |
81 Each of the subprocess-creating functions has a @var{buffer-or-name} | |
82 argument which specifies where the standard output from the program will | |
83 go. If @var{buffer-or-name} is @code{nil}, that says to discard the | |
84 output unless a filter function handles it. (@xref{Filter Functions}, | |
7411
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
85 and @ref{Read and Print}.) Normally, you should avoid having multiple |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
86 processes send output to the same buffer because their output would be |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
87 intermixed randomly. |
6558 | 88 |
89 @cindex program arguments | |
90 All three of the subprocess-creating functions have a @code{&rest} | |
91 argument, @var{args}. The @var{args} must all be strings, and they are | |
92 supplied to @var{program} as separate command line arguments. Wildcard | |
93 characters and other shell constructs are not allowed in these strings, | |
94 since they are passed directly to the specified program. | |
95 | |
7735
7db892210924
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7411
diff
changeset
|
96 @strong{Please note:} The argument @var{program} contains only the |
6558 | 97 name of the program; it may not contain any command-line arguments. You |
98 must use @var{args} to provide those. | |
99 | |
100 The subprocess gets its current directory from the value of | |
101 @code{default-directory} (@pxref{File Name Expansion}). | |
102 | |
103 @cindex environment variables, subprocesses | |
104 The subprocess inherits its environment from Emacs; but you can | |
105 specify overrides for it with @code{process-environment}. @xref{System | |
106 Environment}. | |
107 | |
108 @defvar exec-directory | |
109 @pindex wakeup | |
110 The value of this variable is the name of a directory (a string) that | |
111 contains programs that come with GNU Emacs, that are intended for Emacs | |
112 to invoke. The program @code{wakeup} is an example of such a program; | |
113 the @code{display-time} command uses it to get a reminder once per | |
114 minute. | |
115 @end defvar | |
116 | |
117 @defopt exec-path | |
118 The value of this variable is a list of directories to search for | |
119 programs to run in subprocesses. Each element is either the name of a | |
120 directory (i.e., a string), or @code{nil}, which stands for the default | |
121 directory (which is the value of @code{default-directory}). | |
122 @cindex program directories | |
123 | |
124 The value of @code{exec-path} is used by @code{call-process} and | |
125 @code{start-process} when the @var{program} argument is not an absolute | |
126 file name. | |
127 @end defopt | |
128 | |
129 @node Synchronous Processes | |
130 @section Creating a Synchronous Process | |
131 @cindex synchronous subprocess | |
132 | |
133 After a @dfn{synchronous process} is created, Emacs waits for the | |
134 process to terminate before continuing. Starting Dired is an example of | |
135 this: it runs @code{ls} in a synchronous process, then modifies the | |
136 output slightly. Because the process is synchronous, the entire | |
137 directory listing arrives in the buffer before Emacs tries to do | |
138 anything with it. | |
139 | |
140 While Emacs waits for the synchronous subprocess to terminate, the | |
141 user can quit by typing @kbd{C-g}. The first @kbd{C-g} tries to kill | |
142 the subprocess with a @code{SIGINT} signal; but it waits until the | |
143 subprocess actually terminates before quitting. If during that time the | |
144 user types another @kbd{C-g}, that kills the subprocess instantly with | |
145 @code{SIGKILL} and quits immediately. @xref{Quitting}. | |
146 | |
147 The synchronous subprocess functions returned @code{nil} in version | |
148 18. In version 19, they return an indication of how the process | |
149 terminated. | |
150 | |
151 @defun call-process program &optional infile buffer-or-name display &rest args | |
152 This function calls @var{program} in a separate process and waits for | |
153 it to finish. | |
154 | |
155 The standard input for the process comes from file @var{infile} if | |
156 @var{infile} is not @code{nil} and from @file{/dev/null} otherwise. The | |
157 process output gets inserted in buffer @var{buffer-or-name} before point, | |
158 if that argument names a buffer. If @var{buffer-or-name} is @code{t}, | |
159 output is sent to the current buffer; if @var{buffer-or-name} is | |
160 @code{nil}, output is discarded. | |
161 | |
162 If @var{buffer-or-name} is the integer 0, @code{call-process} returns | |
163 @code{nil} immediately and discards any output. In this case, the | |
164 process is not truly synchronous, since it can run in parallel with | |
165 Emacs; but you can think of it as synchronous in that Emacs is | |
166 essentially finished with the subprocess as soon as this function | |
167 returns. | |
168 | |
169 If @var{display} is non-@code{nil}, then @code{call-process} redisplays | |
170 the buffer as output is inserted. Otherwise the function does no | |
171 redisplay, and the results become visible on the screen only when Emacs | |
172 redisplays that buffer in the normal course of events. | |
173 | |
174 The remaining arguments, @var{args}, are strings that specify command | |
175 line arguments for the program. | |
176 | |
177 The value returned by @code{call-process} (unless you told it not to | |
178 wait) indicates the reason for process termination. A number gives the | |
179 exit status of the subprocess; 0 means success, and any other value | |
180 means failure. If the process terminated with a signal, | |
181 @code{call-process} returns a string describing the signal. | |
182 | |
183 In the examples below, the buffer @samp{foo} is current. | |
184 | |
185 @smallexample | |
186 @group | |
187 (call-process "pwd" nil t) | |
188 @result{} nil | |
189 | |
190 ---------- Buffer: foo ---------- | |
191 /usr/user/lewis/manual | |
192 ---------- Buffer: foo ---------- | |
193 @end group | |
194 | |
195 @group | |
196 (call-process "grep" nil "bar" nil "lewis" "/etc/passwd") | |
197 @result{} nil | |
198 | |
199 ---------- Buffer: bar ---------- | |
200 lewis:5LTsHm66CSWKg:398:21:Bil Lewis:/user/lewis:/bin/csh | |
201 | |
202 ---------- Buffer: bar ---------- | |
203 @end group | |
204 @end smallexample | |
205 | |
206 The @code{insert-directory} function contains a good example of the use | |
207 of @code{call-process}: | |
208 | |
209 @smallexample | |
210 @group | |
211 (call-process insert-directory-program nil t nil switches | |
212 (if full-directory-p | |
213 (concat (file-name-as-directory file) ".") | |
214 file)) | |
215 @end group | |
216 @end smallexample | |
217 @end defun | |
218 | |
219 @defun call-process-region start end program &optional delete buffer-or-name display &rest args | |
220 This function sends the text between @var{start} to @var{end} as | |
221 standard input to a process running @var{program}. It deletes the text | |
222 sent if @var{delete} is non-@code{nil}; this is useful when @var{buffer} | |
223 is @code{t}, to insert the output in the current buffer. | |
224 | |
225 The arguments @var{buffer-or-name} and @var{display} control what to do | |
226 with the output from the subprocess, and whether to update the display | |
227 as it comes in. For details, see the description of | |
228 @code{call-process}, above. If @var{buffer-or-name} is the integer 0, | |
229 @code{call-process-region} discards the output and returns @code{nil} | |
230 immediately, without waiting for the subprocess to finish. | |
231 | |
232 The remaining arguments, @var{args}, are strings that specify command | |
233 line arguments for the program. | |
234 | |
235 The return value of @code{call-process-region} is just like that of | |
236 @code{call-process}: @code{nil} if you told it to return without | |
237 waiting; otherwise, a number or string which indicates how the | |
238 subprocess terminated. | |
239 | |
240 In the following example, we use @code{call-process-region} to run the | |
241 @code{cat} utility, with standard input being the first five characters | |
242 in buffer @samp{foo} (the word @samp{input}). @code{cat} copies its | |
243 standard input into its standard output. Since the argument | |
244 @var{buffer-or-name} is @code{t}, this output is inserted in the current | |
245 buffer. | |
246 | |
247 @smallexample | |
248 @group | |
249 ---------- Buffer: foo ---------- | |
250 input@point{} | |
251 ---------- Buffer: foo ---------- | |
252 @end group | |
253 | |
254 @group | |
255 (call-process-region 1 6 "cat" nil t) | |
256 @result{} nil | |
257 | |
258 ---------- Buffer: foo ---------- | |
259 inputinput@point{} | |
260 ---------- Buffer: foo ---------- | |
261 @end group | |
262 @end smallexample | |
263 | |
264 The @code{shell-command-on-region} command uses | |
265 @code{call-process-region} like this: | |
266 | |
267 @smallexample | |
268 @group | |
269 (call-process-region | |
270 start end | |
271 shell-file-name ; @r{Name of program.} | |
272 nil ; @r{Do not delete region.} | |
273 buffer ; @r{Send output to @code{buffer}.} | |
274 nil ; @r{No redisplay during output.} | |
275 "-c" command) ; @r{Arguments for the shell.} | |
276 @end group | |
277 @end smallexample | |
278 @end defun | |
279 | |
7411
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
280 @node MS-DOS Subprocesses |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
281 @section MS-DOS Subprocesses |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
282 |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
283 On MS-DOS, you must indicate whether the data going to and from |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
284 a synchronous subprocess are text or binary. Text data requires |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
285 translation between the end-of-line convention used within Emacs |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
286 (a single newline character) and the convention used outside Emacs |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
287 (the two-character sequence, CRLF). |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
288 |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
289 The variable @code{binary-process-input} applies to input sent to the |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
290 subprocess, and @code{binary-process-output} applies to output received |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
291 from it. A non-@code{nil} value means the data is non-text; @code{nil} |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
292 means the data is text, and calls for conversion. |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
293 |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
294 @defvar binary-process-input |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
295 If this variable is @code{nil}, convert newlines to CRLF sequences in |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
296 the input to a synchronous subprocess. |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
297 @end defvar |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
298 |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
299 @defvar binary-process-output |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
300 If this variable is @code{nil}, convert CRLF sequences to newlines in |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
301 the output from a synchronous subprocess. |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
302 @end defvar |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
303 |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
304 @xref{Files and MS-DOS}, for related information. |
266b18250120
*** empty log message ***
Richard M. Stallman <rms@gnu.org>
parents:
7115
diff
changeset
|
305 |
6558 | 306 @node Asynchronous Processes |
307 @section Creating an Asynchronous Process | |
308 @cindex asynchronous subprocess | |
309 | |
310 After an @dfn{asynchronous process} is created, Emacs and the Lisp | |
311 program both continue running immediately. The process may thereafter | |
312 run in parallel with Emacs, and the two may communicate with each other | |
313 using the functions described in following sections. Here we describe | |
314 how to create an asynchronous process with @code{start-process}. | |
315 | |
316 @defun start-process name buffer-or-name program &rest args | |
317 This function creates a new asynchronous subprocess and starts the | |
318 program @var{program} running in it. It returns a process object that | |
319 stands for the new subprocess in Lisp. The argument @var{name} | |
320 specifies the name for the process object; if a process with this name | |
321 already exists, then @var{name} is modified (by adding @samp{<1>}, etc.) | |
322 to be unique. The buffer @var{buffer-or-name} is the buffer to | |
323 associate with the process. | |
324 | |
325 The remaining arguments, @var{args}, are strings that specify command | |
326 line arguments for the program. | |
327 | |
328 In the example below, the first process is started and runs (rather, | |
329 sleeps) for 100 seconds. Meanwhile, the second process is started, and | |
330 given the name @samp{my-process<1>} for the sake of uniqueness. It | |
331 inserts the directory listing at the end of the buffer @samp{foo}, | |
332 before the first process finishes. Then it finishes, and a message to | |
333 that effect is inserted in the buffer. Much later, the first process | |
334 finishes, and another message is inserted in the buffer for it. | |
335 | |
336 @smallexample | |
337 @group | |
338 (start-process "my-process" "foo" "sleep" "100") | |
339 @result{} #<process my-process> | |
340 @end group | |
341 | |
342 @group | |
343 (start-process "my-process" "foo" "ls" "-l" "/user/lewis/bin") | |
344 @result{} #<process my-process<1>> | |
345 | |
346 ---------- Buffer: foo ---------- | |
347 total 2 | |
348 lrwxrwxrwx 1 lewis 14 Jul 22 10:12 gnuemacs --> /emacs | |
349 -rwxrwxrwx 1 lewis 19 Jul 30 21:02 lemon | |
350 | |
351 Process my-process<1> finished | |
352 | |
353 Process my-process finished | |
354 ---------- Buffer: foo ---------- | |
355 @end group | |
356 @end smallexample | |
357 @end defun | |
358 | |
359 @defun start-process-shell-command name buffer-or-name command &rest command-args | |
360 This function is like @code{start-process} except that it uses a shell | |
361 to execute the specified command. The argument @var{command} is a shell | |
362 command name, and @var{command-args} are the arguments for the shell | |
363 command. | |
364 @end defun | |
365 | |
366 @defvar process-connection-type | |
367 @cindex pipes | |
368 @cindex @sc{pty}s | |
369 This variable controls the type of device used to communicate with | |
370 asynchronous subprocesses. If it is @code{nil}, then pipes are used. | |
371 If it is @code{t}, then @sc{pty}s are used (or pipes if @sc{pty}s are | |
372 not supported). | |
373 | |
374 @sc{pty}s are usually preferable for processes visible to the user, as | |
375 in Shell mode, because they allow job control (@kbd{C-c}, @kbd{C-z}, | |
376 etc.) to work between the process and its children whereas pipes do not. | |
377 For subprocesses used for internal purposes by programs, it is often | |
378 better to use a pipe, because they are more efficient. In addition, the | |
379 total number of @sc{pty}s is limited on many systems and it is good not | |
380 to waste them. | |
381 | |
382 The value @code{process-connection-type} is used when | |
383 @code{start-process} is called. So you can specify how to communicate | |
384 with one subprocess by binding the variable around the call to | |
385 @code{start-process}. | |
386 | |
387 @smallexample | |
388 @group | |
389 (let ((process-connection-type nil)) ; @r{Use a pipe.} | |
390 (start-process @dots{})) | |
391 @end group | |
392 @end smallexample | |
393 @end defvar | |
394 | |
395 @node Deleting Processes | |
396 @section Deleting Processes | |
397 @cindex deleting processes | |
398 | |
399 @dfn{Deleting a process} disconnects Emacs immediately from the | |
400 subprocess, and removes it from the list of active processes. It sends | |
401 a signal to the subprocess to make the subprocess terminate, but this is | |
402 not guaranteed to happen immediately. The process object itself | |
403 continues to exist as long as other Lisp objects point to it. | |
404 | |
405 You can delete a process explicitly at any time. Processes are | |
406 deleted automatically after they terminate, but not necessarily right | |
407 away. If you delete a terminated process explicitly before it is | |
408 deleted automatically, no harm results. | |
409 | |
410 @defvar delete-exited-processes | |
411 This variable controls automatic deletion of processes that have | |
412 terminated (due to calling @code{exit} or to a signal). If it is | |
413 @code{nil}, then they continue to exist until the user runs | |
414 @code{list-processes}. Otherwise, they are deleted immediately after | |
415 they exit. | |
416 @end defvar | |
417 | |
418 @defun delete-process name | |
419 This function deletes the process associated with @var{name}, killing it | |
420 with a @code{SIGHUP} signal. The argument @var{name} may be a process, | |
421 the name of a process, a buffer, or the name of a buffer. | |
422 | |
423 @smallexample | |
424 @group | |
425 (delete-process "*shell*") | |
426 @result{} nil | |
427 @end group | |
428 @end smallexample | |
429 @end defun | |
430 | |
431 @defun process-kill-without-query process | |
432 This function declares that Emacs need not query the user if | |
433 @var{process} is still running when Emacs is exited. The process will | |
434 be deleted silently. The value is @code{t}. | |
435 | |
436 @smallexample | |
437 @group | |
438 (process-kill-without-query (get-process "shell")) | |
439 @result{} t | |
440 @end group | |
441 @end smallexample | |
442 @end defun | |
443 | |
444 @node Process Information | |
445 @section Process Information | |
446 | |
447 Several functions return information about processes. | |
448 @code{list-processes} is provided for interactive use. | |
449 | |
450 @deffn Command list-processes | |
451 This command displays a listing of all living processes. In addition, | |
452 it finally deletes any process whose status was @samp{Exited} or | |
453 @samp{Signaled}. It returns @code{nil}. | |
454 @end deffn | |
455 | |
456 @defun process-list | |
457 This function returns a list of all processes that have not been deleted. | |
458 | |
459 @smallexample | |
460 @group | |
461 (process-list) | |
462 @result{} (#<process display-time> #<process shell>) | |
463 @end group | |
464 @end smallexample | |
465 @end defun | |
466 | |
467 @defun get-process name | |
468 This function returns the process named @var{name}, or @code{nil} if | |
469 there is none. An error is signaled if @var{name} is not a string. | |
470 | |
471 @smallexample | |
472 @group | |
473 (get-process "shell") | |
474 @result{} #<process shell> | |
475 @end group | |
476 @end smallexample | |
477 @end defun | |
478 | |
479 @defun process-command process | |
480 This function returns the command that was executed to start | |
481 @var{process}. This is a list of strings, the first string being the | |
482 program executed and the rest of the strings being the arguments that | |
483 were given to the program. | |
484 | |
485 @smallexample | |
486 @group | |
487 (process-command (get-process "shell")) | |
488 @result{} ("/bin/csh" "-i") | |
489 @end group | |
490 @end smallexample | |
491 @end defun | |
492 | |
493 @defun process-id process | |
494 This function returns the @sc{pid} of @var{process}. This is an | |
495 integer which distinguishes the process @var{process} from all other | |
496 processes running on the same computer at the current time. The | |
497 @sc{pid} of a process is chosen by the operating system kernel when the | |
498 process is started and remains constant as long as the process exists. | |
499 @end defun | |
500 | |
501 @defun process-name process | |
502 This function returns the name of @var{process}. | |
503 @end defun | |
504 | |
505 @defun process-status process-name | |
506 This function returns the status of @var{process-name} as a symbol. | |
507 The argument @var{process-name} must be a process, a buffer, a | |
508 process name (string) or a buffer name (string). | |
509 | |
510 The possible values for an actual subprocess are: | |
511 | |
512 @table @code | |
513 @item run | |
514 for a process that is running. | |
515 @item stop | |
516 for a process that is stopped but continuable. | |
517 @item exit | |
518 for a process that has exited. | |
519 @item signal | |
520 for a process that has received a fatal signal. | |
521 @item open | |
522 for a network connection that is open. | |
523 @item closed | |
524 for a network connection that is closed. Once a connection | |
525 is closed, you cannot reopen it, though you might be able to open | |
526 a new connection to the same place. | |
527 @item nil | |
528 if @var{process-name} is not the name of an existing process. | |
529 @end table | |
530 | |
531 @smallexample | |
532 @group | |
533 (process-status "shell") | |
534 @result{} run | |
535 @end group | |
536 @group | |
537 (process-status (get-buffer "*shell*")) | |
538 @result{} run | |
539 @end group | |
540 @group | |
541 x | |
542 @result{} #<process xx<1>> | |
543 (process-status x) | |
544 @result{} exit | |
545 @end group | |
546 @end smallexample | |
547 | |
548 For a network connection, @code{process-status} returns one of the symbols | |
549 @code{open} or @code{closed}. The latter means that the other side | |
550 closed the connection, or Emacs did @code{delete-process}. | |
551 | |
552 In earlier Emacs versions (prior to version 19), the status of a network | |
553 connection was @code{run} if open, and @code{exit} if closed. | |
554 @end defun | |
555 | |
556 @defun process-exit-status process | |
557 This function returns the exit status of @var{process} or the signal | |
558 number that killed it. (Use the result of @code{process-status} to | |
559 determine which of those it is.) If @var{process} has not yet | |
560 terminated, the value is 0. | |
561 @end defun | |
562 | |
563 @node Input to Processes | |
564 @section Sending Input to Processes | |
565 @cindex process input | |
566 | |
567 Asynchronous subprocesses receive input when it is sent to them by | |
568 Emacs, which is done with the functions in this section. You must | |
569 specify the process to send input to, and the input data to send. The | |
570 data appears on the ``standard input'' of the subprocess. | |
571 | |
572 Some operating systems have limited space for buffered input in a | |
573 @sc{pty}. On these systems, Emacs sends an @sc{eof} periodically amidst | |
574 the other characters, to force them through. For most programs, | |
575 these @sc{eof}s do no harm. | |
576 | |
577 @defun process-send-string process-name string | |
578 This function sends @var{process-name} the contents of @var{string} as | |
579 standard input. The argument @var{process-name} must be a process or | |
580 the name of a process. If it is @code{nil}, the current buffer's | |
581 process is used. | |
582 | |
583 The function returns @code{nil}. | |
584 | |
585 @smallexample | |
586 @group | |
587 (process-send-string "shell<1>" "ls\n") | |
588 @result{} nil | |
589 @end group | |
590 | |
591 | |
592 @group | |
593 ---------- Buffer: *shell* ---------- | |
594 ... | |
595 introduction.texi syntax-tables.texi~ | |
596 introduction.texi~ text.texi | |
597 introduction.txt text.texi~ | |
598 ... | |
599 ---------- Buffer: *shell* ---------- | |
600 @end group | |
601 @end smallexample | |
602 @end defun | |
603 | |
604 @deffn Command process-send-region process-name start end | |
605 This function sends the text in the region defined by @var{start} and | |
606 @var{end} as standard input to @var{process-name}, which is a process or | |
607 a process name. (If it is @code{nil}, the current buffer's process is | |
608 used.) | |
609 | |
610 An error is signaled unless both @var{start} and @var{end} are | |
611 integers or markers that indicate positions in the current buffer. (It | |
612 is unimportant which number is larger.) | |
613 @end deffn | |
614 | |
615 @defun process-send-eof &optional process-name | |
616 This function makes @var{process-name} see an end-of-file in its | |
617 input. The @sc{eof} comes after any text already sent to it. | |
618 | |
619 If @var{process-name} is not supplied, or if it is @code{nil}, then | |
620 this function sends the @sc{eof} to the current buffer's process. An | |
621 error is signaled if the current buffer has no process. | |
622 | |
623 The function returns @var{process-name}. | |
624 | |
625 @smallexample | |
626 @group | |
627 (process-send-eof "shell") | |
628 @result{} "shell" | |
629 @end group | |
630 @end smallexample | |
631 @end defun | |
632 | |
633 @node Signals to Processes | |
634 @section Sending Signals to Processes | |
635 @cindex process signals | |
636 @cindex sending signals | |
637 @cindex signals | |
638 | |
639 @dfn{Sending a signal} to a subprocess is a way of interrupting its | |
640 activities. There are several different signals, each with its own | |
641 meaning. The set of signals and their names is defined by the operating | |
642 system. For example, the signal @code{SIGINT} means that the user has | |
643 typed @kbd{C-c}, or that some analogous thing has happened. | |
644 | |
645 Each signal has a standard effect on the subprocess. Most signals | |
646 kill the subprocess, but some stop or resume execution instead. Most | |
647 signals can optionally be handled by programs; if the program handles | |
648 the signal, then we can say nothing in general about its effects. | |
649 | |
650 You can send signals explicitly by calling the functions in this | |
651 section. Emacs also sends signals automatically at certain times: | |
652 killing a buffer sends a @code{SIGHUP} signal to all its associated | |
653 processes; killing Emacs sends a @code{SIGHUP} signal to all remaining | |
654 processes. (@code{SIGHUP} is a signal that usually indicates that the | |
655 user hung up the phone.) | |
656 | |
657 Each of the signal-sending functions takes two optional arguments: | |
658 @var{process-name} and @var{current-group}. | |
659 | |
660 The argument @var{process-name} must be either a process, the name of | |
661 one, or @code{nil}. If it is @code{nil}, the process defaults to the | |
662 process associated with the current buffer. An error is signaled if | |
663 @var{process-name} does not identify a process. | |
664 | |
665 The argument @var{current-group} is a flag that makes a difference | |
666 when you are running a job-control shell as an Emacs subprocess. If it | |
667 is non-@code{nil}, then the signal is sent to the current process-group | |
668 of the terminal which Emacs uses to communicate with the subprocess. If | |
669 the process is a job-control shell, this means the shell's current | |
670 subjob. If it is @code{nil}, the signal is sent to the process group of | |
671 the immediate subprocess of Emacs. If the subprocess is a job-control | |
672 shell, this is the shell itself. | |
673 | |
674 The flag @var{current-group} has no effect when a pipe is used to | |
675 communicate with the subprocess, because the operating system does not | |
676 support the distinction in the case of pipes. For the same reason, | |
677 job-control shells won't work when a pipe is used. See | |
678 @code{process-connection-type} in @ref{Asynchronous Processes}. | |
679 | |
680 @defun interrupt-process &optional process-name current-group | |
681 This function interrupts the process @var{process-name} by sending the | |
682 signal @code{SIGINT}. Outside of Emacs, typing the ``interrupt | |
683 character'' (normally @kbd{C-c} on some systems, and @code{DEL} on | |
684 others) sends this signal. When the argument @var{current-group} is | |
685 non-@code{nil}, you can think of this function as ``typing @kbd{C-c}'' | |
686 on the terminal by which Emacs talks to the subprocess. | |
687 @end defun | |
688 | |
689 @defun kill-process &optional process-name current-group | |
690 This function kills the process @var{process-name} by sending the | |
691 signal @code{SIGKILL}. This signal kills the subprocess immediately, | |
692 and cannot be handled by the subprocess. | |
693 @end defun | |
694 | |
695 @defun quit-process &optional process-name current-group | |
696 This function sends the signal @code{SIGQUIT} to the process | |
697 @var{process-name}. This signal is the one sent by the ``quit | |
698 character'' (usually @kbd{C-b} or @kbd{C-\}) when you are not inside | |
699 Emacs. | |
700 @end defun | |
701 | |
702 @defun stop-process &optional process-name current-group | |
703 This function stops the process @var{process-name} by sending the | |
704 signal @code{SIGTSTP}. Use @code{continue-process} to resume its | |
705 execution. | |
706 | |
707 On systems with job control, the ``stop character'' (usually @kbd{C-z}) | |
708 sends this signal (outside of Emacs). When @var{current-group} is | |
709 non-@code{nil}, you can think of this function as ``typing @kbd{C-z}'' | |
710 on the terminal Emacs uses to communicate with the subprocess. | |
711 @end defun | |
712 | |
713 @defun continue-process &optional process-name current-group | |
714 This function resumes execution of the process @var{process} by sending | |
715 it the signal @code{SIGCONT}. This presumes that @var{process-name} was | |
716 stopped previously. | |
717 @end defun | |
718 | |
719 @c Emacs 19 feature | |
720 @defun signal-process pid signal | |
721 This function sends a signal to process @var{pid}, which need not be | |
722 a child of Emacs. The argument @var{signal} specifies which signal | |
723 to send; it should be an integer. | |
724 @end defun | |
725 | |
726 @node Output from Processes | |
727 @section Receiving Output from Processes | |
728 @cindex process output | |
729 @cindex output from processes | |
730 | |
731 There are two ways to receive the output that a subprocess writes to | |
732 its standard output stream. The output can be inserted in a buffer, | |
733 which is called the associated buffer of the process, or a function | |
734 called the @dfn{filter function} can be called to act on the output. | |
735 | |
736 @menu | |
737 * Process Buffers:: If no filter, output is put in a buffer. | |
738 * Filter Functions:: Filter functions accept output from the process. | |
739 * Accepting Output:: Explicitly permitting subprocess output. | |
740 Waiting for subprocess output. | |
741 @end menu | |
742 | |
743 @node Process Buffers | |
744 @subsection Process Buffers | |
745 | |
746 A process can (and usually does) have an @dfn{associated buffer}, | |
747 which is an ordinary Emacs buffer that is used for two purposes: storing | |
748 the output from the process, and deciding when to kill the process. You | |
749 can also use the buffer to identify a process to operate on, since in | |
750 normal practice only one process is associated with any given buffer. | |
751 Many applications of processes also use the buffer for editing input to | |
752 be sent to the process, but this is not built into Emacs Lisp. | |
753 | |
754 Unless the process has a filter function (@pxref{Filter Functions}), | |
755 its output is inserted in the associated buffer. The position to insert | |
756 the output is determined by the @code{process-mark} (@pxref{Process | |
757 Information}), which is then updated to point to the end of the text | |
758 just inserted. Usually, but not always, the @code{process-mark} is at | |
759 the end of the buffer. If the process has no buffer and no filter | |
760 function, its output is discarded. | |
761 | |
762 @defun process-buffer process | |
763 This function returns the associated buffer of the process | |
764 @var{process}. | |
765 | |
766 @smallexample | |
767 @group | |
768 (process-buffer (get-process "shell")) | |
769 @result{} #<buffer *shell*> | |
770 @end group | |
771 @end smallexample | |
772 @end defun | |
773 | |
774 @defun process-mark process | |
775 This function returns the process marker for @var{process}, which is the | |
776 marker that says where to insert output from the process. | |
777 | |
778 If @var{process} does not have a buffer, @code{process-mark} returns a | |
779 marker that points nowhere. | |
780 | |
781 Insertion of process output in a buffer uses this marker to decide where | |
782 to insert, and updates it to point after the inserted text. That is why | |
783 successive batches of output are inserted consecutively. | |
784 | |
785 Filter functions normally should use this marker in the same fashion | |
786 as is done by direct insertion of output in the buffer. A good | |
787 example of a filter function that uses @code{process-mark} is found at | |
788 the end of the following section. | |
789 | |
790 When the user is expected to enter input in the process buffer for | |
791 transmission to the process, the process marker is useful for | |
792 distinguishing the new input from previous output. | |
793 @end defun | |
794 | |
795 @defun set-process-buffer process buffer | |
796 This function sets the buffer associated with @var{process} to | |
797 @var{buffer}. If @var{buffer} is @code{nil}, the process becomes | |
798 associated with no buffer. | |
799 @end defun | |
800 | |
801 @defun get-buffer-process buffer-or-name | |
802 This function returns the process associated with @var{buffer-or-name}. | |
803 If there are several processes associated with it, then one is chosen. | |
804 (Presently, the one chosen is the one most recently created.) It is | |
805 usually a bad idea to have more than one process associated with the | |
806 same buffer. | |
807 | |
808 @smallexample | |
809 @group | |
810 (get-buffer-process "*shell*") | |
811 @result{} #<process shell> | |
812 @end group | |
813 @end smallexample | |
814 | |
815 Killing the process's buffer deletes the process, which kills the | |
816 subprocess with a @code{SIGHUP} signal (@pxref{Signals to Processes}). | |
817 @end defun | |
818 | |
819 @node Filter Functions | |
820 @subsection Process Filter Functions | |
821 @cindex filter function | |
822 @cindex process filter | |
823 | |
824 A process @dfn{filter function} is a function that receives the | |
825 standard output from the associated process. If a process has a filter, | |
826 then @emph{all} output from that process, that would otherwise have been | |
827 in a buffer, is passed to the filter. The process buffer is used | |
828 directly for output from the process only when there is no filter. | |
829 | |
830 A filter function must accept two arguments: the associated process and | |
831 a string, which is the output. The function is then free to do whatever it | |
832 chooses with the output. | |
833 | |
834 A filter function runs only while Emacs is waiting (e.g., for terminal | |
835 input, or for time to elapse, or for process output). This avoids the | |
836 timing errors that could result from running filters at random places in | |
837 the middle of other Lisp programs. You may explicitly cause Emacs to | |
838 wait, so that filter functions will run, by calling @code{sit-for}, | |
839 @code{sleep-for} or @code{accept-process-output} (@pxref{Accepting | |
840 Output}). Emacs is also waiting when the command loop is reading input. | |
841 | |
842 Quitting is normally inhibited within a filter function---otherwise, | |
843 the effect of typing @kbd{C-g} at command level or to quit a user | |
844 command would be unpredictable. If you want to permit quitting inside a | |
845 filter function, bind @code{inhibit-quit} to @code{nil}. | |
846 @xref{Quitting}. | |
847 | |
848 Many filter functions sometimes or always insert the text in the | |
849 process's buffer, mimicking the actions of Emacs when there is no | |
850 filter. Such filter functions need to use @code{set-buffer} in order to | |
851 be sure to insert in that buffer. To avoid setting the current buffer | |
852 semipermanently, these filter functions must use @code{unwind-protect} | |
853 to make sure to restore the previous current buffer. They should also | |
854 update the process marker, and in some cases update the value of point. | |
855 Here is how to do these things: | |
856 | |
857 @smallexample | |
858 @group | |
859 (defun ordinary-insertion-filter (proc string) | |
860 (let ((old-buffer (current-buffer))) | |
861 (unwind-protect | |
862 (let (moving) | |
863 (set-buffer (process-buffer proc)) | |
864 (setq moving (= (point) (process-mark proc))) | |
865 @end group | |
866 @group | |
867 (save-excursion | |
868 ;; @r{Insert the text, moving the process-marker.} | |
869 (goto-char (process-mark proc)) | |
870 (insert string) | |
871 (set-marker (process-mark proc) (point))) | |
872 (if moving (goto-char (process-mark proc)))) | |
873 (set-buffer old-buffer)))) | |
874 @end group | |
875 @end smallexample | |
876 | |
877 @noindent | |
878 The reason to use an explicit @code{unwind-protect} rather than letting | |
879 @code{save-excursion} restore the current buffer is so as to preserve | |
880 the change in point made by @code{goto-char}. | |
881 | |
882 To make the filter force the process buffer to be visible whenever new | |
883 text arrives, insert the following line just before the | |
884 @code{unwind-protect}: | |
885 | |
886 @smallexample | |
887 (display-buffer (process-buffer proc)) | |
888 @end smallexample | |
889 | |
890 To force point to move to the end of the new output no matter where | |
891 it was previously, eliminate the variable @code{moving} and call | |
892 @code{goto-char} unconditionally. | |
893 | |
894 All filter functions that do regexp searching or matching should save | |
895 and restore the match data. Otherwise, a filter function that runs | |
896 during a call to @code{sit-for} might clobber the match data of the | |
897 program that called @code{sit-for}. @xref{Match Data}. | |
898 | |
899 A filter function that writes the output into the buffer of the | |
900 process should check whether the process is still alive. If it tries to | |
901 insert into a dead buffer, it will get an error. If the buffer is dead, | |
902 @code{(buffer-name (process-buffer @var{process}))} returns @code{nil}. | |
903 | |
904 The output to the function may come in chunks of any size. A program | |
905 that produces the same output twice in a row may send it as one batch | |
906 of 200 characters one time, and five batches of 40 characters the next. | |
907 | |
908 @defun set-process-filter process filter | |
909 This function gives @var{process} the filter function @var{filter}. If | |
910 @var{filter} is @code{nil}, it gives the process no filter. | |
911 @end defun | |
912 | |
913 @defun process-filter process | |
914 This function returns the filter function of @var{process}, or @code{nil} | |
915 if it has none. | |
916 @end defun | |
917 | |
918 Here is an example of use of a filter function: | |
919 | |
920 @smallexample | |
921 @group | |
922 (defun keep-output (process output) | |
923 (setq kept (cons output kept))) | |
924 @result{} keep-output | |
925 @end group | |
926 @group | |
927 (setq kept nil) | |
928 @result{} nil | |
929 @end group | |
930 @group | |
931 (set-process-filter (get-process "shell") 'keep-output) | |
932 @result{} keep-output | |
933 @end group | |
934 @group | |
935 (process-send-string "shell" "ls ~/other\n") | |
936 @result{} nil | |
937 kept | |
938 @result{} ("lewis@@slug[8] % " | |
939 @end group | |
940 @group | |
941 "FINAL-W87-SHORT.MSS backup.otl kolstad.mss~ | |
942 address.txt backup.psf kolstad.psf | |
943 backup.bib~ david.mss resume-Dec-86.mss~ | |
944 backup.err david.psf resume-Dec.psf | |
945 backup.mss dland syllabus.mss | |
946 " | |
947 "#backups.mss# backup.mss~ kolstad.mss | |
948 ") | |
949 @end group | |
950 @end smallexample | |
951 | |
952 @ignore @c The code in this example doesn't show the right way to do things. | |
953 Here is another, more realistic example, which demonstrates how to use | |
954 the process mark to do insertion in the same fashion as is done when | |
955 there is no filter function: | |
956 | |
957 @smallexample | |
958 @group | |
959 ;; @r{Insert input in the buffer specified by @code{my-shell-buffer}} | |
960 ;; @r{and make sure that buffer is shown in some window.} | |
961 (defun my-process-filter (proc str) | |
962 (let ((cur (selected-window)) | |
963 (pop-up-windows t)) | |
964 (pop-to-buffer my-shell-buffer) | |
965 @end group | |
966 @group | |
967 (goto-char (point-max)) | |
968 (insert str) | |
969 (set-marker (process-mark proc) (point-max)) | |
970 (select-window cur))) | |
971 @end group | |
972 @end smallexample | |
973 @end ignore | |
974 | |
975 @node Accepting Output | |
976 @subsection Accepting Output from Processes | |
977 | |
978 Output from asynchronous subprocesses normally arrives only while | |
979 Emacs is waiting for some sort of external event, such as elapsed time | |
980 or terminal input. Occasionally it is useful in a Lisp program to | |
981 explicitly permit output to arrive at a specific point, or even to wait | |
982 until output arrives from a process. | |
983 | |
984 @defun accept-process-output &optional process seconds millisec | |
985 This function allows Emacs to read pending output from processes. The | |
986 output is inserted in the associated buffers or given to their filter | |
987 functions. If @var{process} is non-@code{nil} then this function does | |
988 not return until some output has been received from @var{process}. | |
989 | |
990 @c Emacs 19 feature | |
991 The arguments @var{seconds} and @var{millisec} let you specify timeout | |
992 periods. The former specifies a period measured in seconds and the | |
993 latter specifies one measured in milliseconds. The two time periods | |
994 thus specified are added together, and @code{accept-process-output} | |
995 returns after that much time whether or not there has been any | |
996 subprocess output. | |
997 | |
998 Not all operating systems support waiting periods other than multiples | |
999 of a second; on those that do not, you get an error if you specify | |
1000 nonzero @var{millisec}. | |
1001 | |
1002 The function @code{accept-process-output} returns non-@code{nil} if it | |
1003 did get some output, or @code{nil} if the timeout expired before output | |
1004 arrived. | |
1005 @end defun | |
1006 | |
1007 @node Sentinels | |
1008 @section Sentinels: Detecting Process Status Changes | |
1009 @cindex process sentinel | |
1010 @cindex sentinel | |
1011 | |
1012 A @dfn{process sentinel} is a function that is called whenever the | |
1013 associated process changes status for any reason, including signals | |
1014 (whether sent by Emacs or caused by the process's own actions) that | |
1015 terminate, stop, or continue the process. The process sentinel is also | |
1016 called if the process exits. The sentinel receives two arguments: the | |
1017 process for which the event occurred, and a string describing the type | |
1018 of event. | |
1019 | |
1020 The string describing the event looks like one of the following: | |
1021 | |
1022 @itemize @bullet | |
1023 @item | |
1024 @code{"finished\n"}. | |
1025 | |
1026 @item | |
1027 @code{"exited abnormally with code @var{exitcode}\n"}. | |
1028 | |
1029 @item | |
1030 @code{"@var{name-of-signal}\n"}. | |
1031 | |
1032 @item | |
1033 @code{"@var{name-of-signal} (core dumped)\n"}. | |
1034 @end itemize | |
1035 | |
1036 A sentinel runs only while Emacs is waiting (e.g., for terminal input, | |
1037 or for time to elapse, or for process output). This avoids the timing | |
1038 errors that could result from running them at random places in the | |
1039 middle of other Lisp programs. A program can wait, so that sentinels | |
1040 will run, by calling @code{sit-for}, @code{sleep-for} or | |
1041 @code{accept-process-output} (@pxref{Accepting Output}). Emacs is also | |
1042 waiting when the command loop is reading input. | |
1043 | |
1044 Quitting is normally inhibited within a sentinel---otherwise, the | |
1045 effect of typing @kbd{C-g} at command level or to quit a user command | |
1046 would be unpredictable. If you want to permit quitting inside a | |
1047 sentinel, bind @code{inhibit-quit} to @code{nil}. @xref{Quitting}. | |
1048 | |
1049 A sentinel that writes the output into the buffer of the process | |
1050 should check whether the process is still alive. If it tries to insert | |
1051 into a dead buffer, it will get an error. If the buffer is dead, | |
1052 @code{(buffer-name (process-buffer @var{process}))} returns @code{nil}. | |
1053 | |
1054 All sentinels that do regexp searching or matching should save and | |
1055 restore the match data. Otherwise, a sentinel that runs during a call | |
1056 to @code{sit-for} might clobber the match data of the program that | |
1057 called @code{sit-for}. @xref{Match Data}. | |
1058 | |
1059 @defun set-process-sentinel process sentinel | |
1060 This function associates @var{sentinel} with @var{process}. If | |
1061 @var{sentinel} is @code{nil}, then the process will have no sentinel. | |
1062 The default behavior when there is no sentinel is to insert a message in | |
1063 the process's buffer when the process status changes. | |
1064 | |
1065 @smallexample | |
1066 @group | |
1067 (defun msg-me (process event) | |
1068 (princ | |
1069 (format "Process: %s had the event `%s'" process event))) | |
1070 (set-process-sentinel (get-process "shell") 'msg-me) | |
1071 @result{} msg-me | |
1072 @end group | |
1073 @group | |
1074 (kill-process (get-process "shell")) | |
1075 @print{} Process: #<process shell> had the event `killed' | |
1076 @result{} #<process shell> | |
1077 @end group | |
1078 @end smallexample | |
1079 @end defun | |
1080 | |
1081 @defun process-sentinel process | |
1082 This function returns the sentinel of @var{process}, or @code{nil} if it | |
1083 has none. | |
1084 @end defun | |
1085 | |
1086 @defun waiting-for-user-input-p | |
1087 While a sentinel or filter function is running, this function returns | |
1088 non-@code{nil} if Emacs was waiting for keyboard input from the user at | |
1089 the time the sentinel or filter function was called, @code{nil} if it | |
1090 was not. | |
1091 @end defun | |
1092 | |
1093 @node Transaction Queues | |
1094 @section Transaction Queues | |
1095 @cindex transaction queue | |
1096 | |
1097 You can use a @dfn{transaction queue} for more convenient communication | |
1098 with subprocesses using transactions. First use @code{tq-create} to | |
1099 create a transaction queue communicating with a specified process. Then | |
1100 you can call @code{tq-enqueue} to send a transaction. | |
1101 | |
1102 @defun tq-create process | |
1103 This function creates and returns a transaction queue communicating with | |
1104 @var{process}. The argument @var{process} should be a subprocess | |
1105 capable of sending and receiving streams of bytes. It may be a child | |
1106 process, or it may be a TCP connection to a server possibly on another | |
1107 machine. | |
1108 @end defun | |
1109 | |
1110 @defun tq-enqueue queue question regexp closure fn | |
1111 This function sends a transaction to queue @var{queue}. Specifying the | |
1112 queue has the effect of specifying the subprocess to talk to. | |
1113 | |
1114 The argument @var{question} is the outgoing message which starts the | |
1115 transaction. The argument @var{fn} is the function to call when the | |
1116 corresponding answer comes back; it is called with two arguments: | |
1117 @var{closure}, and the answer received. | |
1118 | |
1119 The argument @var{regexp} is a regular expression that should match the | |
1120 entire answer, but nothing less; that's how @code{tq-enqueue} determines | |
1121 where the answer ends. | |
1122 | |
1123 The return value of @code{tq-enqueue} itself is not meaningful. | |
1124 @end defun | |
1125 | |
1126 @defun tq-close queue | |
1127 Shut down transaction queue @var{queue}, waiting for all pending transactions | |
1128 to complete, and then terminate the connection or child process. | |
1129 @end defun | |
1130 | |
1131 Transaction queues are implemented by means of a filter function. | |
1132 @xref{Filter Functions}. | |
1133 | |
1134 @node TCP | |
1135 @section TCP | |
1136 @cindex TCP | |
1137 | |
1138 Emacs Lisp programs can open TCP connections to other processes on the | |
1139 same machine or other machines. A network connection is handled by Lisp | |
1140 much like a subprocess, and is represented by a process object. | |
1141 However, the process you are communicating with is not a child of the | |
1142 Emacs process, so you can't kill it or send it signals. All you can do | |
1143 is send and receive data. @code{delete-process} closes the connection, | |
1144 but does not kill the process at the other end; that process must decide | |
1145 what to do about closure of the connection. | |
1146 | |
1147 You can distinguish process objects representing network connections | |
1148 from those representing subprocesses with the @code{process-status} | |
1149 function. @xref{Process Information}. | |
1150 | |
1151 @defun open-network-stream name buffer-or-name host service | |
1152 This function opens a TCP connection for a service to a host. It | |
1153 returns a process object to represent the connection. | |
1154 | |
1155 The @var{name} argument specifies the name for the process object. It | |
1156 is modified as necessary to make it unique. | |
1157 | |
1158 The @var{buffer-or-name} argument is the buffer to associate with the | |
1159 connection. Output from the connection is inserted in the buffer, | |
1160 unless you specify a filter function to handle the output. If | |
1161 @var{buffer-or-name} is @code{nil}, it means that the connection is not | |
1162 associated with any buffer. | |
1163 | |
1164 The arguments @var{host} and @var{service} specify where to connect to; | |
1165 @var{host} is the host name (a string), and @var{service} is the name of | |
1166 a defined network service (a string) or a port number (an integer). | |
1167 @end defun |