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