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