Commit | Line | Data |
68dc0745 |
1 | =head1 NAME |
2 | |
65acb1b1 |
3 | perlfaq8 - System Interaction ($Revision: 1.36 $, $Date: 1999/01/08 05:36:34 $) |
68dc0745 |
4 | |
5 | =head1 DESCRIPTION |
6 | |
7 | This section of the Perl FAQ covers questions involving operating |
8 | system interaction. This involves interprocess communication (IPC), |
9 | control over the user-interface (keyboard, screen and pointing |
10 | devices), and most anything else not related to data manipulation. |
11 | |
12 | Read the FAQs and documentation specific to the port of perl to your |
46fc3d4c |
13 | operating system (eg, L<perlvms>, L<perlplan9>, ...). These should |
68dc0745 |
14 | contain more detailed information on the vagaries of your perl. |
15 | |
16 | =head2 How do I find out which operating system I'm running under? |
17 | |
c8db1d39 |
18 | The $^O variable ($OSNAME if you use English) contains the operating |
68dc0745 |
19 | system that your perl binary was built for. |
20 | |
21 | =head2 How come exec() doesn't return? |
22 | |
23 | Because that's what it does: it replaces your currently running |
24 | program with a different one. If you want to keep going (as is |
25 | probably the case if you're asking this question) use system() |
26 | instead. |
27 | |
28 | =head2 How do I do fancy stuff with the keyboard/screen/mouse? |
29 | |
30 | How you access/control keyboards, screens, and pointing devices |
31 | ("mice") is system-dependent. Try the following modules: |
32 | |
33 | =over 4 |
34 | |
35 | =item Keyboard |
36 | |
37 | Term::Cap Standard perl distribution |
38 | Term::ReadKey CPAN |
39 | Term::ReadLine::Gnu CPAN |
40 | Term::ReadLine::Perl CPAN |
41 | Term::Screen CPAN |
42 | |
43 | =item Screen |
44 | |
45 | Term::Cap Standard perl distribution |
46 | Curses CPAN |
47 | Term::ANSIColor CPAN |
48 | |
49 | =item Mouse |
50 | |
51 | Tk CPAN |
52 | |
53 | =back |
54 | |
c8db1d39 |
55 | Some of these specific cases are shown below. |
56 | |
57 | =head2 How do I print something out in color? |
58 | |
59 | In general, you don't, because you don't know whether |
60 | the recipient has a color-aware display device. If you |
61 | know that they have an ANSI terminal that understands |
62 | color, you can use the Term::ANSIColor module from CPAN: |
63 | |
64 | use Term::ANSIColor; |
65 | print color("red"), "Stop!\n", color("reset"); |
66 | print color("green"), "Go!\n", color("reset"); |
67 | |
68 | Or like this: |
69 | |
70 | use Term::ANSIColor qw(:constants); |
71 | print RED, "Stop!\n", RESET; |
72 | print GREEN, "Go!\n", RESET; |
73 | |
74 | =head2 How do I read just one key without waiting for a return key? |
75 | |
76 | Controlling input buffering is a remarkably system-dependent matter. |
77 | If most systems, you can just use the B<stty> command as shown in |
78 | L<perlfunc/getc>, but as you see, that's already getting you into |
79 | portability snags. |
80 | |
81 | open(TTY, "+</dev/tty") or die "no tty: $!"; |
82 | system "stty cbreak </dev/tty >/dev/tty 2>&1"; |
83 | $key = getc(TTY); # perhaps this works |
84 | # OR ELSE |
85 | sysread(TTY, $key, 1); # probably this does |
86 | system "stty -cbreak </dev/tty >/dev/tty 2>&1"; |
87 | |
88 | The Term::ReadKey module from CPAN offers an easy-to-use interface that |
89 | should be more efficient than shelling out to B<stty> for each key. |
90 | It even includes limited support for Windows. |
91 | |
92 | use Term::ReadKey; |
93 | ReadMode('cbreak'); |
94 | $key = ReadKey(0); |
95 | ReadMode('normal'); |
96 | |
97 | However, that requires that you have a working C compiler and can use it |
98 | to build and install a CPAN module. Here's a solution using |
99 | the standard POSIX module, which is already on your systems (assuming |
100 | your system supports POSIX). |
101 | |
102 | use HotKey; |
103 | $key = readkey(); |
104 | |
105 | And here's the HotKey module, which hides the somewhat mystifying calls |
106 | to manipulate the POSIX termios structures. |
107 | |
108 | # HotKey.pm |
109 | package HotKey; |
110 | |
111 | @ISA = qw(Exporter); |
112 | @EXPORT = qw(cbreak cooked readkey); |
113 | |
114 | use strict; |
115 | use POSIX qw(:termios_h); |
116 | my ($term, $oterm, $echo, $noecho, $fd_stdin); |
117 | |
118 | $fd_stdin = fileno(STDIN); |
119 | $term = POSIX::Termios->new(); |
120 | $term->getattr($fd_stdin); |
121 | $oterm = $term->getlflag(); |
122 | |
123 | $echo = ECHO | ECHOK | ICANON; |
124 | $noecho = $oterm & ~$echo; |
125 | |
126 | sub cbreak { |
127 | $term->setlflag($noecho); # ok, so i don't want echo either |
128 | $term->setcc(VTIME, 1); |
129 | $term->setattr($fd_stdin, TCSANOW); |
130 | } |
131 | |
132 | sub cooked { |
133 | $term->setlflag($oterm); |
134 | $term->setcc(VTIME, 0); |
135 | $term->setattr($fd_stdin, TCSANOW); |
136 | } |
137 | |
138 | sub readkey { |
139 | my $key = ''; |
140 | cbreak(); |
141 | sysread(STDIN, $key, 1); |
142 | cooked(); |
143 | return $key; |
144 | } |
145 | |
146 | END { cooked() } |
147 | |
148 | 1; |
149 | |
150 | =head2 How do I check whether input is ready on the keyboard? |
151 | |
152 | The easiest way to do this is to read a key in nonblocking mode with the |
153 | Term::ReadKey module from CPAN, passing it an argument of -1 to indicate |
154 | not to block: |
155 | |
156 | use Term::ReadKey; |
157 | |
158 | ReadMode('cbreak'); |
159 | |
160 | if (defined ($char = ReadKey(-1)) ) { |
161 | # input was waiting and it was $char |
162 | } else { |
163 | # no input was waiting |
164 | } |
165 | |
166 | ReadMode('normal'); # restore normal tty settings |
167 | |
168 | =head2 How do I clear the screen? |
169 | |
170 | If you only have to so infrequently, use C<system>: |
171 | |
172 | system("clear"); |
173 | |
174 | If you have to do this a lot, save the clear string |
175 | so you can print it 100 times without calling a program |
176 | 100 times: |
177 | |
178 | $clear_string = `clear`; |
179 | print $clear_string; |
180 | |
181 | If you're planning on doing other screen manipulations, like cursor |
182 | positions, etc, you might wish to use Term::Cap module: |
183 | |
184 | use Term::Cap; |
185 | $terminal = Term::Cap->Tgetent( {OSPEED => 9600} ); |
186 | $clear_string = $terminal->Tputs('cl'); |
187 | |
188 | =head2 How do I get the screen size? |
189 | |
190 | If you have Term::ReadKey module installed from CPAN, |
191 | you can use it to fetch the width and height in characters |
192 | and in pixels: |
193 | |
194 | use Term::ReadKey; |
195 | ($wchar, $hchar, $wpixels, $hpixels) = GetTerminalSize(); |
196 | |
197 | This is more portable than the raw C<ioctl>, but not as |
198 | illustrative: |
199 | |
200 | require 'sys/ioctl.ph'; |
201 | die "no TIOCGWINSZ " unless defined &TIOCGWINSZ; |
202 | open(TTY, "+</dev/tty") or die "No tty: $!"; |
203 | unless (ioctl(TTY, &TIOCGWINSZ, $winsize='')) { |
204 | die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ; |
205 | } |
206 | ($row, $col, $xpixel, $ypixel) = unpack('S4', $winsize); |
207 | print "(row,col) = ($row,$col)"; |
208 | print " (xpixel,ypixel) = ($xpixel,$ypixel)" if $xpixel || $ypixel; |
209 | print "\n"; |
210 | |
68dc0745 |
211 | =head2 How do I ask the user for a password? |
212 | |
213 | (This question has nothing to do with the web. See a different |
214 | FAQ for that.) |
215 | |
216 | There's an example of this in L<perlfunc/crypt>). First, you put |
217 | the terminal into "no echo" mode, then just read the password |
218 | normally. You may do this with an old-style ioctl() function, POSIX |
219 | terminal control (see L<POSIX>, and Chapter 7 of the Camel), or a call |
220 | to the B<stty> program, with varying degrees of portability. |
221 | |
222 | You can also do this for most systems using the Term::ReadKey module |
223 | from CPAN, which is easier to use and in theory more portable. |
224 | |
c8db1d39 |
225 | use Term::ReadKey; |
226 | |
227 | ReadMode('noecho'); |
228 | $password = ReadLine(0); |
229 | |
68dc0745 |
230 | =head2 How do I read and write the serial port? |
231 | |
232 | This depends on which operating system your program is running on. In |
233 | the case of Unix, the serial ports will be accessible through files in |
234 | /dev; on other systems, the devices names will doubtless differ. |
235 | Several problem areas common to all device interaction are the |
236 | following |
237 | |
238 | =over 4 |
239 | |
240 | =item lockfiles |
241 | |
242 | Your system may use lockfiles to control multiple access. Make sure |
243 | you follow the correct protocol. Unpredictable behaviour can result |
244 | from multiple processes reading from one device. |
245 | |
246 | =item open mode |
247 | |
248 | If you expect to use both read and write operations on the device, |
249 | you'll have to open it for update (see L<perlfunc/"open"> for |
250 | details). You may wish to open it without running the risk of |
251 | blocking by using sysopen() and C<O_RDWR|O_NDELAY|O_NOCTTY> from the |
252 | Fcntl module (part of the standard perl distribution). See |
253 | L<perlfunc/"sysopen"> for more on this approach. |
254 | |
255 | =item end of line |
256 | |
257 | Some devices will be expecting a "\r" at the end of each line rather |
258 | than a "\n". In some ports of perl, "\r" and "\n" are different from |
259 | their usual (Unix) ASCII values of "\012" and "\015". You may have to |
260 | give the numeric values you want directly, using octal ("\015"), hex |
261 | ("0x0D"), or as a control-character specification ("\cM"). |
262 | |
263 | print DEV "atv1\012"; # wrong, for some devices |
264 | print DEV "atv1\015"; # right, for some devices |
265 | |
266 | Even though with normal text files, a "\n" will do the trick, there is |
267 | still no unified scheme for terminating a line that is portable |
46fc3d4c |
268 | between Unix, DOS/Win, and Macintosh, except to terminate I<ALL> line |
68dc0745 |
269 | ends with "\015\012", and strip what you don't need from the output. |
270 | This applies especially to socket I/O and autoflushing, discussed |
271 | next. |
272 | |
273 | =item flushing output |
274 | |
275 | If you expect characters to get to your device when you print() them, |
c8db1d39 |
276 | you'll want to autoflush that filehandle. You can use select() |
277 | and the C<$|> variable to control autoflushing (see L<perlvar/$|> |
278 | and L<perlfunc/select>): |
68dc0745 |
279 | |
280 | $oldh = select(DEV); |
281 | $| = 1; |
282 | select($oldh); |
283 | |
284 | You'll also see code that does this without a temporary variable, as in |
285 | |
286 | select((select(DEV), $| = 1)[0]); |
287 | |
c8db1d39 |
288 | Or if you don't mind pulling in a few thousand lines |
289 | of code just because you're afraid of a little $| variable: |
290 | |
291 | use IO::Handle; |
292 | DEV->autoflush(1); |
293 | |
68dc0745 |
294 | As mentioned in the previous item, this still doesn't work when using |
295 | socket I/O between Unix and Macintosh. You'll need to hardcode your |
296 | line terminators, in that case. |
297 | |
298 | =item non-blocking input |
299 | |
300 | If you are doing a blocking read() or sysread(), you'll have to |
301 | arrange for an alarm handler to provide a timeout (see |
302 | L<perlfunc/alarm>). If you have a non-blocking open, you'll likely |
303 | have a non-blocking read, which means you may have to use a 4-arg |
304 | select() to determine whether I/O is ready on that device (see |
305 | L<perlfunc/"select">. |
306 | |
307 | =back |
308 | |
c8db1d39 |
309 | While trying to read from his caller-id box, the notorious Jamie Zawinski |
310 | <jwz@netscape.com>, after much gnashing of teeth and fighting with sysread, |
311 | sysopen, POSIX's tcgetattr business, and various other functions that |
312 | go bump in the night, finally came up with this: |
313 | |
314 | sub open_modem { |
315 | use IPC::Open2; |
316 | my $stty = `/bin/stty -g`; |
317 | open2( \*MODEM_IN, \*MODEM_OUT, "cu -l$modem_device -s2400 2>&1"); |
318 | # starting cu hoses /dev/tty's stty settings, even when it has |
319 | # been opened on a pipe... |
320 | system("/bin/stty $stty"); |
321 | $_ = <MODEM_IN>; |
322 | chop; |
323 | if ( !m/^Connected/ ) { |
324 | print STDERR "$0: cu printed `$_' instead of `Connected'\n"; |
325 | } |
326 | } |
327 | |
68dc0745 |
328 | =head2 How do I decode encrypted password files? |
329 | |
330 | You spend lots and lots of money on dedicated hardware, but this is |
331 | bound to get you talked about. |
332 | |
333 | Seriously, you can't if they are Unix password files - the Unix |
c8db1d39 |
334 | password system employs one-way encryption. It's more like hashing than |
335 | encryption. The best you can check is whether something else hashes to |
336 | the same string. You can't turn a hash back into the original string. |
337 | Programs like Crack |
338 | can forcibly (and intelligently) try to guess passwords, but don't |
339 | (can't) guarantee quick success. |
68dc0745 |
340 | |
341 | If you're worried about users selecting bad passwords, you should |
342 | proactively check when they try to change their password (by modifying |
343 | passwd(1), for example). |
344 | |
345 | =head2 How do I start a process in the background? |
346 | |
347 | You could use |
348 | |
349 | system("cmd &") |
350 | |
351 | or you could use fork as documented in L<perlfunc/"fork">, with |
352 | further examples in L<perlipc>. Some things to be aware of, if you're |
353 | on a Unix-like system: |
354 | |
355 | =over 4 |
356 | |
c8db1d39 |
357 | =item STDIN, STDOUT, and STDERR are shared |
68dc0745 |
358 | |
359 | Both the main process and the backgrounded one (the "child" process) |
360 | share the same STDIN, STDOUT and STDERR filehandles. If both try to |
361 | access them at once, strange things can happen. You may want to close |
362 | or reopen these for the child. You can get around this with |
363 | C<open>ing a pipe (see L<perlfunc/"open">) but on some systems this |
364 | means that the child process cannot outlive the parent. |
365 | |
366 | =item Signals |
367 | |
368 | You'll have to catch the SIGCHLD signal, and possibly SIGPIPE too. |
369 | SIGCHLD is sent when the backgrounded process finishes. SIGPIPE is |
370 | sent when you write to a filehandle whose child process has closed (an |
371 | untrapped SIGPIPE can cause your program to silently die). This is |
372 | not an issue with C<system("cmd&")>. |
373 | |
374 | =item Zombies |
375 | |
376 | You have to be prepared to "reap" the child process when it finishes |
377 | |
378 | $SIG{CHLD} = sub { wait }; |
379 | |
380 | See L<perlipc/"Signals"> for other examples of code to do this. |
381 | Zombies are not an issue with C<system("prog &")>. |
382 | |
383 | =back |
384 | |
385 | =head2 How do I trap control characters/signals? |
386 | |
c8db1d39 |
387 | You don't actually "trap" a control character. Instead, that character |
388 | generates a signal which is sent to your terminal's currently |
389 | foregrounded process group, which you then trap in your process. |
390 | Signals are documented in L<perlipc/"Signals"> and chapter 6 of the Camel. |
68dc0745 |
391 | |
46fc3d4c |
392 | Be warned that very few C libraries are re-entrant. Therefore, if you |
68dc0745 |
393 | attempt to print() in a handler that got invoked during another stdio |
394 | operation your internal structures will likely be in an |
395 | inconsistent state, and your program will dump core. You can |
396 | sometimes avoid this by using syswrite() instead of print(). |
397 | |
398 | Unless you're exceedingly careful, the only safe things to do inside a |
399 | signal handler are: set a variable and exit. And in the first case, |
400 | you should only set a variable in such a way that malloc() is not |
401 | called (eg, by setting a variable that already has a value). |
402 | |
403 | For example: |
404 | |
405 | $Interrupted = 0; # to ensure it has a value |
406 | $SIG{INT} = sub { |
407 | $Interrupted++; |
408 | syswrite(STDERR, "ouch\n", 5); |
409 | } |
410 | |
411 | However, because syscalls restart by default, you'll find that if |
412 | you're in a "slow" call, such as E<lt>FHE<gt>, read(), connect(), or |
413 | wait(), that the only way to terminate them is by "longjumping" out; |
46fc3d4c |
414 | that is, by raising an exception. See the time-out handler for a |
68dc0745 |
415 | blocking flock() in L<perlipc/"Signals"> or chapter 6 of the Camel. |
416 | |
417 | =head2 How do I modify the shadow password file on a Unix system? |
418 | |
c8db1d39 |
419 | If perl was installed correctly, and your shadow library was written |
420 | properly, the getpw*() functions described in L<perlfunc> should in |
421 | theory provide (read-only) access to entries in the shadow password |
422 | file. To change the file, make a new shadow password file (the format |
423 | varies from system to system - see L<passwd(5)> for specifics) and use |
68dc0745 |
424 | pwd_mkdb(8) to install it (see L<pwd_mkdb(5)> for more details). |
425 | |
426 | =head2 How do I set the time and date? |
427 | |
428 | Assuming you're running under sufficient permissions, you should be |
429 | able to set the system-wide date and time by running the date(1) |
430 | program. (There is no way to set the time and date on a per-process |
431 | basis.) This mechanism will work for Unix, MS-DOS, Windows, and NT; |
432 | the VMS equivalent is C<set time>. |
433 | |
434 | However, if all you want to do is change your timezone, you can |
435 | probably get away with setting an environment variable: |
436 | |
437 | $ENV{TZ} = "MST7MDT"; # unixish |
438 | $ENV{'SYS$TIMEZONE_DIFFERENTIAL'}="-5" # vms |
c8db1d39 |
439 | system "trn comp.lang.perl.misc"; |
68dc0745 |
440 | |
441 | =head2 How can I sleep() or alarm() for under a second? |
442 | |
443 | If you want finer granularity than the 1 second that the sleep() |
444 | function provides, the easiest way is to use the select() function as |
445 | documented in L<perlfunc/"select">. If your system has itimers and |
446 | syscall() support, you can check out the old example in |
447 | http://www.perl.com/CPAN/doc/misc/ancient/tutorial/eg/itimers.pl . |
448 | |
449 | =head2 How can I measure time under a second? |
450 | |
65acb1b1 |
451 | In general, you may not be able to. The Time::HiRes module (available |
452 | from CPAN) provides this functionality for some systems. |
68dc0745 |
453 | |
65acb1b1 |
454 | If your system supports both the syscall() function in Perl as well as |
455 | a system call like gettimeofday(2), then you may be able to do |
456 | something like this: |
68dc0745 |
457 | |
458 | require 'sys/syscall.ph'; |
459 | |
460 | $TIMEVAL_T = "LL"; |
461 | |
462 | $done = $start = pack($TIMEVAL_T, ()); |
463 | |
65acb1b1 |
464 | syscall( &SYS_gettimeofday, $start, 0) != -1 |
68dc0745 |
465 | or die "gettimeofday: $!"; |
466 | |
467 | ########################## |
468 | # DO YOUR OPERATION HERE # |
469 | ########################## |
470 | |
471 | syscall( &SYS_gettimeofday, $done, 0) != -1 |
472 | or die "gettimeofday: $!"; |
473 | |
474 | @start = unpack($TIMEVAL_T, $start); |
475 | @done = unpack($TIMEVAL_T, $done); |
476 | |
477 | # fix microseconds |
478 | for ($done[1], $start[1]) { $_ /= 1_000_000 } |
479 | |
480 | $delta_time = sprintf "%.4f", ($done[0] + $done[1] ) |
481 | - |
482 | ($start[0] + $start[1] ); |
483 | |
484 | =head2 How can I do an atexit() or setjmp()/longjmp()? (Exception handling) |
485 | |
486 | Release 5 of Perl added the END block, which can be used to simulate |
487 | atexit(). Each package's END block is called when the program or |
c8db1d39 |
488 | thread ends (see L<perlmod> manpage for more details). |
489 | |
490 | For example, you can use this to make sure your filter program |
491 | managed to finish its output without filling up the disk: |
492 | |
493 | END { |
494 | close(STDOUT) || die "stdout close failed: $!"; |
495 | } |
496 | |
497 | The END block isn't called when untrapped signals kill the program, though, so if |
498 | you use END blocks you should also use |
68dc0745 |
499 | |
500 | use sigtrap qw(die normal-signals); |
501 | |
502 | Perl's exception-handling mechanism is its eval() operator. You can |
503 | use eval() as setjmp and die() as longjmp. For details of this, see |
46fc3d4c |
504 | the section on signals, especially the time-out handler for a blocking |
68dc0745 |
505 | flock() in L<perlipc/"Signals"> and chapter 6 of the Camel. |
506 | |
507 | If exception handling is all you're interested in, try the |
508 | exceptions.pl library (part of the standard perl distribution). |
509 | |
510 | If you want the atexit() syntax (and an rmexit() as well), try the |
511 | AtExit module available from CPAN. |
512 | |
513 | =head2 Why doesn't my sockets program work under System V (Solaris)? What does the error message "Protocol not supported" mean? |
514 | |
515 | Some Sys-V based systems, notably Solaris 2.X, redefined some of the |
516 | standard socket constants. Since these were constant across all |
517 | architectures, they were often hardwired into perl code. The proper |
518 | way to deal with this is to "use Socket" to get the correct values. |
519 | |
520 | Note that even though SunOS and Solaris are binary compatible, these |
521 | values are different. Go figure. |
522 | |
523 | =head2 How can I call my system's unique C functions from Perl? |
524 | |
525 | In most cases, you write an external module to do it - see the answer |
526 | to "Where can I learn about linking C with Perl? [h2xs, xsubpp]". |
527 | However, if the function is a system call, and your system supports |
528 | syscall(), you can use the syscall function (documented in |
529 | L<perlfunc>). |
530 | |
531 | Remember to check the modules that came with your distribution, and |
532 | CPAN as well - someone may already have written a module to do it. |
533 | |
534 | =head2 Where do I get the include files to do ioctl() or syscall()? |
535 | |
536 | Historically, these would be generated by the h2ph tool, part of the |
537 | standard perl distribution. This program converts cpp(1) directives |
538 | in C header files to files containing subroutine definitions, like |
539 | &SYS_getitimer, which you can use as arguments to your functions. |
540 | It doesn't work perfectly, but it usually gets most of the job done. |
541 | Simple files like F<errno.h>, F<syscall.h>, and F<socket.h> were fine, |
542 | but the hard ones like F<ioctl.h> nearly always need to hand-edited. |
543 | Here's how to install the *.ph files: |
544 | |
46fc3d4c |
545 | 1. become super-user |
68dc0745 |
546 | 2. cd /usr/include |
547 | 3. h2ph *.h */*.h |
548 | |
549 | If your system supports dynamic loading, for reasons of portability and |
550 | sanity you probably ought to use h2xs (also part of the standard perl |
551 | distribution). This tool converts C header files to Perl extensions. |
552 | See L<perlxstut> for how to get started with h2xs. |
553 | |
554 | If your system doesn't support dynamic loading, you still probably |
555 | ought to use h2xs. See L<perlxstut> and L<ExtUtils::MakeMaker> for |
556 | more information (in brief, just use B<make perl> instead of a plain |
557 | B<make> to rebuild perl with a new static extension). |
558 | |
559 | =head2 Why do setuid perl scripts complain about kernel problems? |
560 | |
561 | Some operating systems have bugs in the kernel that make setuid |
562 | scripts inherently insecure. Perl gives you a number of options |
563 | (described in L<perlsec>) to work around such systems. |
564 | |
565 | =head2 How can I open a pipe both to and from a command? |
566 | |
567 | The IPC::Open2 module (part of the standard perl distribution) is an |
c8db1d39 |
568 | easy-to-use approach that internally uses pipe(), fork(), and exec() to do |
569 | the job. Make sure you read the deadlock warnings in its documentation, |
570 | though (see L<IPC::Open2>). See L<perlipc/"Bidirectional Communication |
571 | with Another Process"> and L<perlipc/"Bidirectional Communication with |
572 | Yourself"> |
573 | |
574 | You may also use the IPC::Open3 module (part of the standard perl |
575 | distribution), but be warned that it has a different order of |
576 | arguments from IPC::Open2 (see L<IPC::Open3>). |
68dc0745 |
577 | |
3fe9a6f1 |
578 | =head2 Why can't I get the output of a command with system()? |
579 | |
46fc3d4c |
580 | You're confusing the purpose of system() and backticks (``). system() |
581 | runs a command and returns exit status information (as a 16 bit value: |
c8db1d39 |
582 | the low 7 bits are the signal the process died from, if any, and |
46fc3d4c |
583 | the high 8 bits are the actual exit value). Backticks (``) run a |
3fe9a6f1 |
584 | command and return what it sent to STDOUT. |
585 | |
46fc3d4c |
586 | $exit_status = system("mail-users"); |
587 | $output_string = `ls`; |
3fe9a6f1 |
588 | |
68dc0745 |
589 | =head2 How can I capture STDERR from an external command? |
590 | |
591 | There are three basic ways of running external commands: |
592 | |
593 | system $cmd; # using system() |
594 | $output = `$cmd`; # using backticks (``) |
595 | open (PIPE, "cmd |"); # using open() |
596 | |
597 | With system(), both STDOUT and STDERR will go the same place as the |
598 | script's versions of these, unless the command redirects them. |
599 | Backticks and open() read B<only> the STDOUT of your command. |
600 | |
601 | With any of these, you can change file descriptors before the call: |
602 | |
603 | open(STDOUT, ">logfile"); |
604 | system("ls"); |
605 | |
606 | or you can use Bourne shell file-descriptor redirection: |
607 | |
608 | $output = `$cmd 2>some_file`; |
609 | open (PIPE, "cmd 2>some_file |"); |
610 | |
611 | You can also use file-descriptor redirection to make STDERR a |
612 | duplicate of STDOUT: |
613 | |
614 | $output = `$cmd 2>&1`; |
615 | open (PIPE, "cmd 2>&1 |"); |
616 | |
617 | Note that you I<cannot> simply open STDERR to be a dup of STDOUT |
618 | in your Perl program and avoid calling the shell to do the redirection. |
619 | This doesn't work: |
620 | |
621 | open(STDERR, ">&STDOUT"); |
622 | $alloutput = `cmd args`; # stderr still escapes |
623 | |
624 | This fails because the open() makes STDERR go to where STDOUT was |
625 | going at the time of the open(). The backticks then make STDOUT go to |
626 | a string, but don't change STDERR (which still goes to the old |
627 | STDOUT). |
628 | |
629 | Note that you I<must> use Bourne shell (sh(1)) redirection syntax in |
630 | backticks, not csh(1)! Details on why Perl's system() and backtick |
631 | and pipe opens all use the Bourne shell are in |
632 | http://www.perl.com/CPAN/doc/FMTEYEWTK/versus/csh.whynot . |
c8db1d39 |
633 | To capture a command's STDERR and STDOUT together: |
68dc0745 |
634 | |
c8db1d39 |
635 | $output = `cmd 2>&1`; # either with backticks |
636 | $pid = open(PH, "cmd 2>&1 |"); # or with an open pipe |
637 | while (<PH>) { } # plus a read |
638 | |
639 | To capture a command's STDOUT but discard its STDERR: |
640 | |
641 | $output = `cmd 2>/dev/null`; # either with backticks |
642 | $pid = open(PH, "cmd 2>/dev/null |"); # or with an open pipe |
643 | while (<PH>) { } # plus a read |
644 | |
645 | To capture a command's STDERR but discard its STDOUT: |
646 | |
647 | $output = `cmd 2>&1 1>/dev/null`; # either with backticks |
648 | $pid = open(PH, "cmd 2>&1 1>/dev/null |"); # or with an open pipe |
649 | while (<PH>) { } # plus a read |
650 | |
651 | To exchange a command's STDOUT and STDERR in order to capture the STDERR |
652 | but leave its STDOUT to come out our old STDERR: |
653 | |
654 | $output = `cmd 3>&1 1>&2 2>&3 3>&-`; # either with backticks |
655 | $pid = open(PH, "cmd 3>&1 1>&2 2>&3 3>&-|");# or with an open pipe |
656 | while (<PH>) { } # plus a read |
657 | |
658 | To read both a command's STDOUT and its STDERR separately, it's easiest |
659 | and safest to redirect them separately to files, and then read from those |
660 | files when the program is done: |
661 | |
662 | system("program args 1>/tmp/program.stdout 2>/tmp/program.stderr"); |
663 | |
664 | Ordering is important in all these examples. That's because the shell |
665 | processes file descriptor redirections in strictly left to right order. |
666 | |
667 | system("prog args 1>tmpfile 2>&1"); |
668 | system("prog args 2>&1 1>tmpfile"); |
669 | |
670 | The first command sends both standard out and standard error to the |
671 | temporary file. The second command sends only the old standard output |
672 | there, and the old standard error shows up on the old standard out. |
68dc0745 |
673 | |
674 | =head2 Why doesn't open() return an error when a pipe open fails? |
675 | |
65acb1b1 |
676 | Because the pipe open takes place in two steps: first Perl calls |
677 | fork() to start a new process, then this new process calls exec() to |
678 | run the program you really wanted to open. The first step reports |
679 | success or failure to your process, so open() can only tell you |
680 | whether the fork() succeeded or not. |
681 | |
682 | To find out if the exec() step succeeded, you have to catch SIGCHLD |
683 | and wait() to get the exit status. You should also catch SIGPIPE if |
684 | you're writing to the child--you may not have found out the exec() |
3fe9a6f1 |
685 | failed by the time you write. This is documented in L<perlipc>. |
68dc0745 |
686 | |
65acb1b1 |
687 | In some cases, even this won't work. If the second argument to a |
688 | piped open() contains shell metacharacters, perl fork()s, then exec()s |
689 | a shell to decode the metacharacters and eventually run the desired |
690 | program. Now when you call wait(), you only learn whether or not the |
691 | I<shell> could be successfully started. Best to avoid shell |
692 | metacharacters. |
693 | |
68dc0745 |
694 | On systems that follow the spawn() paradigm, open() I<might> do what |
65acb1b1 |
695 | you expect--unless perl uses a shell to start your command. In this |
68dc0745 |
696 | case the fork()/exec() description still applies. |
697 | |
698 | =head2 What's wrong with using backticks in a void context? |
699 | |
700 | Strictly speaking, nothing. Stylistically speaking, it's not a good |
701 | way to write maintainable code because backticks have a (potentially |
702 | humungous) return value, and you're ignoring it. It's may also not be very |
703 | efficient, because you have to read in all the lines of output, allocate |
704 | memory for them, and then throw it away. Too often people are lulled |
705 | to writing: |
706 | |
707 | `cp file file.bak`; |
708 | |
709 | And now they think "Hey, I'll just always use backticks to run programs." |
710 | Bad idea: backticks are for capturing a program's output; the system() |
711 | function is for running programs. |
712 | |
713 | Consider this line: |
714 | |
715 | `cat /etc/termcap`; |
716 | |
717 | You haven't assigned the output anywhere, so it just wastes memory |
718 | (for a little while). Plus you forgot to check C<$?> to see whether |
719 | the program even ran correctly. Even if you wrote |
720 | |
721 | print `cat /etc/termcap`; |
722 | |
723 | In most cases, this could and probably should be written as |
724 | |
725 | system("cat /etc/termcap") == 0 |
726 | or die "cat program failed!"; |
727 | |
728 | Which will get the output quickly (as its generated, instead of only |
c8db1d39 |
729 | at the end) and also check the return value. |
68dc0745 |
730 | |
731 | system() also provides direct control over whether shell wildcard |
732 | processing may take place, whereas backticks do not. |
733 | |
734 | =head2 How can I call backticks without shell processing? |
735 | |
736 | This is a bit tricky. Instead of writing |
737 | |
738 | @ok = `grep @opts '$search_string' @filenames`; |
739 | |
740 | You have to do this: |
741 | |
742 | my @ok = (); |
743 | if (open(GREP, "-|")) { |
744 | while (<GREP>) { |
745 | chomp; |
746 | push(@ok, $_); |
747 | } |
748 | close GREP; |
749 | } else { |
750 | exec 'grep', @opts, $search_string, @filenames; |
751 | } |
752 | |
753 | Just as with system(), no shell escapes happen when you exec() a list. |
754 | |
c8db1d39 |
755 | There are more examples of this L<perlipc/"Safe Pipe Opens">. |
756 | |
54310121 |
757 | =head2 Why can't my script read from STDIN after I gave it EOF (^D on Unix, ^Z on MS-DOS)? |
68dc0745 |
758 | |
759 | Because some stdio's set error and eof flags that need clearing. The |
760 | POSIX module defines clearerr() that you can use. That is the |
761 | technically correct way to do it. Here are some less reliable |
762 | workarounds: |
763 | |
764 | =over 4 |
765 | |
766 | =item 1 |
767 | |
768 | Try keeping around the seekpointer and go there, like this: |
769 | |
770 | $where = tell(LOG); |
771 | seek(LOG, $where, 0); |
772 | |
773 | =item 2 |
774 | |
775 | If that doesn't work, try seeking to a different part of the file and |
776 | then back. |
777 | |
778 | =item 3 |
779 | |
780 | If that doesn't work, try seeking to a different part of |
781 | the file, reading something, and then seeking back. |
782 | |
783 | =item 4 |
784 | |
785 | If that doesn't work, give up on your stdio package and use sysread. |
786 | |
787 | =back |
788 | |
789 | =head2 How can I convert my shell script to perl? |
790 | |
791 | Learn Perl and rewrite it. Seriously, there's no simple converter. |
792 | Things that are awkward to do in the shell are easy to do in Perl, and |
793 | this very awkwardness is what would make a shell->perl converter |
794 | nigh-on impossible to write. By rewriting it, you'll think about what |
795 | you're really trying to do, and hopefully will escape the shell's |
46fc3d4c |
796 | pipeline datastream paradigm, which while convenient for some matters, |
68dc0745 |
797 | causes many inefficiencies. |
798 | |
799 | =head2 Can I use perl to run a telnet or ftp session? |
800 | |
46fc3d4c |
801 | Try the Net::FTP, TCP::Client, and Net::Telnet modules (available from |
802 | CPAN). http://www.perl.com/CPAN/scripts/netstuff/telnet.emul.shar |
803 | will also help for emulating the telnet protocol, but Net::Telnet is |
804 | quite probably easier to use.. |
805 | |
806 | If all you want to do is pretend to be telnet but don't need |
807 | the initial telnet handshaking, then the standard dual-process |
808 | approach will suffice: |
809 | |
810 | use IO::Socket; # new in 5.004 |
811 | $handle = IO::Socket::INET->new('www.perl.com:80') |
812 | || die "can't connect to port 80 on www.perl.com: $!"; |
813 | $handle->autoflush(1); |
814 | if (fork()) { # XXX: undef means failure |
815 | select($handle); |
816 | print while <STDIN>; # everything from stdin to socket |
817 | } else { |
818 | print while <$handle>; # everything from socket to stdout |
819 | } |
820 | close $handle; |
821 | exit; |
68dc0745 |
822 | |
823 | =head2 How can I write expect in Perl? |
824 | |
825 | Once upon a time, there was a library called chat2.pl (part of the |
c8db1d39 |
826 | standard perl distribution), which never really got finished. If you |
827 | find it somewhere, I<don't use it>. These days, your best bet is to |
828 | look at the Expect module available from CPAN, which also requires two |
829 | other modules from CPAN, IO::Pty and IO::Stty. |
68dc0745 |
830 | |
831 | =head2 Is there a way to hide perl's command line from programs such as "ps"? |
832 | |
833 | First of all note that if you're doing this for security reasons (to |
834 | avoid people seeing passwords, for example) then you should rewrite |
835 | your program so that critical information is never given as an |
836 | argument. Hiding the arguments won't make your program completely |
837 | secure. |
838 | |
839 | To actually alter the visible command line, you can assign to the |
840 | variable $0 as documented in L<perlvar>. This won't work on all |
841 | operating systems, though. Daemon programs like sendmail place their |
842 | state there, as in: |
843 | |
844 | $0 = "orcus [accepting connections]"; |
845 | |
846 | =head2 I {changed directory, modified my environment} in a perl script. How come the change disappeared when I exited the script? How do I get my changes to be visible? |
847 | |
848 | =over 4 |
849 | |
850 | =item Unix |
851 | |
852 | In the strictest sense, it can't be done -- the script executes as a |
853 | different process from the shell it was started from. Changes to a |
854 | process are not reflected in its parent, only in its own children |
855 | created after the change. There is shell magic that may allow you to |
856 | fake it by eval()ing the script's output in your shell; check out the |
92c2ed05 |
857 | comp.unix.questions FAQ for details. |
68dc0745 |
858 | |
68dc0745 |
859 | =back |
860 | |
861 | =head2 How do I close a process's filehandle without waiting for it to complete? |
862 | |
863 | Assuming your system supports such things, just send an appropriate signal |
864 | to the process (see L<perlfunc/"kill">. It's common to first send a TERM |
865 | signal, wait a little bit, and then send a KILL signal to finish it off. |
866 | |
867 | =head2 How do I fork a daemon process? |
868 | |
869 | If by daemon process you mean one that's detached (disassociated from |
870 | its tty), then the following process is reported to work on most |
871 | Unixish systems. Non-Unix users should check their Your_OS::Process |
872 | module for other solutions. |
873 | |
874 | =over 4 |
875 | |
876 | =item * |
877 | |
b5a41e52 |
878 | Open /dev/tty and use the TIOCNOTTY ioctl on it. See L<tty(4)> |
c8db1d39 |
879 | for details. Or better yet, you can just use the POSIX::setsid() |
880 | function, so you don't have to worry about process groups. |
68dc0745 |
881 | |
882 | =item * |
883 | |
884 | Change directory to / |
885 | |
886 | =item * |
887 | |
888 | Reopen STDIN, STDOUT, and STDERR so they're not connected to the old |
889 | tty. |
890 | |
891 | =item * |
892 | |
893 | Background yourself like this: |
894 | |
895 | fork && exit; |
896 | |
897 | =back |
898 | |
899 | =head2 How do I make my program run with sh and csh? |
900 | |
901 | See the F<eg/nih> script (part of the perl source distribution). |
902 | |
68dc0745 |
903 | =head2 How do I find out if I'm running interactively or not? |
904 | |
905 | Good question. Sometimes C<-t STDIN> and C<-t STDOUT> can give clues, |
906 | sometimes not. |
907 | |
908 | if (-t STDIN && -t STDOUT) { |
909 | print "Now what? "; |
910 | } |
911 | |
912 | On POSIX systems, you can test whether your own process group matches |
913 | the current process group of your controlling terminal as follows: |
914 | |
915 | use POSIX qw/getpgrp tcgetpgrp/; |
916 | open(TTY, "/dev/tty") or die $!; |
65acb1b1 |
917 | $tpgrp = tcgetpgrp(fileno(*TTY)); |
68dc0745 |
918 | $pgrp = getpgrp(); |
919 | if ($tpgrp == $pgrp) { |
920 | print "foreground\n"; |
921 | } else { |
922 | print "background\n"; |
923 | } |
924 | |
925 | =head2 How do I timeout a slow event? |
926 | |
927 | Use the alarm() function, probably in conjunction with a signal |
928 | handler, as documented L<perlipc/"Signals"> and chapter 6 of the |
929 | Camel. You may instead use the more flexible Sys::AlarmCall module |
930 | available from CPAN. |
931 | |
932 | =head2 How do I set CPU limits? |
933 | |
934 | Use the BSD::Resource module from CPAN. |
935 | |
936 | =head2 How do I avoid zombies on a Unix system? |
937 | |
938 | Use the reaper code from L<perlipc/"Signals"> to call wait() when a |
939 | SIGCHLD is received, or else use the double-fork technique described |
940 | in L<perlfunc/fork>. |
941 | |
942 | =head2 How do I use an SQL database? |
943 | |
944 | There are a number of excellent interfaces to SQL databases. See the |
945 | DBD::* modules available from |
946 | http://www.perl.com/CPAN/modules/dbperl/DBD . |
c8db1d39 |
947 | A lot of information on this can be found at |
948 | http://www.hermetica.com/technologia/perl/DBI/index.html . |
68dc0745 |
949 | |
950 | =head2 How do I make a system() exit on control-C? |
951 | |
952 | You can't. You need to imitate the system() call (see L<perlipc> for |
953 | sample code) and then have a signal handler for the INT signal that |
c8db1d39 |
954 | passes the signal on to the subprocess. Or you can check for it: |
955 | |
956 | $rc = system($cmd); |
957 | if ($rc & 127) { die "signal death" } |
68dc0745 |
958 | |
959 | =head2 How do I open a file without blocking? |
960 | |
961 | If you're lucky enough to be using a system that supports |
962 | non-blocking reads (most Unixish systems do), you need only to use the |
963 | O_NDELAY or O_NONBLOCK flag from the Fcntl module in conjunction with |
964 | sysopen(): |
965 | |
966 | use Fcntl; |
967 | sysopen(FH, "/tmp/somefile", O_WRONLY|O_NDELAY|O_CREAT, 0644) |
968 | or die "can't open /tmp/somefile: $!": |
969 | |
970 | =head2 How do I install a CPAN module? |
971 | |
972 | The easiest way is to have the CPAN module do it for you. This module |
973 | comes with perl version 5.004 and later. To manually install the CPAN |
974 | module, or any well-behaved CPAN module for that matter, follow these |
975 | steps: |
976 | |
977 | =over 4 |
978 | |
979 | =item 1 |
980 | |
981 | Unpack the source into a temporary area. |
982 | |
983 | =item 2 |
984 | |
985 | perl Makefile.PL |
986 | |
987 | =item 3 |
988 | |
989 | make |
990 | |
991 | =item 4 |
992 | |
993 | make test |
994 | |
995 | =item 5 |
996 | |
997 | make install |
998 | |
999 | =back |
1000 | |
1001 | If your version of perl is compiled without dynamic loading, then you |
1002 | just need to replace step 3 (B<make>) with B<make perl> and you will |
1003 | get a new F<perl> binary with your extension linked in. |
1004 | |
c8db1d39 |
1005 | See L<ExtUtils::MakeMaker> for more details on building extensions. |
1006 | See also the next question. |
1007 | |
1008 | =head2 What's the difference between require and use? |
1009 | |
1010 | Perl offers several different ways to include code from one file into |
1011 | another. Here are the deltas between the various inclusion constructs: |
1012 | |
1013 | 1) do $file is like eval `cat $file`, except the former: |
5e3006a4 |
1014 | 1.1: searches @INC and updates %INC. |
c8db1d39 |
1015 | 1.2: bequeaths an *unrelated* lexical scope on the eval'ed code. |
1016 | |
1017 | 2) require $file is like do $file, except the former: |
1018 | 2.1: checks for redundant loading, skipping already loaded files. |
1019 | 2.2: raises an exception on failure to find, compile, or execute $file. |
1020 | |
1021 | 3) require Module is like require "Module.pm", except the former: |
1022 | 3.1: translates each "::" into your system's directory separator. |
1023 | 3.2: primes the parser to disambiguate class Module as an indirect object. |
1024 | |
1025 | 4) use Module is like require Module, except the former: |
1026 | 4.1: loads the module at compile time, not run-time. |
1027 | 4.2: imports symbols and semantics from that package to the current one. |
1028 | |
1029 | In general, you usually want C<use> and a proper Perl module. |
46fc3d4c |
1030 | |
1031 | =head2 How do I keep my own module/library directory? |
1032 | |
1033 | When you build modules, use the PREFIX option when generating |
1034 | Makefiles: |
1035 | |
1036 | perl Makefile.PL PREFIX=/u/mydir/perl |
1037 | |
1038 | then either set the PERL5LIB environment variable before you run |
1039 | scripts that use the modules/libraries (see L<perlrun>) or say |
1040 | |
1041 | use lib '/u/mydir/perl'; |
1042 | |
65acb1b1 |
1043 | This is almost the same as: |
1044 | |
1045 | BEGIN { |
1046 | unshift(@INC, '/u/mydir/perl'); |
1047 | } |
1048 | |
1049 | except that the lib module checks for machine-dependent subdirectories. |
46fc3d4c |
1050 | See Perl's L<lib> for more information. |
1051 | |
1052 | =head2 How do I add the directory my program lives in to the module/library search path? |
1053 | |
1054 | use FindBin; |
7b8d334a |
1055 | use lib "$FindBin::Bin"; |
46fc3d4c |
1056 | use your_own_modules; |
1057 | |
1058 | =head2 How do I add a directory to my include path at runtime? |
1059 | |
1060 | Here are the suggested ways of modifying your include path: |
1061 | |
1062 | the PERLLIB environment variable |
1063 | the PERL5LIB environment variable |
1064 | the perl -Idir commpand line flag |
1065 | the use lib pragma, as in |
1066 | use lib "$ENV{HOME}/myown_perllib"; |
1067 | |
1068 | The latter is particularly useful because it knows about machine |
1069 | dependent architectures. The lib.pm pragmatic module was first |
1070 | included with the 5.002 release of Perl. |
68dc0745 |
1071 | |
65acb1b1 |
1072 | =head2 What is socket.ph and where do I get it? |
1073 | |
1074 | It's a perl4-style file defining values for system networking |
1075 | constants. Sometimes it is built using h2ph when Perl is installed, |
1076 | but other times it is not. Modern programs C<use Socket;> instead. |
1077 | |
fc36a67e |
1078 | =head1 AUTHOR AND COPYRIGHT |
1079 | |
65acb1b1 |
1080 | Copyright (c) 1997-1999 Tom Christiansen and Nathan Torkington. |
5a964f20 |
1081 | All rights reserved. |
1082 | |
1083 | When included as part of the Standard Version of Perl, or as part of |
1084 | its complete documentation whether printed or otherwise, this work |
1085 | may be distributed only under the terms of Perl's Artistic License. |
1086 | Any distribution of this file or derivatives thereof I<outside> |
1087 | of that package require that special arrangements be made with |
1088 | copyright holder. |
1089 | |
1090 | Irrespective of its distribution, all code examples in this file |
1091 | are hereby placed into the public domain. You are permitted and |
1092 | encouraged to use this code in your own programs for fun |
1093 | or for profit as you see fit. A simple comment in the code giving |
1094 | credit would be courteous but is not required. |
65acb1b1 |
1095 | |