1 '\" te 2 .\" Copyright (c) 2000, 2001, 2002, 2003, 2004 by Martin C. Shepherd. 3 .\" All Rights Reserved. 4 .\" Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 5 .\" "Software"), to deal in the Software without restriction, including 6 .\" without limitation the rights to use, copy, modify, merge, publish, 7 .\" distribute, and/or sell copies of the Software, and to permit persons 8 .\" to whom the Software is furnished to do so, provided that the above 9 .\" copyright notice(s) and this permission notice appear in all copies of 10 .\" the Software and that both the above copyright notice(s) and this 11 .\" permission notice appear in supporting documentation. 12 .\" 13 .\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 14 .\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 15 .\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT 16 .\" OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR 17 .\" HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL 18 .\" INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING 19 .\" FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, 20 .\" NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION 21 .\" WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 22 .\" 23 .\" Except as contained in this notice, the name of a copyright holder 24 .\" shall not be used in advertising or otherwise to promote the sale, use 25 .\" or other dealings in this Software without prior written authorization 26 .\" of the copyright holder. 27 .\" Portions Copyright (c) 2007, Sun Microsystems, Inc. All Rights Reserved. 28 .TH GL_IO_MODE 3TECLA "January 18, 2020" 29 .SH NAME 30 gl_io_mode, gl_raw_io, gl_normal_io, gl_tty_signals, gl_abandon_line, 31 gl_handle_signal, gl_pending_io \- use \fBgl_get_line()\fR from an external 32 event loop 33 .SH SYNOPSIS 34 .nf 35 cc [ \fIflag\fR\&.\|.\|. ] \fIfile\fR\&.\|.\|. \fB-ltecla\fR [ \fIlibrary\fR\&.\|.\|. ] 36 #include <libtecla.h> 37 38 \fBint\fR \fBgl_io_mode\fR(\fBGetLine *\fR\fIgl\fR, \fBGlIOMode\fR \fImode\fR); 39 .fi 40 41 .LP 42 .nf 43 \fBint\fR \fBgl_raw_io\fR(\fBGetLine *\fR\fIgl\fR); 44 .fi 45 46 .LP 47 .nf 48 \fBint\fR \fBgl_normal_io\fR(\fBGetLine *\fR\fIgl\fR); 49 .fi 50 51 .LP 52 .nf 53 \fBint\fR \fBgl_tty_signals\fR(\fBvoid (*\fR\fIterm_handler\fR)(int), \fBvoid (*\fR\fIsusp_handler\fR)(int), 54 \fBvoid (*\fR\fIcont_handler\fR)(int), \fBvoid (*\fR\fIsize_handler\fR)(int)); 55 .fi 56 57 .LP 58 .nf 59 \fBvoid\fR \fBgl_abandon_line\fR(\fBGetLine *\fR\fIgl\fR); 60 .fi 61 62 .LP 63 .nf 64 \fBvoid\fR \fBgl_handle_signal\fR(\fBint\fR \fIsigno\fR, \fBGetLine *\fR\fIgl\fR, \fBint\fR \fIngl\fR); 65 .fi 66 67 .LP 68 .nf 69 \fBGlPendingIO\fR \fBgl_pending_io\fR(\fBGetLine *\fR\fIgl\fR); 70 .fi 71 72 .SH DESCRIPTION 73 The \fBgl_get_line\fR(3TECLA) function supports two different I/O modes. These 74 are selected by calling the \fBgl_io_mode()\fR function. The \fImode\fR 75 argument of \fBgl_io_mode()\fR specifies the new I/O mode and must be one of 76 the following. 77 .sp 78 .ne 2 79 .na 80 \fB\fBGL_NORMAL_MODE\fR\fR 81 .ad 82 .RS 18n 83 Select the normal blocking-I/O mode. In this mode \fBgl_get_line()\fR does not 84 return until either an error occurs of the user finishes entering a new line. 85 .RE 86 87 .sp 88 .ne 2 89 .na 90 \fB\fBGL_SERVER_MODE\fR\fR 91 .ad 92 .RS 18n 93 Select non-blocking server I/O mode. In this mode, since non-blocking terminal 94 I/O is used, the entry of each new input line typically requires many calls to 95 \fBgl_get_line()\fR from an external I/O-driven event loop. 96 .RE 97 98 .sp 99 .LP 100 Newly created GetLine objects start in normal I/O mode, so to switch to 101 non-blocking server mode requires an initial call to \fBgl_io_mode()\fR. 102 .SS "Server I/O Mode" 103 In non-blocking server I/O mode, the application is required to have an event 104 loop that calls \fBgl_get_line()\fR whenever the terminal file descriptor can 105 perform the type of I/O that \fBgl_get_line()\fR is waiting for. To determine 106 which type of I/O \fBgl_get_line()\fR is waiting for, the application calls the 107 \fBgl_pending_io()\fR function. The return value is one of the following two 108 enumerated values. 109 .sp 110 .ne 2 111 .na 112 \fB\fBGLP_READ\fR\fR 113 .ad 114 .RS 13n 115 \fBgl_get_line()\fR is waiting to write a character to the terminal. 116 .RE 117 118 .sp 119 .ne 2 120 .na 121 \fB\fBGLP_WRITE\fR\fR 122 .ad 123 .RS 13n 124 \fBgl_get_line()\fR is waiting to read a character from the keyboard. 125 .RE 126 127 .sp 128 .LP 129 If the application is using either the \fBselect\fR(3C) or \fBpoll\fR(2) 130 function to watch for I/O on a group of file descriptors, then it should call 131 the \fBgl_pending_io()\fR function before each call to these functions to 132 determine which direction of I/O it should tell them to watch for, and 133 configure their arguments accordingly. In the case of the \fBselect()\fR 134 function, this means using the \fBFD_SET()\fR macro to add the terminal file 135 descriptor either to the set of file descriptors to be watched for readability 136 or the set to be watched for writability. 137 .sp 138 .LP 139 As in normal I/O mode, the return value of \fBgl_get_line()\fR is either a 140 pointer to a completed input line or \fINULL\fR. However, whereas in normal I/O 141 mode a \fINULL\fR return value always means that an error occurred, in 142 non-blocking server mode, \fINULL\fR is also returned when \fBgl_get_line()\fR 143 cannot read or write to the terminal without blocking. Thus in non-blocking 144 server mode, in order to determine when a \fINULL\fR return value signifies 145 that an error occurred or not, it is necessary to call the 146 \fBgl_return_status()\fR function. If this function returns the enumerated 147 value \fBGLR_BLOCKED\fR, \fBgl_get_line()\fR is waiting for I/O and no error 148 has occurred. 149 .sp 150 .LP 151 When \fBgl_get_line()\fR returns \fINULL\fR and \fBgl_return_status()\fR 152 indicates that this is due to blocked terminal I/O, the application should call 153 \fBgl_get_line()\fR again when the type of I/O reported by 154 \fBgl_pending_io()\fR becomes possible. The \fIprompt\fR, \fIstart_line\fR and 155 \fIstart_pos\fR arguments of \fBgl_get_line()\fR will be ignored on these 156 calls. If you need to change the prompt of the line that is currently being 157 edited, you can call the \fBgl_replace_prompt\fR(3TECLA) function between calls 158 to \fBgl_get_line()\fR. 159 .SS "Giving Up The Terminal" 160 A complication that is unique to non-blocking server mode is that it requires 161 that the terminal be left in raw mode between calls to \fBgl_get_line()\fR. If 162 this were not the case, the external event loop would not be able to detect 163 individual key-presses, and the basic line editing implemented by the terminal 164 driver would clash with the editing provided by \fBgl_get_line()\fR. When the 165 terminal needs to be used for purposes other than entering a new input line 166 with \fBgl_get_line()\fR, it needs to be restored to a usable state. In 167 particular, whenever the process is suspended or terminated, the terminal must 168 be returned to a normal state. If this is not done, then depending on the 169 characteristics of the shell that was used to invoke the program, the user 170 could end up with a hung terminal. To this end, the \fBgl_normal_io()\fR 171 function is provided for switching the terminal back to the state that it was 172 in when raw mode was last established. 173 .sp 174 .LP 175 The \fBgl_normal_io()\fR function first flushes any pending output to the 176 terminal, then moves the cursor to the start of the terminal line which follows 177 the end of the incompletely entered input line. At this point it is safe to 178 suspend or terminate the process, and it is safe for the application to read 179 and write to the terminal. To resume entry of the input line, the application 180 should call the \fBgl_raw_io()\fR function. 181 .sp 182 .LP 183 The \fBgl_normal_io()\fR function starts a new line, redisplays the partially 184 completed input line (if any), restores the cursor position within this line to 185 where it was when \fBgl_normal_io()\fR was called, then switches back to raw, 186 non-blocking terminal mode ready to continue entry of the input line when 187 \fBgl_get_line()\fR is next called. 188 .sp 189 .LP 190 Note that in non-blocking server mode, if \fBgl_get_line()\fR is called after a 191 call to \fBgl_normal_io()\fR, without an intervening call to \fBgl_raw_io()\fR, 192 \fBgl_get_line()\fR will call \fBgl_raw_mode()\fR itself, and the terminal will 193 remain in this mode when \fBgl_get_line()\fR returns. 194 .SS "Signal Handling" 195 In the previous section it was pointed out that in non-blocking server mode, 196 the terminal must be restored to a sane state whenever a signal is received 197 that either suspends or terminates the process. In normal I/O mode, this is 198 done for you by \fBgl_get_line()\fR, but in non-blocking server mode, since the 199 terminal is left in raw mode between calls to \fBgl_get_line()\fR, this signal 200 handling has to be done by the application. Since there are many signals that 201 can suspend or terminate a process, as well as other signals that are important 202 to \fBgl_get_line()\fR, such as the \fBSIGWINCH\fR signal, which tells it when 203 the terminal size has changed, the \fBgl_tty_signals()\fR function is provided 204 for installing signal handlers for all pertinent signals. 205 .sp 206 .LP 207 The \fBgl_tty_signals()\fR function uses \fBgl_get_line()\fR's internal list of 208 signals to assign specified signal handlers to groups of signals. The arguments 209 of this function are as follows. 210 .sp 211 .ne 2 212 .na 213 \fB\fIterm_handler\fR\fR 214 .ad 215 .RS 16n 216 This is the signal handler that is used to trap signals that by default 217 terminate any process that receives them (for example, \fBSIGINT\fR or 218 \fBSIGTERM\fR). 219 .RE 220 221 .sp 222 .ne 2 223 .na 224 \fB\fIsusp_handler\fR\fR 225 .ad 226 .RS 16n 227 This is the signal handler that is used to trap signals that by default suspend 228 any process that receives them, (for example, \fBSIGTSTP\fR or \fBSIGTTOU\fR). 229 .RE 230 231 .sp 232 .ne 2 233 .na 234 \fB\fIcont_handler\fR\fR 235 .ad 236 .RS 16n 237 This is the signal handler that is used to trap signals that are usually sent 238 when a process resumes after being suspended (usually \fBSIGCONT\fR). Beware 239 that there is nothing to stop a user from sending one of these signals at other 240 times. 241 .RE 242 243 .sp 244 .ne 2 245 .na 246 \fB\fIsize_handler\fR\fR 247 .ad 248 .RS 16n 249 This signal handler is used to trap signals that are sent to processes when 250 their controlling terminals are resized by the user (for example, 251 \fBSIGWINCH\fR). 252 .RE 253 254 .sp 255 .LP 256 These arguments can all be the same, if so desired, and \fBSIG_IGN\fR (ignore 257 this signal) or \fBSIG_DFL\fR (use the system-provided default signal handler) 258 can be specified instead of a function where pertinent. In particular, it is 259 rarely useful to trap \fBSIGCONT\fR, so the \fIcont_handler\fR argument will 260 usually be \fBSIG_DFL\fR or \fBSIG_IGN\fR. 261 .sp 262 .LP 263 The \fBgl_tty_signals()\fR function uses the POSIX \fBsigaction\fR(2) function 264 to install these signal handlers, and it is careful to use the \fIsa_mask\fR 265 member of each \fBsigaction\fR structure to ensure that only one of these 266 signals is ever delivered at a time. This guards against different instances of 267 these signal handlers from simultaneously trying to write to common global 268 data, such as a shared \fBsigsetjmp\fR(3C) buffer or a signal-received flag. 269 The signal handlers installed by this function should call the 270 \fBgl_handle_signal()\fR. 271 .sp 272 .LP 273 The \fIsigno\fR argument tells this function which signal it is being asked to 274 respond to, and the \fIgl\fR argument should be a pointer to the first element 275 of an array of \fIngl\fR \fBGetLine\fR objects. If your application has only 276 one of these objects, pass its pointer as the \fIgl\fR argument and specify 277 \fIngl\fR as 1. 278 .sp 279 .LP 280 Depending on the signal that is being handled, this function does different 281 things. 282 .SS "Process termination signals" 283 If the signal that was caught is one of those that by default terminates any 284 process that receives it, then \fBgl_handle_signal()\fR does the following 285 steps. 286 .RS +4 287 .TP 288 1. 289 First it blocks the delivery of all signals that can be blocked (ie. 290 \fBSIGKILL\fR and \fBSIGSTOP\fR cannot be blocked). 291 .RE 292 .RS +4 293 .TP 294 2. 295 Next it calls \fBgl_normal_io()\fR for each of the ngl GetLine objects. Note 296 that this does nothing to any of the GetLine objects that are not currently in 297 raw mode. 298 .RE 299 .RS +4 300 .TP 301 3. 302 Next it sets the signal handler of the signal to its default, 303 process-termination disposition. 304 .RE 305 .RS +4 306 .TP 307 4. 308 Next it re-sends the process the signal that was caught. 309 .RE 310 .RS +4 311 .TP 312 5. 313 Finally it unblocks delivery of this signal, which results in the process 314 being terminated. 315 .RE 316 .SS "Process suspension signals" 317 If the default disposition of the signal is to suspend the process, the same 318 steps are executed as for process termination signals, except that when the 319 process is later resumed, \fBgl_handle_signal()\fR continues, and does the 320 following steps. 321 .RS +4 322 .TP 323 1. 324 It re-blocks delivery of the signal. 325 .RE 326 .RS +4 327 .TP 328 2. 329 It reinstates the signal handler of the signal to the one that was displaced 330 when its default disposition was substituted. 331 .RE 332 .RS +4 333 .TP 334 3. 335 For any of the GetLine objects that were in raw mode when 336 \fBgl_handle_signal()\fR was called, \fBgl_handle_signal()\fR then calls 337 \fBgl_raw_io()\fR, to resume entry of the input lines on those terminals. 338 .RE 339 .RS +4 340 .TP 341 4. 342 Finally, it restores the signal process mask to how it was when 343 \fBgl_handle_signal()\fR was called. 344 .RE 345 .sp 346 .LP 347 Note that the process is suspended or terminated using the original signal that 348 was caught, rather than using the uncatchable \fBSIGSTOP\fR and \fBSIGKILL\fR 349 signals. This is important, because when a process is suspended or terminated, 350 the parent of the process may wish to use the status value returned by the wait 351 system call to figure out which signal was responsible. In particular, most 352 shells use this information to print a corresponding message to the terminal. 353 Users would be rightly confused if when their process received a \fBSIGPIPE\fR 354 signal, the program responded by sending itself a \fBSIGKILL\fR signal, and the 355 shell then printed out the provocative statement, "Killed!". 356 .SS "Interrupting The Event Loop" 357 If a signal is caught and handled when the application's event loop is waiting 358 in \fBselect()\fR or \fBpoll()\fR, these functions will be aborted with 359 \fBerrno\fR set to \fBEINTR\fR. When this happens the event loop should call 360 \fBgl_pending_io()\fR before calling \fBselect()\fR or \fBpoll()\fR again. It 361 should then arrange for \fBselect()\fR or \fBpoll()\fR to wait for the type of 362 I/O that \fBgl_pending_io()\fR reports. This is necessary because any signal 363 handler that calls \fBgl_handle_signal()\fR will frequently change the type of 364 I/O that \fBgl_get_line()\fR is waiting for. 365 .sp 366 .LP 367 If a signal arrives between the statements that configure the arguments of 368 \fBselect()\fR or \fBpoll()\fR and the calls to these functions, the signal 369 will not be seen by these functions, which will then not be aborted. If these 370 functions are waiting for keyboard input from the user when the signal is 371 received, and the signal handler arranges to redraw the input line to 372 accommodate a terminal resize or the resumption of the process. This redisplay 373 will be delayed until the user presses the next key. Apart from puzzling the 374 user, this clearly is not a serious problem. However there is a way, albeit 375 complicated, to completely avoid this race condition. The following steps 376 illustrate this. 377 .RS +4 378 .TP 379 1. 380 Block all of the signals that \fBgl_get_line()\fR catches, by passing the 381 signal set returned by \fBgl_list_signals()\fR to \fBsigprocmask\fR(2). 382 .RE 383 .RS +4 384 .TP 385 2. 386 Call \fBgl_pending_io()\fR and set up the arguments of \fBselect()\fR or 387 \fBpoll()\fR accordingly. 388 .RE 389 .RS +4 390 .TP 391 3. 392 Call \fBsigsetjmp\fR(3C) with a non-zero \fIsavemask\fR argument. 393 .RE 394 .RS +4 395 .TP 396 4. 397 Initially this \fBsigsetjmp()\fR statement will return zero, indicating that 398 control is not resuming there after a matching call to \fBsiglongjmp\fR(3C). 399 .RE 400 .RS +4 401 .TP 402 5. 403 Replace all of the handlers of the signals that \fBgl_get_line()\fR is 404 configured to catch, with a signal handler that first records the number of the 405 signal that was caught, in a file-scope variable, then calls \fBsiglongjmp()\fR 406 with a non-zero \fIval\fR argument, to return execution to the above 407 \fBsigsetjmp()\fR statement. Registering these signal handlers can conveniently 408 be done using the \fBgl_tty_signals()\fR function. 409 .RE 410 .RS +4 411 .TP 412 6. 413 Set the file-scope variable that the above signal handler uses to record any 414 signal that is caught to -1, so that we can check whether a signal was caught 415 by seeing if it contains a valid signal number. 416 .RE 417 .RS +4 418 .TP 419 7. 420 Now unblock the signals that were blocked in step 1. Any signal that was 421 received by the process in between step 1 and now will now be delivered, and 422 trigger our signal handler, as will any signal that is received until we block 423 these signals again. 424 .RE 425 .RS +4 426 .TP 427 8. 428 Now call \fBselect()\fR or \fBpoll()\fR. 429 .RE 430 .RS +4 431 .TP 432 9. 433 When select returns, again block the signals that were unblocked in step 7. 434 .sp 435 If a signal is arrived any time during the above steps, our signal handler will 436 be triggered and cause control to return to the \fBsigsetjmp()\fR statement, 437 where this time, \fBsigsetjmp()\fR will return non-zero, indicating that a 438 signal was caught. When this happens we simply skip the above block of 439 statements, and continue with the following statements, which are executed 440 regardless of whether or not a signal is caught. Note that when 441 \fBsigsetjmp()\fR returns, regardless of why it returned, the process signal 442 mask is returned to how it was when \fBsigsetjmp()\fR was called. Thus the 443 following statements are always executed with all of our signals blocked. 444 .RE 445 .RS +4 446 .TP 447 10. 448 Reinstate the signal handlers that were displaced in step 5. 449 .RE 450 .RS +4 451 .TP 452 11. 453 Check whether a signal was caught, by checking the file-scope variable that 454 the signal handler records signal numbers in. 455 .RE 456 .RS +4 457 .TP 458 12. 459 If a signal was caught, send this signal to the application again and 460 unblock only this signal so that it invokes the signal handler which was just 461 reinstated in step 10. 462 .RE 463 .RS +4 464 .TP 465 13. 466 Unblock all of the signals that were blocked in step 7. 467 .RE 468 .SS "Signals Caught By \fBgl_get_line()\fR" 469 Since the application is expected to handle signals in non-blocking server 470 mode, \fBgl_get_line()\fR does not attempt to duplicate this when it is being 471 called. If one of the signals that it is configured to catch is sent to the 472 application while \fBgl_get_line()\fR is being called, \fBgl_get_line()\fR 473 reinstates the caller's signal handlers, then immediately before returning, 474 re-sends the signal to the process to let the application's signal handler 475 handle it. If the process is not terminated by this signal, \fBgl_get_line()\fR 476 returns \fINULL\fR, and a following call to \fBgl_return_status()\fR returns 477 the enumerated value \fBGLR_SIGNAL\fR. 478 .SS "Aborting Line Input" 479 Often, rather than letting it terminate the process, applications respond to 480 the \fBSIGINT\fR user-interrupt signal by aborting the current input line. This 481 can be accomplished in non-blocking server-I/O mode by not calling 482 \fBgl_handle_signal()\fR when this signal is caught, but by calling instead the 483 \fBgl_abandon_line()\fR function. This function arranges that when 484 \fBgl_get_line()\fR is next called, it first flushes any pending output to the 485 terminal, discards the current input line, outputs a new prompt on the next 486 line, and finally starts accepting input of a new input line from the user. 487 .SS "Signal Safe Functions" 488 Provided that certain rules are followed, the \fBgl_normal_io()\fR, 489 \fBgl_raw_io()\fR, \fBgl_handle_signal()\fR, and \fBgl_abandon_line()\fR 490 functions can be written to be safely callable from signal handlers. Other 491 functions in this library should not be called from signal handlers. For this 492 to be true, all signal handlers that call these functions must be registered in 493 such a way that only one instance of any one of them can be running at one 494 time. The way to do this is to use the POSIX \fBsigaction()\fR function to 495 register all signal handlers, and when doing this, use the \fIsa_mask\fR member 496 of the corresponding \fBsigaction\fR structure to indicate that all of the 497 signals whose handlers invoke the above functions should be blocked when the 498 current signal is being handled. This prevents two signal handlers from 499 operating on a \fBGetLine\fR object at the same time. 500 .sp 501 .LP 502 To prevent signal handlers from accessing a \fBGetLine\fR object while 503 \fBgl_get_line()\fR or any of its associated public functions are operating on 504 it, all public functions associated with \fBgl_get_line()\fR, including 505 \fBgl_get_line()\fR itself, temporarily block the delivery of signals when they 506 are accessing \fBGetLine\fR objects. Beware that the only signals that they 507 block are the signals that \fBgl_get_line()\fR is currently configured to 508 catch, so be sure that if you call any of the above functions from signal 509 handlers, that the signals that these handlers are assigned to are configured 510 to be caught by \fBgl_get_line()\fR. See \fBgl_trap_signal\fR(3TECLA). 511 .SS "Using Timeouts To Poll" 512 If instead of using \fBselect()\fR or \fBpoll()\fR to wait for I/O your 513 application needs only to get out of \fBgl_get_line()\fR periodically to 514 briefly do something else before returning to accept input from the user, use 515 the \fBgl_inactivity_timeout\fR(3TECLA) function in non-blocking server mode to 516 specify that a callback function that returns \fBGLTO_CONTINUE\fR should be 517 called whenever \fBgl_get_line()\fR has been waiting for I/O for more than a 518 specified amount of time. When this callback is triggered, \fBgl_get_line()\fR 519 will return \fINULL\fR and a following call to \fBgl_return_status()\fR will 520 return \fBGLR_BLOCKED\fR. 521 .sp 522 .LP 523 The \fBgl_get_line()\fR function will not return until the user has not typed a 524 key for the specified interval, so if the interval is long and the user keeps 525 typing, \fBgl_get_line()\fR might not return for a while. There is no guarantee 526 that it will return in the time specified. 527 .SH ATTRIBUTES 528 See \fBattributes\fR(5) for descriptions of the following attributes: 529 .sp 530 531 .sp 532 .TS 533 box; 534 c | c 535 l | l . 536 ATTRIBUTE TYPE ATTRIBUTE VALUE 537 _ 538 Interface Stability Evolving 539 _ 540 MT-Level MT-Safe 541 .TE 542 543 .SH SEE ALSO 544 \fBcpl_complete_word\fR(3TECLA), \fBef_expand_file\fR(3TECLA), 545 \fBgl_get_line\fR(3TECLA), \fBlibtecla\fR(3LIB), \fBpca_lookup_file\fR(3TECLA), 546 \fBattributes\fR(5), \fBtecla\fR(5)