Commit | Line | Data |
68dc0745 |
1 | =head1 NAME |
2 | |
3 | perlfaq8 - System Interaction ($Revision: 1.15 $) |
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 |
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 ($OSTYPE if you use English) contains the operating |
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 | |
55 | =head2 How do I ask the user for a password? |
56 | |
57 | (This question has nothing to do with the web. See a different |
58 | FAQ for that.) |
59 | |
60 | There's an example of this in L<perlfunc/crypt>). First, you put |
61 | the terminal into "no echo" mode, then just read the password |
62 | normally. You may do this with an old-style ioctl() function, POSIX |
63 | terminal control (see L<POSIX>, and Chapter 7 of the Camel), or a call |
64 | to the B<stty> program, with varying degrees of portability. |
65 | |
66 | You can also do this for most systems using the Term::ReadKey module |
67 | from CPAN, which is easier to use and in theory more portable. |
68 | |
69 | =head2 How do I read and write the serial port? |
70 | |
71 | This depends on which operating system your program is running on. In |
72 | the case of Unix, the serial ports will be accessible through files in |
73 | /dev; on other systems, the devices names will doubtless differ. |
74 | Several problem areas common to all device interaction are the |
75 | following |
76 | |
77 | =over 4 |
78 | |
79 | =item lockfiles |
80 | |
81 | Your system may use lockfiles to control multiple access. Make sure |
82 | you follow the correct protocol. Unpredictable behaviour can result |
83 | from multiple processes reading from one device. |
84 | |
85 | =item open mode |
86 | |
87 | If you expect to use both read and write operations on the device, |
88 | you'll have to open it for update (see L<perlfunc/"open"> for |
89 | details). You may wish to open it without running the risk of |
90 | blocking by using sysopen() and C<O_RDWR|O_NDELAY|O_NOCTTY> from the |
91 | Fcntl module (part of the standard perl distribution). See |
92 | L<perlfunc/"sysopen"> for more on this approach. |
93 | |
94 | =item end of line |
95 | |
96 | Some devices will be expecting a "\r" at the end of each line rather |
97 | than a "\n". In some ports of perl, "\r" and "\n" are different from |
98 | their usual (Unix) ASCII values of "\012" and "\015". You may have to |
99 | give the numeric values you want directly, using octal ("\015"), hex |
100 | ("0x0D"), or as a control-character specification ("\cM"). |
101 | |
102 | print DEV "atv1\012"; # wrong, for some devices |
103 | print DEV "atv1\015"; # right, for some devices |
104 | |
105 | Even though with normal text files, a "\n" will do the trick, there is |
106 | still no unified scheme for terminating a line that is portable |
107 | between Unix, DOS/Win, and Macintosh, except to terminate I<ALL> line |
108 | ends with "\015\012", and strip what you don't need from the output. |
109 | This applies especially to socket I/O and autoflushing, discussed |
110 | next. |
111 | |
112 | =item flushing output |
113 | |
114 | If you expect characters to get to your device when you print() them, |
115 | you'll want to autoflush that filehandle, as in the older |
116 | |
117 | use FileHandle; |
118 | DEV->autoflush(1); |
119 | |
120 | and the newer |
121 | |
122 | use IO::Handle; |
123 | DEV->autoflush(1); |
124 | |
125 | You can use select() and the C<$|> variable to control autoflushing |
126 | (see L<perlvar/$|> and L<perlfunc/select>): |
127 | |
128 | $oldh = select(DEV); |
129 | $| = 1; |
130 | select($oldh); |
131 | |
132 | You'll also see code that does this without a temporary variable, as in |
133 | |
134 | select((select(DEV), $| = 1)[0]); |
135 | |
136 | As mentioned in the previous item, this still doesn't work when using |
137 | socket I/O between Unix and Macintosh. You'll need to hardcode your |
138 | line terminators, in that case. |
139 | |
140 | =item non-blocking input |
141 | |
142 | If you are doing a blocking read() or sysread(), you'll have to |
143 | arrange for an alarm handler to provide a timeout (see |
144 | L<perlfunc/alarm>). If you have a non-blocking open, you'll likely |
145 | have a non-blocking read, which means you may have to use a 4-arg |
146 | select() to determine whether I/O is ready on that device (see |
147 | L<perlfunc/"select">. |
148 | |
149 | =back |
150 | |
151 | =head2 How do I decode encrypted password files? |
152 | |
153 | You spend lots and lots of money on dedicated hardware, but this is |
154 | bound to get you talked about. |
155 | |
156 | Seriously, you can't if they are Unix password files - the Unix |
157 | password system employs one-way encryption. Programs like Crack can |
158 | forcibly (and intelligently) try to guess passwords, but don't (can't) |
159 | guarantee quick success. |
160 | |
161 | If you're worried about users selecting bad passwords, you should |
162 | proactively check when they try to change their password (by modifying |
163 | passwd(1), for example). |
164 | |
165 | =head2 How do I start a process in the background? |
166 | |
167 | You could use |
168 | |
169 | system("cmd &") |
170 | |
171 | or you could use fork as documented in L<perlfunc/"fork">, with |
172 | further examples in L<perlipc>. Some things to be aware of, if you're |
173 | on a Unix-like system: |
174 | |
175 | =over 4 |
176 | |
177 | =item STDIN, STDOUT and STDERR are shared |
178 | |
179 | Both the main process and the backgrounded one (the "child" process) |
180 | share the same STDIN, STDOUT and STDERR filehandles. If both try to |
181 | access them at once, strange things can happen. You may want to close |
182 | or reopen these for the child. You can get around this with |
183 | C<open>ing a pipe (see L<perlfunc/"open">) but on some systems this |
184 | means that the child process cannot outlive the parent. |
185 | |
186 | =item Signals |
187 | |
188 | You'll have to catch the SIGCHLD signal, and possibly SIGPIPE too. |
189 | SIGCHLD is sent when the backgrounded process finishes. SIGPIPE is |
190 | sent when you write to a filehandle whose child process has closed (an |
191 | untrapped SIGPIPE can cause your program to silently die). This is |
192 | not an issue with C<system("cmd&")>. |
193 | |
194 | =item Zombies |
195 | |
196 | You have to be prepared to "reap" the child process when it finishes |
197 | |
198 | $SIG{CHLD} = sub { wait }; |
199 | |
200 | See L<perlipc/"Signals"> for other examples of code to do this. |
201 | Zombies are not an issue with C<system("prog &")>. |
202 | |
203 | =back |
204 | |
205 | =head2 How do I trap control characters/signals? |
206 | |
207 | You don't actually "trap" a control character. Instead, that |
208 | character generates a signal, which you then trap. Signals are |
209 | documented in L<perlipc/"Signals"> and chapter 6 of the Camel. |
210 | |
211 | Be warned that very few C libraries are re-entrant. Therefore, if you |
212 | attempt to print() in a handler that got invoked during another stdio |
213 | operation your internal structures will likely be in an |
214 | inconsistent state, and your program will dump core. You can |
215 | sometimes avoid this by using syswrite() instead of print(). |
216 | |
217 | Unless you're exceedingly careful, the only safe things to do inside a |
218 | signal handler are: set a variable and exit. And in the first case, |
219 | you should only set a variable in such a way that malloc() is not |
220 | called (eg, by setting a variable that already has a value). |
221 | |
222 | For example: |
223 | |
224 | $Interrupted = 0; # to ensure it has a value |
225 | $SIG{INT} = sub { |
226 | $Interrupted++; |
227 | syswrite(STDERR, "ouch\n", 5); |
228 | } |
229 | |
230 | However, because syscalls restart by default, you'll find that if |
231 | you're in a "slow" call, such as E<lt>FHE<gt>, read(), connect(), or |
232 | wait(), that the only way to terminate them is by "longjumping" out; |
233 | that is, by raising an exception. See the time-out handler for a |
234 | blocking flock() in L<perlipc/"Signals"> or chapter 6 of the Camel. |
235 | |
236 | =head2 How do I modify the shadow password file on a Unix system? |
237 | |
238 | If perl was installed correctly, the getpw*() functions described in |
239 | L<perlfunc> provide (read-only) access to the shadow password file. |
240 | To change the file, make a new shadow password file (the format varies |
241 | from system to system - see L<passwd(5)> for specifics) and use |
242 | pwd_mkdb(8) to install it (see L<pwd_mkdb(5)> for more details). |
243 | |
244 | =head2 How do I set the time and date? |
245 | |
246 | Assuming you're running under sufficient permissions, you should be |
247 | able to set the system-wide date and time by running the date(1) |
248 | program. (There is no way to set the time and date on a per-process |
249 | basis.) This mechanism will work for Unix, MS-DOS, Windows, and NT; |
250 | the VMS equivalent is C<set time>. |
251 | |
252 | However, if all you want to do is change your timezone, you can |
253 | probably get away with setting an environment variable: |
254 | |
255 | $ENV{TZ} = "MST7MDT"; # unixish |
256 | $ENV{'SYS$TIMEZONE_DIFFERENTIAL'}="-5" # vms |
257 | system "trn comp.lang.perl"; |
258 | |
259 | =head2 How can I sleep() or alarm() for under a second? |
260 | |
261 | If you want finer granularity than the 1 second that the sleep() |
262 | function provides, the easiest way is to use the select() function as |
263 | documented in L<perlfunc/"select">. If your system has itimers and |
264 | syscall() support, you can check out the old example in |
265 | http://www.perl.com/CPAN/doc/misc/ancient/tutorial/eg/itimers.pl . |
266 | |
267 | =head2 How can I measure time under a second? |
268 | |
269 | In general, you may not be able to. The Time::HiRes module (available |
270 | from CPAN) provides this functionality for some systems. |
271 | |
272 | In general, you may not be able to. But if you system supports both the |
273 | syscall() function in Perl as well as a system call like gettimeofday(2), |
274 | then you may be able to do something like this: |
275 | |
276 | require 'sys/syscall.ph'; |
277 | |
278 | $TIMEVAL_T = "LL"; |
279 | |
280 | $done = $start = pack($TIMEVAL_T, ()); |
281 | |
282 | syscall( &SYS_gettimeofday, $start, 0)) != -1 |
283 | or die "gettimeofday: $!"; |
284 | |
285 | ########################## |
286 | # DO YOUR OPERATION HERE # |
287 | ########################## |
288 | |
289 | syscall( &SYS_gettimeofday, $done, 0) != -1 |
290 | or die "gettimeofday: $!"; |
291 | |
292 | @start = unpack($TIMEVAL_T, $start); |
293 | @done = unpack($TIMEVAL_T, $done); |
294 | |
295 | # fix microseconds |
296 | for ($done[1], $start[1]) { $_ /= 1_000_000 } |
297 | |
298 | $delta_time = sprintf "%.4f", ($done[0] + $done[1] ) |
299 | - |
300 | ($start[0] + $start[1] ); |
301 | |
302 | =head2 How can I do an atexit() or setjmp()/longjmp()? (Exception handling) |
303 | |
304 | Release 5 of Perl added the END block, which can be used to simulate |
305 | atexit(). Each package's END block is called when the program or |
306 | thread ends (see L<perlmod> manpage for more details). It isn't |
307 | called when untrapped signals kill the program, though, so if you use |
308 | END blocks you should also use |
309 | |
310 | use sigtrap qw(die normal-signals); |
311 | |
312 | Perl's exception-handling mechanism is its eval() operator. You can |
313 | use eval() as setjmp and die() as longjmp. For details of this, see |
314 | the section on signals, especially the time-out handler for a blocking |
315 | flock() in L<perlipc/"Signals"> and chapter 6 of the Camel. |
316 | |
317 | If exception handling is all you're interested in, try the |
318 | exceptions.pl library (part of the standard perl distribution). |
319 | |
320 | If you want the atexit() syntax (and an rmexit() as well), try the |
321 | AtExit module available from CPAN. |
322 | |
323 | =head2 Why doesn't my sockets program work under System V (Solaris)? What does the error message "Protocol not supported" mean? |
324 | |
325 | Some Sys-V based systems, notably Solaris 2.X, redefined some of the |
326 | standard socket constants. Since these were constant across all |
327 | architectures, they were often hardwired into perl code. The proper |
328 | way to deal with this is to "use Socket" to get the correct values. |
329 | |
330 | Note that even though SunOS and Solaris are binary compatible, these |
331 | values are different. Go figure. |
332 | |
333 | =head2 How can I call my system's unique C functions from Perl? |
334 | |
335 | In most cases, you write an external module to do it - see the answer |
336 | to "Where can I learn about linking C with Perl? [h2xs, xsubpp]". |
337 | However, if the function is a system call, and your system supports |
338 | syscall(), you can use the syscall function (documented in |
339 | L<perlfunc>). |
340 | |
341 | Remember to check the modules that came with your distribution, and |
342 | CPAN as well - someone may already have written a module to do it. |
343 | |
344 | =head2 Where do I get the include files to do ioctl() or syscall()? |
345 | |
346 | Historically, these would be generated by the h2ph tool, part of the |
347 | standard perl distribution. This program converts cpp(1) directives |
348 | in C header files to files containing subroutine definitions, like |
349 | &SYS_getitimer, which you can use as arguments to your functions. |
350 | It doesn't work perfectly, but it usually gets most of the job done. |
351 | Simple files like F<errno.h>, F<syscall.h>, and F<socket.h> were fine, |
352 | but the hard ones like F<ioctl.h> nearly always need to hand-edited. |
353 | Here's how to install the *.ph files: |
354 | |
355 | 1. become super-user |
356 | 2. cd /usr/include |
357 | 3. h2ph *.h */*.h |
358 | |
359 | If your system supports dynamic loading, for reasons of portability and |
360 | sanity you probably ought to use h2xs (also part of the standard perl |
361 | distribution). This tool converts C header files to Perl extensions. |
362 | See L<perlxstut> for how to get started with h2xs. |
363 | |
364 | If your system doesn't support dynamic loading, you still probably |
365 | ought to use h2xs. See L<perlxstut> and L<ExtUtils::MakeMaker> for |
366 | more information (in brief, just use B<make perl> instead of a plain |
367 | B<make> to rebuild perl with a new static extension). |
368 | |
369 | =head2 Why do setuid perl scripts complain about kernel problems? |
370 | |
371 | Some operating systems have bugs in the kernel that make setuid |
372 | scripts inherently insecure. Perl gives you a number of options |
373 | (described in L<perlsec>) to work around such systems. |
374 | |
375 | =head2 How can I open a pipe both to and from a command? |
376 | |
377 | The IPC::Open2 module (part of the standard perl distribution) is an |
378 | easy-to-use approach that internally uses pipe(), fork(), and exec() |
379 | to do the job. Make sure you read the deadlock warnings in its |
380 | documentation, though (see L<IPC::Open2>). |
381 | |
382 | =head2 How can I capture STDERR from an external command? |
383 | |
384 | There are three basic ways of running external commands: |
385 | |
386 | system $cmd; # using system() |
387 | $output = `$cmd`; # using backticks (``) |
388 | open (PIPE, "cmd |"); # using open() |
389 | |
390 | With system(), both STDOUT and STDERR will go the same place as the |
391 | script's versions of these, unless the command redirects them. |
392 | Backticks and open() read B<only> the STDOUT of your command. |
393 | |
394 | With any of these, you can change file descriptors before the call: |
395 | |
396 | open(STDOUT, ">logfile"); |
397 | system("ls"); |
398 | |
399 | or you can use Bourne shell file-descriptor redirection: |
400 | |
401 | $output = `$cmd 2>some_file`; |
402 | open (PIPE, "cmd 2>some_file |"); |
403 | |
404 | You can also use file-descriptor redirection to make STDERR a |
405 | duplicate of STDOUT: |
406 | |
407 | $output = `$cmd 2>&1`; |
408 | open (PIPE, "cmd 2>&1 |"); |
409 | |
410 | Note that you I<cannot> simply open STDERR to be a dup of STDOUT |
411 | in your Perl program and avoid calling the shell to do the redirection. |
412 | This doesn't work: |
413 | |
414 | open(STDERR, ">&STDOUT"); |
415 | $alloutput = `cmd args`; # stderr still escapes |
416 | |
417 | This fails because the open() makes STDERR go to where STDOUT was |
418 | going at the time of the open(). The backticks then make STDOUT go to |
419 | a string, but don't change STDERR (which still goes to the old |
420 | STDOUT). |
421 | |
422 | Note that you I<must> use Bourne shell (sh(1)) redirection syntax in |
423 | backticks, not csh(1)! Details on why Perl's system() and backtick |
424 | and pipe opens all use the Bourne shell are in |
425 | http://www.perl.com/CPAN/doc/FMTEYEWTK/versus/csh.whynot . |
426 | |
427 | You may also use the IPC::Open3 module (part of the standard perl |
428 | distribution), but be warned that it has a different order of |
429 | arguments from IPC::Open2 (see L<IPC::Open3>). |
430 | |
431 | =head2 Why doesn't open() return an error when a pipe open fails? |
432 | |
433 | It does, but probably not how you expect it to. On systems that |
434 | follow the standard fork()/exec() paradigm (eg, Unix), it works like |
435 | this: open() causes a fork(). In the parent, open() returns with the |
436 | process ID of the child. The child exec()s the command to be piped |
437 | to/from. The parent can't know whether the exec() was successful or |
438 | not - all it can return is whether the fork() succeeded or not. To |
439 | find out if the command succeeded, you have to catch SIGCHLD and |
440 | wait() to get the exit status. |
441 | |
442 | On systems that follow the spawn() paradigm, open() I<might> do what |
443 | you expect - unless perl uses a shell to start your command. In this |
444 | case the fork()/exec() description still applies. |
445 | |
446 | =head2 What's wrong with using backticks in a void context? |
447 | |
448 | Strictly speaking, nothing. Stylistically speaking, it's not a good |
449 | way to write maintainable code because backticks have a (potentially |
450 | humungous) return value, and you're ignoring it. It's may also not be very |
451 | efficient, because you have to read in all the lines of output, allocate |
452 | memory for them, and then throw it away. Too often people are lulled |
453 | to writing: |
454 | |
455 | `cp file file.bak`; |
456 | |
457 | And now they think "Hey, I'll just always use backticks to run programs." |
458 | Bad idea: backticks are for capturing a program's output; the system() |
459 | function is for running programs. |
460 | |
461 | Consider this line: |
462 | |
463 | `cat /etc/termcap`; |
464 | |
465 | You haven't assigned the output anywhere, so it just wastes memory |
466 | (for a little while). Plus you forgot to check C<$?> to see whether |
467 | the program even ran correctly. Even if you wrote |
468 | |
469 | print `cat /etc/termcap`; |
470 | |
471 | In most cases, this could and probably should be written as |
472 | |
473 | system("cat /etc/termcap") == 0 |
474 | or die "cat program failed!"; |
475 | |
476 | Which will get the output quickly (as its generated, instead of only |
477 | at the end ) and also check the return value. |
478 | |
479 | system() also provides direct control over whether shell wildcard |
480 | processing may take place, whereas backticks do not. |
481 | |
482 | =head2 How can I call backticks without shell processing? |
483 | |
484 | This is a bit tricky. Instead of writing |
485 | |
486 | @ok = `grep @opts '$search_string' @filenames`; |
487 | |
488 | You have to do this: |
489 | |
490 | my @ok = (); |
491 | if (open(GREP, "-|")) { |
492 | while (<GREP>) { |
493 | chomp; |
494 | push(@ok, $_); |
495 | } |
496 | close GREP; |
497 | } else { |
498 | exec 'grep', @opts, $search_string, @filenames; |
499 | } |
500 | |
501 | Just as with system(), no shell escapes happen when you exec() a list. |
502 | |
503 | =head2 Why can't my script read from STDIN after I gave it EOF (^D on Unix, ^Z on MSDOS)? |
504 | |
505 | Because some stdio's set error and eof flags that need clearing. The |
506 | POSIX module defines clearerr() that you can use. That is the |
507 | technically correct way to do it. Here are some less reliable |
508 | workarounds: |
509 | |
510 | =over 4 |
511 | |
512 | =item 1 |
513 | |
514 | Try keeping around the seekpointer and go there, like this: |
515 | |
516 | $where = tell(LOG); |
517 | seek(LOG, $where, 0); |
518 | |
519 | =item 2 |
520 | |
521 | If that doesn't work, try seeking to a different part of the file and |
522 | then back. |
523 | |
524 | =item 3 |
525 | |
526 | If that doesn't work, try seeking to a different part of |
527 | the file, reading something, and then seeking back. |
528 | |
529 | =item 4 |
530 | |
531 | If that doesn't work, give up on your stdio package and use sysread. |
532 | |
533 | =back |
534 | |
535 | =head2 How can I convert my shell script to perl? |
536 | |
537 | Learn Perl and rewrite it. Seriously, there's no simple converter. |
538 | Things that are awkward to do in the shell are easy to do in Perl, and |
539 | this very awkwardness is what would make a shell->perl converter |
540 | nigh-on impossible to write. By rewriting it, you'll think about what |
541 | you're really trying to do, and hopefully will escape the shell's |
542 | pipeline datastream paradigm, which while convenient for some matters, |
543 | causes many inefficiencies. |
544 | |
545 | =head2 Can I use perl to run a telnet or ftp session? |
546 | |
547 | Try the Net::FTP and TCP::Client modules (available from CPAN). |
548 | http://www.perl.com/CPAN/scripts/netstuff/telnet.emul.shar will also |
549 | help for emulating the telnet protocol. |
550 | |
551 | =head2 How can I write expect in Perl? |
552 | |
553 | Once upon a time, there was a library called chat2.pl (part of the |
554 | standard perl distribution), which never really got finished. These |
555 | days, your best bet is to look at the Comm.pl library available from |
556 | CPAN. |
557 | |
558 | =head2 Is there a way to hide perl's command line from programs such as "ps"? |
559 | |
560 | First of all note that if you're doing this for security reasons (to |
561 | avoid people seeing passwords, for example) then you should rewrite |
562 | your program so that critical information is never given as an |
563 | argument. Hiding the arguments won't make your program completely |
564 | secure. |
565 | |
566 | To actually alter the visible command line, you can assign to the |
567 | variable $0 as documented in L<perlvar>. This won't work on all |
568 | operating systems, though. Daemon programs like sendmail place their |
569 | state there, as in: |
570 | |
571 | $0 = "orcus [accepting connections]"; |
572 | |
573 | =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? |
574 | |
575 | =over 4 |
576 | |
577 | =item Unix |
578 | |
579 | In the strictest sense, it can't be done -- the script executes as a |
580 | different process from the shell it was started from. Changes to a |
581 | process are not reflected in its parent, only in its own children |
582 | created after the change. There is shell magic that may allow you to |
583 | fake it by eval()ing the script's output in your shell; check out the |
584 | comp.unix.questions FAQ for details. |
585 | |
586 | =item VMS |
587 | |
588 | Change to %ENV persist after Perl exits, but directory changes do not. |
589 | |
590 | =back |
591 | |
592 | =head2 How do I close a process's filehandle without waiting for it to complete? |
593 | |
594 | Assuming your system supports such things, just send an appropriate signal |
595 | to the process (see L<perlfunc/"kill">. It's common to first send a TERM |
596 | signal, wait a little bit, and then send a KILL signal to finish it off. |
597 | |
598 | =head2 How do I fork a daemon process? |
599 | |
600 | If by daemon process you mean one that's detached (disassociated from |
601 | its tty), then the following process is reported to work on most |
602 | Unixish systems. Non-Unix users should check their Your_OS::Process |
603 | module for other solutions. |
604 | |
605 | =over 4 |
606 | |
607 | =item * |
608 | |
609 | Open /dev/tty and use the the TIOCNOTTY ioctl on it. See L<tty(4)> |
610 | for details. |
611 | |
612 | =item * |
613 | |
614 | Change directory to / |
615 | |
616 | =item * |
617 | |
618 | Reopen STDIN, STDOUT, and STDERR so they're not connected to the old |
619 | tty. |
620 | |
621 | =item * |
622 | |
623 | Background yourself like this: |
624 | |
625 | fork && exit; |
626 | |
627 | =back |
628 | |
629 | =head2 How do I make my program run with sh and csh? |
630 | |
631 | See the F<eg/nih> script (part of the perl source distribution). |
632 | |
633 | =head2 How do I keep my own module/library directory? |
634 | |
635 | When you build modules, use the PREFIX option when generating |
636 | Makefiles: |
637 | |
638 | perl Makefile.PL PREFIX=/u/mydir/perl |
639 | |
640 | then either set the PERL5LIB environment variable before you run |
641 | scripts that use the modules/libraries (see L<perlrun>) or say |
642 | |
643 | use lib '/u/mydir/perl'; |
644 | |
645 | See Perl's L<lib> for more information. |
646 | |
647 | =head2 How do I find out if I'm running interactively or not? |
648 | |
649 | Good question. Sometimes C<-t STDIN> and C<-t STDOUT> can give clues, |
650 | sometimes not. |
651 | |
652 | if (-t STDIN && -t STDOUT) { |
653 | print "Now what? "; |
654 | } |
655 | |
656 | On POSIX systems, you can test whether your own process group matches |
657 | the current process group of your controlling terminal as follows: |
658 | |
659 | use POSIX qw/getpgrp tcgetpgrp/; |
660 | open(TTY, "/dev/tty") or die $!; |
661 | $tpgrp = tcgetpgrp(TTY); |
662 | $pgrp = getpgrp(); |
663 | if ($tpgrp == $pgrp) { |
664 | print "foreground\n"; |
665 | } else { |
666 | print "background\n"; |
667 | } |
668 | |
669 | =head2 How do I timeout a slow event? |
670 | |
671 | Use the alarm() function, probably in conjunction with a signal |
672 | handler, as documented L<perlipc/"Signals"> and chapter 6 of the |
673 | Camel. You may instead use the more flexible Sys::AlarmCall module |
674 | available from CPAN. |
675 | |
676 | =head2 How do I set CPU limits? |
677 | |
678 | Use the BSD::Resource module from CPAN. |
679 | |
680 | =head2 How do I avoid zombies on a Unix system? |
681 | |
682 | Use the reaper code from L<perlipc/"Signals"> to call wait() when a |
683 | SIGCHLD is received, or else use the double-fork technique described |
684 | in L<perlfunc/fork>. |
685 | |
686 | =head2 How do I use an SQL database? |
687 | |
688 | There are a number of excellent interfaces to SQL databases. See the |
689 | DBD::* modules available from |
690 | http://www.perl.com/CPAN/modules/dbperl/DBD . |
691 | |
692 | =head2 How do I make a system() exit on control-C? |
693 | |
694 | You can't. You need to imitate the system() call (see L<perlipc> for |
695 | sample code) and then have a signal handler for the INT signal that |
696 | passes the signal on to the subprocess. |
697 | |
698 | =head2 How do I open a file without blocking? |
699 | |
700 | If you're lucky enough to be using a system that supports |
701 | non-blocking reads (most Unixish systems do), you need only to use the |
702 | O_NDELAY or O_NONBLOCK flag from the Fcntl module in conjunction with |
703 | sysopen(): |
704 | |
705 | use Fcntl; |
706 | sysopen(FH, "/tmp/somefile", O_WRONLY|O_NDELAY|O_CREAT, 0644) |
707 | or die "can't open /tmp/somefile: $!": |
708 | |
709 | =head2 How do I install a CPAN module? |
710 | |
711 | The easiest way is to have the CPAN module do it for you. This module |
712 | comes with perl version 5.004 and later. To manually install the CPAN |
713 | module, or any well-behaved CPAN module for that matter, follow these |
714 | steps: |
715 | |
716 | =over 4 |
717 | |
718 | =item 1 |
719 | |
720 | Unpack the source into a temporary area. |
721 | |
722 | =item 2 |
723 | |
724 | perl Makefile.PL |
725 | |
726 | =item 3 |
727 | |
728 | make |
729 | |
730 | =item 4 |
731 | |
732 | make test |
733 | |
734 | =item 5 |
735 | |
736 | make install |
737 | |
738 | =back |
739 | |
740 | If your version of perl is compiled without dynamic loading, then you |
741 | just need to replace step 3 (B<make>) with B<make perl> and you will |
742 | get a new F<perl> binary with your extension linked in. |
743 | |
744 | See L<ExtUtils::MakeMaker> for more details on building extensions. |
745 | |
746 | =head1 AUTHOR AND COPYRIGHT |
747 | |
748 | Copyright (c) 1997 Tom Christiansen and Nathan Torkington. |
749 | All rights reserved. See L<perlfaq> for distribution information. |