summaryrefslogtreecommitdiffstats
path: root/contrib/perl5/pod/perlfaq8.pod
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/perl5/pod/perlfaq8.pod')
-rw-r--r--contrib/perl5/pod/perlfaq8.pod1075
1 files changed, 1075 insertions, 0 deletions
diff --git a/contrib/perl5/pod/perlfaq8.pod b/contrib/perl5/pod/perlfaq8.pod
new file mode 100644
index 0000000..c4036ff
--- /dev/null
+++ b/contrib/perl5/pod/perlfaq8.pod
@@ -0,0 +1,1075 @@
+=head1 NAME
+
+perlfaq8 - System Interaction ($Revision: 1.26 $, $Date: 1998/08/05 12:20:28 $)
+
+=head1 DESCRIPTION
+
+This section of the Perl FAQ covers questions involving operating
+system interaction. This involves interprocess communication (IPC),
+control over the user-interface (keyboard, screen and pointing
+devices), and most anything else not related to data manipulation.
+
+Read the FAQs and documentation specific to the port of perl to your
+operating system (eg, L<perlvms>, L<perlplan9>, ...). These should
+contain more detailed information on the vagaries of your perl.
+
+=head2 How do I find out which operating system I'm running under?
+
+The $^O variable ($OSNAME if you use English) contains the operating
+system that your perl binary was built for.
+
+=head2 How come exec() doesn't return?
+
+Because that's what it does: it replaces your currently running
+program with a different one. If you want to keep going (as is
+probably the case if you're asking this question) use system()
+instead.
+
+=head2 How do I do fancy stuff with the keyboard/screen/mouse?
+
+How you access/control keyboards, screens, and pointing devices
+("mice") is system-dependent. Try the following modules:
+
+=over 4
+
+=item Keyboard
+
+ Term::Cap Standard perl distribution
+ Term::ReadKey CPAN
+ Term::ReadLine::Gnu CPAN
+ Term::ReadLine::Perl CPAN
+ Term::Screen CPAN
+
+=item Screen
+
+ Term::Cap Standard perl distribution
+ Curses CPAN
+ Term::ANSIColor CPAN
+
+=item Mouse
+
+ Tk CPAN
+
+=back
+
+Some of these specific cases are shown below.
+
+=head2 How do I print something out in color?
+
+In general, you don't, because you don't know whether
+the recipient has a color-aware display device. If you
+know that they have an ANSI terminal that understands
+color, you can use the Term::ANSIColor module from CPAN:
+
+ use Term::ANSIColor;
+ print color("red"), "Stop!\n", color("reset");
+ print color("green"), "Go!\n", color("reset");
+
+Or like this:
+
+ use Term::ANSIColor qw(:constants);
+ print RED, "Stop!\n", RESET;
+ print GREEN, "Go!\n", RESET;
+
+=head2 How do I read just one key without waiting for a return key?
+
+Controlling input buffering is a remarkably system-dependent matter.
+If most systems, you can just use the B<stty> command as shown in
+L<perlfunc/getc>, but as you see, that's already getting you into
+portability snags.
+
+ open(TTY, "+</dev/tty") or die "no tty: $!";
+ system "stty cbreak </dev/tty >/dev/tty 2>&1";
+ $key = getc(TTY); # perhaps this works
+ # OR ELSE
+ sysread(TTY, $key, 1); # probably this does
+ system "stty -cbreak </dev/tty >/dev/tty 2>&1";
+
+The Term::ReadKey module from CPAN offers an easy-to-use interface that
+should be more efficient than shelling out to B<stty> for each key.
+It even includes limited support for Windows.
+
+ use Term::ReadKey;
+ ReadMode('cbreak');
+ $key = ReadKey(0);
+ ReadMode('normal');
+
+However, that requires that you have a working C compiler and can use it
+to build and install a CPAN module. Here's a solution using
+the standard POSIX module, which is already on your systems (assuming
+your system supports POSIX).
+
+ use HotKey;
+ $key = readkey();
+
+And here's the HotKey module, which hides the somewhat mystifying calls
+to manipulate the POSIX termios structures.
+
+ # HotKey.pm
+ package HotKey;
+
+ @ISA = qw(Exporter);
+ @EXPORT = qw(cbreak cooked readkey);
+
+ use strict;
+ use POSIX qw(:termios_h);
+ my ($term, $oterm, $echo, $noecho, $fd_stdin);
+
+ $fd_stdin = fileno(STDIN);
+ $term = POSIX::Termios->new();
+ $term->getattr($fd_stdin);
+ $oterm = $term->getlflag();
+
+ $echo = ECHO | ECHOK | ICANON;
+ $noecho = $oterm & ~$echo;
+
+ sub cbreak {
+ $term->setlflag($noecho); # ok, so i don't want echo either
+ $term->setcc(VTIME, 1);
+ $term->setattr($fd_stdin, TCSANOW);
+ }
+
+ sub cooked {
+ $term->setlflag($oterm);
+ $term->setcc(VTIME, 0);
+ $term->setattr($fd_stdin, TCSANOW);
+ }
+
+ sub readkey {
+ my $key = '';
+ cbreak();
+ sysread(STDIN, $key, 1);
+ cooked();
+ return $key;
+ }
+
+ END { cooked() }
+
+ 1;
+
+=head2 How do I check whether input is ready on the keyboard?
+
+The easiest way to do this is to read a key in nonblocking mode with the
+Term::ReadKey module from CPAN, passing it an argument of -1 to indicate
+not to block:
+
+ use Term::ReadKey;
+
+ ReadMode('cbreak');
+
+ if (defined ($char = ReadKey(-1)) ) {
+ # input was waiting and it was $char
+ } else {
+ # no input was waiting
+ }
+
+ ReadMode('normal'); # restore normal tty settings
+
+=head2 How do I clear the screen?
+
+If you only have to so infrequently, use C<system>:
+
+ system("clear");
+
+If you have to do this a lot, save the clear string
+so you can print it 100 times without calling a program
+100 times:
+
+ $clear_string = `clear`;
+ print $clear_string;
+
+If you're planning on doing other screen manipulations, like cursor
+positions, etc, you might wish to use Term::Cap module:
+
+ use Term::Cap;
+ $terminal = Term::Cap->Tgetent( {OSPEED => 9600} );
+ $clear_string = $terminal->Tputs('cl');
+
+=head2 How do I get the screen size?
+
+If you have Term::ReadKey module installed from CPAN,
+you can use it to fetch the width and height in characters
+and in pixels:
+
+ use Term::ReadKey;
+ ($wchar, $hchar, $wpixels, $hpixels) = GetTerminalSize();
+
+This is more portable than the raw C<ioctl>, but not as
+illustrative:
+
+ require 'sys/ioctl.ph';
+ die "no TIOCGWINSZ " unless defined &TIOCGWINSZ;
+ open(TTY, "+</dev/tty") or die "No tty: $!";
+ unless (ioctl(TTY, &TIOCGWINSZ, $winsize='')) {
+ die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ;
+ }
+ ($row, $col, $xpixel, $ypixel) = unpack('S4', $winsize);
+ print "(row,col) = ($row,$col)";
+ print " (xpixel,ypixel) = ($xpixel,$ypixel)" if $xpixel || $ypixel;
+ print "\n";
+
+=head2 How do I ask the user for a password?
+
+(This question has nothing to do with the web. See a different
+FAQ for that.)
+
+There's an example of this in L<perlfunc/crypt>). First, you put
+the terminal into "no echo" mode, then just read the password
+normally. You may do this with an old-style ioctl() function, POSIX
+terminal control (see L<POSIX>, and Chapter 7 of the Camel), or a call
+to the B<stty> program, with varying degrees of portability.
+
+You can also do this for most systems using the Term::ReadKey module
+from CPAN, which is easier to use and in theory more portable.
+
+ use Term::ReadKey;
+
+ ReadMode('noecho');
+ $password = ReadLine(0);
+
+=head2 How do I read and write the serial port?
+
+This depends on which operating system your program is running on. In
+the case of Unix, the serial ports will be accessible through files in
+/dev; on other systems, the devices names will doubtless differ.
+Several problem areas common to all device interaction are the
+following
+
+=over 4
+
+=item lockfiles
+
+Your system may use lockfiles to control multiple access. Make sure
+you follow the correct protocol. Unpredictable behaviour can result
+from multiple processes reading from one device.
+
+=item open mode
+
+If you expect to use both read and write operations on the device,
+you'll have to open it for update (see L<perlfunc/"open"> for
+details). You may wish to open it without running the risk of
+blocking by using sysopen() and C<O_RDWR|O_NDELAY|O_NOCTTY> from the
+Fcntl module (part of the standard perl distribution). See
+L<perlfunc/"sysopen"> for more on this approach.
+
+=item end of line
+
+Some devices will be expecting a "\r" at the end of each line rather
+than a "\n". In some ports of perl, "\r" and "\n" are different from
+their usual (Unix) ASCII values of "\012" and "\015". You may have to
+give the numeric values you want directly, using octal ("\015"), hex
+("0x0D"), or as a control-character specification ("\cM").
+
+ print DEV "atv1\012"; # wrong, for some devices
+ print DEV "atv1\015"; # right, for some devices
+
+Even though with normal text files, a "\n" will do the trick, there is
+still no unified scheme for terminating a line that is portable
+between Unix, DOS/Win, and Macintosh, except to terminate I<ALL> line
+ends with "\015\012", and strip what you don't need from the output.
+This applies especially to socket I/O and autoflushing, discussed
+next.
+
+=item flushing output
+
+If you expect characters to get to your device when you print() them,
+you'll want to autoflush that filehandle. You can use select()
+and the C<$|> variable to control autoflushing (see L<perlvar/$|>
+and L<perlfunc/select>):
+
+ $oldh = select(DEV);
+ $| = 1;
+ select($oldh);
+
+You'll also see code that does this without a temporary variable, as in
+
+ select((select(DEV), $| = 1)[0]);
+
+Or if you don't mind pulling in a few thousand lines
+of code just because you're afraid of a little $| variable:
+
+ use IO::Handle;
+ DEV->autoflush(1);
+
+As mentioned in the previous item, this still doesn't work when using
+socket I/O between Unix and Macintosh. You'll need to hardcode your
+line terminators, in that case.
+
+=item non-blocking input
+
+If you are doing a blocking read() or sysread(), you'll have to
+arrange for an alarm handler to provide a timeout (see
+L<perlfunc/alarm>). If you have a non-blocking open, you'll likely
+have a non-blocking read, which means you may have to use a 4-arg
+select() to determine whether I/O is ready on that device (see
+L<perlfunc/"select">.
+
+=back
+
+While trying to read from his caller-id box, the notorious Jamie Zawinski
+<jwz@netscape.com>, after much gnashing of teeth and fighting with sysread,
+sysopen, POSIX's tcgetattr business, and various other functions that
+go bump in the night, finally came up with this:
+
+ sub open_modem {
+ use IPC::Open2;
+ my $stty = `/bin/stty -g`;
+ open2( \*MODEM_IN, \*MODEM_OUT, "cu -l$modem_device -s2400 2>&1");
+ # starting cu hoses /dev/tty's stty settings, even when it has
+ # been opened on a pipe...
+ system("/bin/stty $stty");
+ $_ = <MODEM_IN>;
+ chop;
+ if ( !m/^Connected/ ) {
+ print STDERR "$0: cu printed `$_' instead of `Connected'\n";
+ }
+ }
+
+
+=head2 How do I decode encrypted password files?
+
+You spend lots and lots of money on dedicated hardware, but this is
+bound to get you talked about.
+
+Seriously, you can't if they are Unix password files - the Unix
+password system employs one-way encryption. It's more like hashing than
+encryption. The best you can check is whether something else hashes to
+the same string. You can't turn a hash back into the original string.
+Programs like Crack
+can forcibly (and intelligently) try to guess passwords, but don't
+(can't) guarantee quick success.
+
+If you're worried about users selecting bad passwords, you should
+proactively check when they try to change their password (by modifying
+passwd(1), for example).
+
+=head2 How do I start a process in the background?
+
+You could use
+
+ system("cmd &")
+
+or you could use fork as documented in L<perlfunc/"fork">, with
+further examples in L<perlipc>. Some things to be aware of, if you're
+on a Unix-like system:
+
+=over 4
+
+=item STDIN, STDOUT, and STDERR are shared
+
+Both the main process and the backgrounded one (the "child" process)
+share the same STDIN, STDOUT and STDERR filehandles. If both try to
+access them at once, strange things can happen. You may want to close
+or reopen these for the child. You can get around this with
+C<open>ing a pipe (see L<perlfunc/"open">) but on some systems this
+means that the child process cannot outlive the parent.
+
+=item Signals
+
+You'll have to catch the SIGCHLD signal, and possibly SIGPIPE too.
+SIGCHLD is sent when the backgrounded process finishes. SIGPIPE is
+sent when you write to a filehandle whose child process has closed (an
+untrapped SIGPIPE can cause your program to silently die). This is
+not an issue with C<system("cmd&")>.
+
+=item Zombies
+
+You have to be prepared to "reap" the child process when it finishes
+
+ $SIG{CHLD} = sub { wait };
+
+See L<perlipc/"Signals"> for other examples of code to do this.
+Zombies are not an issue with C<system("prog &")>.
+
+=back
+
+=head2 How do I trap control characters/signals?
+
+You don't actually "trap" a control character. Instead, that character
+generates a signal which is sent to your terminal's currently
+foregrounded process group, which you then trap in your process.
+Signals are documented in L<perlipc/"Signals"> and chapter 6 of the Camel.
+
+Be warned that very few C libraries are re-entrant. Therefore, if you
+attempt to print() in a handler that got invoked during another stdio
+operation your internal structures will likely be in an
+inconsistent state, and your program will dump core. You can
+sometimes avoid this by using syswrite() instead of print().
+
+Unless you're exceedingly careful, the only safe things to do inside a
+signal handler are: set a variable and exit. And in the first case,
+you should only set a variable in such a way that malloc() is not
+called (eg, by setting a variable that already has a value).
+
+For example:
+
+ $Interrupted = 0; # to ensure it has a value
+ $SIG{INT} = sub {
+ $Interrupted++;
+ syswrite(STDERR, "ouch\n", 5);
+ }
+
+However, because syscalls restart by default, you'll find that if
+you're in a "slow" call, such as E<lt>FHE<gt>, read(), connect(), or
+wait(), that the only way to terminate them is by "longjumping" out;
+that is, by raising an exception. See the time-out handler for a
+blocking flock() in L<perlipc/"Signals"> or chapter 6 of the Camel.
+
+=head2 How do I modify the shadow password file on a Unix system?
+
+If perl was installed correctly, and your shadow library was written
+properly, the getpw*() functions described in L<perlfunc> should in
+theory provide (read-only) access to entries in the shadow password
+file. To change the file, make a new shadow password file (the format
+varies from system to system - see L<passwd(5)> for specifics) and use
+pwd_mkdb(8) to install it (see L<pwd_mkdb(5)> for more details).
+
+=head2 How do I set the time and date?
+
+Assuming you're running under sufficient permissions, you should be
+able to set the system-wide date and time by running the date(1)
+program. (There is no way to set the time and date on a per-process
+basis.) This mechanism will work for Unix, MS-DOS, Windows, and NT;
+the VMS equivalent is C<set time>.
+
+However, if all you want to do is change your timezone, you can
+probably get away with setting an environment variable:
+
+ $ENV{TZ} = "MST7MDT"; # unixish
+ $ENV{'SYS$TIMEZONE_DIFFERENTIAL'}="-5" # vms
+ system "trn comp.lang.perl.misc";
+
+=head2 How can I sleep() or alarm() for under a second?
+
+If you want finer granularity than the 1 second that the sleep()
+function provides, the easiest way is to use the select() function as
+documented in L<perlfunc/"select">. If your system has itimers and
+syscall() support, you can check out the old example in
+http://www.perl.com/CPAN/doc/misc/ancient/tutorial/eg/itimers.pl .
+
+=head2 How can I measure time under a second?
+
+In general, you may not be able to. The Time::HiRes module (available
+from CPAN) provides this functionality for some systems.
+
+In general, you may not be able to. But if your system supports both the
+syscall() function in Perl as well as a system call like gettimeofday(2),
+then you may be able to do something like this:
+
+ require 'sys/syscall.ph';
+
+ $TIMEVAL_T = "LL";
+
+ $done = $start = pack($TIMEVAL_T, ());
+
+ syscall( &SYS_gettimeofday, $start, 0)) != -1
+ or die "gettimeofday: $!";
+
+ ##########################
+ # DO YOUR OPERATION HERE #
+ ##########################
+
+ syscall( &SYS_gettimeofday, $done, 0) != -1
+ or die "gettimeofday: $!";
+
+ @start = unpack($TIMEVAL_T, $start);
+ @done = unpack($TIMEVAL_T, $done);
+
+ # fix microseconds
+ for ($done[1], $start[1]) { $_ /= 1_000_000 }
+
+ $delta_time = sprintf "%.4f", ($done[0] + $done[1] )
+ -
+ ($start[0] + $start[1] );
+
+=head2 How can I do an atexit() or setjmp()/longjmp()? (Exception handling)
+
+Release 5 of Perl added the END block, which can be used to simulate
+atexit(). Each package's END block is called when the program or
+thread ends (see L<perlmod> manpage for more details).
+
+For example, you can use this to make sure your filter program
+managed to finish its output without filling up the disk:
+
+ END {
+ close(STDOUT) || die "stdout close failed: $!";
+ }
+
+The END block isn't called when untrapped signals kill the program, though, so if
+you use END blocks you should also use
+
+ use sigtrap qw(die normal-signals);
+
+Perl's exception-handling mechanism is its eval() operator. You can
+use eval() as setjmp and die() as longjmp. For details of this, see
+the section on signals, especially the time-out handler for a blocking
+flock() in L<perlipc/"Signals"> and chapter 6 of the Camel.
+
+If exception handling is all you're interested in, try the
+exceptions.pl library (part of the standard perl distribution).
+
+If you want the atexit() syntax (and an rmexit() as well), try the
+AtExit module available from CPAN.
+
+=head2 Why doesn't my sockets program work under System V (Solaris)? What does the error message "Protocol not supported" mean?
+
+Some Sys-V based systems, notably Solaris 2.X, redefined some of the
+standard socket constants. Since these were constant across all
+architectures, they were often hardwired into perl code. The proper
+way to deal with this is to "use Socket" to get the correct values.
+
+Note that even though SunOS and Solaris are binary compatible, these
+values are different. Go figure.
+
+=head2 How can I call my system's unique C functions from Perl?
+
+In most cases, you write an external module to do it - see the answer
+to "Where can I learn about linking C with Perl? [h2xs, xsubpp]".
+However, if the function is a system call, and your system supports
+syscall(), you can use the syscall function (documented in
+L<perlfunc>).
+
+Remember to check the modules that came with your distribution, and
+CPAN as well - someone may already have written a module to do it.
+
+=head2 Where do I get the include files to do ioctl() or syscall()?
+
+Historically, these would be generated by the h2ph tool, part of the
+standard perl distribution. This program converts cpp(1) directives
+in C header files to files containing subroutine definitions, like
+&SYS_getitimer, which you can use as arguments to your functions.
+It doesn't work perfectly, but it usually gets most of the job done.
+Simple files like F<errno.h>, F<syscall.h>, and F<socket.h> were fine,
+but the hard ones like F<ioctl.h> nearly always need to hand-edited.
+Here's how to install the *.ph files:
+
+ 1. become super-user
+ 2. cd /usr/include
+ 3. h2ph *.h */*.h
+
+If your system supports dynamic loading, for reasons of portability and
+sanity you probably ought to use h2xs (also part of the standard perl
+distribution). This tool converts C header files to Perl extensions.
+See L<perlxstut> for how to get started with h2xs.
+
+If your system doesn't support dynamic loading, you still probably
+ought to use h2xs. See L<perlxstut> and L<ExtUtils::MakeMaker> for
+more information (in brief, just use B<make perl> instead of a plain
+B<make> to rebuild perl with a new static extension).
+
+=head2 Why do setuid perl scripts complain about kernel problems?
+
+Some operating systems have bugs in the kernel that make setuid
+scripts inherently insecure. Perl gives you a number of options
+(described in L<perlsec>) to work around such systems.
+
+=head2 How can I open a pipe both to and from a command?
+
+The IPC::Open2 module (part of the standard perl distribution) is an
+easy-to-use approach that internally uses pipe(), fork(), and exec() to do
+the job. Make sure you read the deadlock warnings in its documentation,
+though (see L<IPC::Open2>). See L<perlipc/"Bidirectional Communication
+with Another Process"> and L<perlipc/"Bidirectional Communication with
+Yourself">
+
+You may also use the IPC::Open3 module (part of the standard perl
+distribution), but be warned that it has a different order of
+arguments from IPC::Open2 (see L<IPC::Open3>).
+
+=head2 Why can't I get the output of a command with system()?
+
+You're confusing the purpose of system() and backticks (``). system()
+runs a command and returns exit status information (as a 16 bit value:
+the low 7 bits are the signal the process died from, if any, and
+the high 8 bits are the actual exit value). Backticks (``) run a
+command and return what it sent to STDOUT.
+
+ $exit_status = system("mail-users");
+ $output_string = `ls`;
+
+=head2 How can I capture STDERR from an external command?
+
+There are three basic ways of running external commands:
+
+ system $cmd; # using system()
+ $output = `$cmd`; # using backticks (``)
+ open (PIPE, "cmd |"); # using open()
+
+With system(), both STDOUT and STDERR will go the same place as the
+script's versions of these, unless the command redirects them.
+Backticks and open() read B<only> the STDOUT of your command.
+
+With any of these, you can change file descriptors before the call:
+
+ open(STDOUT, ">logfile");
+ system("ls");
+
+or you can use Bourne shell file-descriptor redirection:
+
+ $output = `$cmd 2>some_file`;
+ open (PIPE, "cmd 2>some_file |");
+
+You can also use file-descriptor redirection to make STDERR a
+duplicate of STDOUT:
+
+ $output = `$cmd 2>&1`;
+ open (PIPE, "cmd 2>&1 |");
+
+Note that you I<cannot> simply open STDERR to be a dup of STDOUT
+in your Perl program and avoid calling the shell to do the redirection.
+This doesn't work:
+
+ open(STDERR, ">&STDOUT");
+ $alloutput = `cmd args`; # stderr still escapes
+
+This fails because the open() makes STDERR go to where STDOUT was
+going at the time of the open(). The backticks then make STDOUT go to
+a string, but don't change STDERR (which still goes to the old
+STDOUT).
+
+Note that you I<must> use Bourne shell (sh(1)) redirection syntax in
+backticks, not csh(1)! Details on why Perl's system() and backtick
+and pipe opens all use the Bourne shell are in
+http://www.perl.com/CPAN/doc/FMTEYEWTK/versus/csh.whynot .
+To capture a command's STDERR and STDOUT together:
+
+ $output = `cmd 2>&1`; # either with backticks
+ $pid = open(PH, "cmd 2>&1 |"); # or with an open pipe
+ while (<PH>) { } # plus a read
+
+To capture a command's STDOUT but discard its STDERR:
+
+ $output = `cmd 2>/dev/null`; # either with backticks
+ $pid = open(PH, "cmd 2>/dev/null |"); # or with an open pipe
+ while (<PH>) { } # plus a read
+
+To capture a command's STDERR but discard its STDOUT:
+
+ $output = `cmd 2>&1 1>/dev/null`; # either with backticks
+ $pid = open(PH, "cmd 2>&1 1>/dev/null |"); # or with an open pipe
+ while (<PH>) { } # plus a read
+
+To exchange a command's STDOUT and STDERR in order to capture the STDERR
+but leave its STDOUT to come out our old STDERR:
+
+ $output = `cmd 3>&1 1>&2 2>&3 3>&-`; # either with backticks
+ $pid = open(PH, "cmd 3>&1 1>&2 2>&3 3>&-|");# or with an open pipe
+ while (<PH>) { } # plus a read
+
+To read both a command's STDOUT and its STDERR separately, it's easiest
+and safest to redirect them separately to files, and then read from those
+files when the program is done:
+
+ system("program args 1>/tmp/program.stdout 2>/tmp/program.stderr");
+
+Ordering is important in all these examples. That's because the shell
+processes file descriptor redirections in strictly left to right order.
+
+ system("prog args 1>tmpfile 2>&1");
+ system("prog args 2>&1 1>tmpfile");
+
+The first command sends both standard out and standard error to the
+temporary file. The second command sends only the old standard output
+there, and the old standard error shows up on the old standard out.
+
+=head2 Why doesn't open() return an error when a pipe open fails?
+
+It does, but probably not how you expect it to. On systems that
+follow the standard fork()/exec() paradigm (such as Unix), it works like
+this: open() causes a fork(). In the parent, open() returns with the
+process ID of the child. The child exec()s the command to be piped
+to/from. The parent can't know whether the exec() was successful or
+not - all it can return is whether the fork() succeeded or not. To
+find out if the command succeeded, you have to catch SIGCHLD and
+wait() to get the exit status. You should also catch SIGPIPE if
+you're writing to the child -- you may not have found out the exec()
+failed by the time you write. This is documented in L<perlipc>.
+
+On systems that follow the spawn() paradigm, open() I<might> do what
+you expect - unless perl uses a shell to start your command. In this
+case the fork()/exec() description still applies.
+
+=head2 What's wrong with using backticks in a void context?
+
+Strictly speaking, nothing. Stylistically speaking, it's not a good
+way to write maintainable code because backticks have a (potentially
+humungous) return value, and you're ignoring it. It's may also not be very
+efficient, because you have to read in all the lines of output, allocate
+memory for them, and then throw it away. Too often people are lulled
+to writing:
+
+ `cp file file.bak`;
+
+And now they think "Hey, I'll just always use backticks to run programs."
+Bad idea: backticks are for capturing a program's output; the system()
+function is for running programs.
+
+Consider this line:
+
+ `cat /etc/termcap`;
+
+You haven't assigned the output anywhere, so it just wastes memory
+(for a little while). Plus you forgot to check C<$?> to see whether
+the program even ran correctly. Even if you wrote
+
+ print `cat /etc/termcap`;
+
+In most cases, this could and probably should be written as
+
+ system("cat /etc/termcap") == 0
+ or die "cat program failed!";
+
+Which will get the output quickly (as its generated, instead of only
+at the end) and also check the return value.
+
+system() also provides direct control over whether shell wildcard
+processing may take place, whereas backticks do not.
+
+=head2 How can I call backticks without shell processing?
+
+This is a bit tricky. Instead of writing
+
+ @ok = `grep @opts '$search_string' @filenames`;
+
+You have to do this:
+
+ my @ok = ();
+ if (open(GREP, "-|")) {
+ while (<GREP>) {
+ chomp;
+ push(@ok, $_);
+ }
+ close GREP;
+ } else {
+ exec 'grep', @opts, $search_string, @filenames;
+ }
+
+Just as with system(), no shell escapes happen when you exec() a list.
+
+There are more examples of this L<perlipc/"Safe Pipe Opens">.
+
+=head2 Why can't my script read from STDIN after I gave it EOF (^D on Unix, ^Z on MS-DOS)?
+
+Because some stdio's set error and eof flags that need clearing. The
+POSIX module defines clearerr() that you can use. That is the
+technically correct way to do it. Here are some less reliable
+workarounds:
+
+=over 4
+
+=item 1
+
+Try keeping around the seekpointer and go there, like this:
+
+ $where = tell(LOG);
+ seek(LOG, $where, 0);
+
+=item 2
+
+If that doesn't work, try seeking to a different part of the file and
+then back.
+
+=item 3
+
+If that doesn't work, try seeking to a different part of
+the file, reading something, and then seeking back.
+
+=item 4
+
+If that doesn't work, give up on your stdio package and use sysread.
+
+=back
+
+=head2 How can I convert my shell script to perl?
+
+Learn Perl and rewrite it. Seriously, there's no simple converter.
+Things that are awkward to do in the shell are easy to do in Perl, and
+this very awkwardness is what would make a shell->perl converter
+nigh-on impossible to write. By rewriting it, you'll think about what
+you're really trying to do, and hopefully will escape the shell's
+pipeline datastream paradigm, which while convenient for some matters,
+causes many inefficiencies.
+
+=head2 Can I use perl to run a telnet or ftp session?
+
+Try the Net::FTP, TCP::Client, and Net::Telnet modules (available from
+CPAN). http://www.perl.com/CPAN/scripts/netstuff/telnet.emul.shar
+will also help for emulating the telnet protocol, but Net::Telnet is
+quite probably easier to use..
+
+If all you want to do is pretend to be telnet but don't need
+the initial telnet handshaking, then the standard dual-process
+approach will suffice:
+
+ use IO::Socket; # new in 5.004
+ $handle = IO::Socket::INET->new('www.perl.com:80')
+ || die "can't connect to port 80 on www.perl.com: $!";
+ $handle->autoflush(1);
+ if (fork()) { # XXX: undef means failure
+ select($handle);
+ print while <STDIN>; # everything from stdin to socket
+ } else {
+ print while <$handle>; # everything from socket to stdout
+ }
+ close $handle;
+ exit;
+
+=head2 How can I write expect in Perl?
+
+Once upon a time, there was a library called chat2.pl (part of the
+standard perl distribution), which never really got finished. If you
+find it somewhere, I<don't use it>. These days, your best bet is to
+look at the Expect module available from CPAN, which also requires two
+other modules from CPAN, IO::Pty and IO::Stty.
+
+=head2 Is there a way to hide perl's command line from programs such as "ps"?
+
+First of all note that if you're doing this for security reasons (to
+avoid people seeing passwords, for example) then you should rewrite
+your program so that critical information is never given as an
+argument. Hiding the arguments won't make your program completely
+secure.
+
+To actually alter the visible command line, you can assign to the
+variable $0 as documented in L<perlvar>. This won't work on all
+operating systems, though. Daemon programs like sendmail place their
+state there, as in:
+
+ $0 = "orcus [accepting connections]";
+
+=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?
+
+=over 4
+
+=item Unix
+
+In the strictest sense, it can't be done -- the script executes as a
+different process from the shell it was started from. Changes to a
+process are not reflected in its parent, only in its own children
+created after the change. There is shell magic that may allow you to
+fake it by eval()ing the script's output in your shell; check out the
+comp.unix.questions FAQ for details.
+
+=back
+
+=head2 How do I close a process's filehandle without waiting for it to complete?
+
+Assuming your system supports such things, just send an appropriate signal
+to the process (see L<perlfunc/"kill">. It's common to first send a TERM
+signal, wait a little bit, and then send a KILL signal to finish it off.
+
+=head2 How do I fork a daemon process?
+
+If by daemon process you mean one that's detached (disassociated from
+its tty), then the following process is reported to work on most
+Unixish systems. Non-Unix users should check their Your_OS::Process
+module for other solutions.
+
+=over 4
+
+=item *
+
+Open /dev/tty and use the the TIOCNOTTY ioctl on it. See L<tty(4)>
+for details. Or better yet, you can just use the POSIX::setsid()
+function, so you don't have to worry about process groups.
+
+=item *
+
+Change directory to /
+
+=item *
+
+Reopen STDIN, STDOUT, and STDERR so they're not connected to the old
+tty.
+
+=item *
+
+Background yourself like this:
+
+ fork && exit;
+
+=back
+
+=head2 How do I make my program run with sh and csh?
+
+See the F<eg/nih> script (part of the perl source distribution).
+
+=head2 How do I find out if I'm running interactively or not?
+
+Good question. Sometimes C<-t STDIN> and C<-t STDOUT> can give clues,
+sometimes not.
+
+ if (-t STDIN && -t STDOUT) {
+ print "Now what? ";
+ }
+
+On POSIX systems, you can test whether your own process group matches
+the current process group of your controlling terminal as follows:
+
+ use POSIX qw/getpgrp tcgetpgrp/;
+ open(TTY, "/dev/tty") or die $!;
+ $tpgrp = tcgetpgrp(TTY);
+ $pgrp = getpgrp();
+ if ($tpgrp == $pgrp) {
+ print "foreground\n";
+ } else {
+ print "background\n";
+ }
+
+=head2 How do I timeout a slow event?
+
+Use the alarm() function, probably in conjunction with a signal
+handler, as documented L<perlipc/"Signals"> and chapter 6 of the
+Camel. You may instead use the more flexible Sys::AlarmCall module
+available from CPAN.
+
+=head2 How do I set CPU limits?
+
+Use the BSD::Resource module from CPAN.
+
+=head2 How do I avoid zombies on a Unix system?
+
+Use the reaper code from L<perlipc/"Signals"> to call wait() when a
+SIGCHLD is received, or else use the double-fork technique described
+in L<perlfunc/fork>.
+
+=head2 How do I use an SQL database?
+
+There are a number of excellent interfaces to SQL databases. See the
+DBD::* modules available from
+http://www.perl.com/CPAN/modules/dbperl/DBD .
+A lot of information on this can be found at
+http://www.hermetica.com/technologia/perl/DBI/index.html .
+
+=head2 How do I make a system() exit on control-C?
+
+You can't. You need to imitate the system() call (see L<perlipc> for
+sample code) and then have a signal handler for the INT signal that
+passes the signal on to the subprocess. Or you can check for it:
+
+ $rc = system($cmd);
+ if ($rc & 127) { die "signal death" }
+
+=head2 How do I open a file without blocking?
+
+If you're lucky enough to be using a system that supports
+non-blocking reads (most Unixish systems do), you need only to use the
+O_NDELAY or O_NONBLOCK flag from the Fcntl module in conjunction with
+sysopen():
+
+ use Fcntl;
+ sysopen(FH, "/tmp/somefile", O_WRONLY|O_NDELAY|O_CREAT, 0644)
+ or die "can't open /tmp/somefile: $!":
+
+=head2 How do I install a CPAN module?
+
+The easiest way is to have the CPAN module do it for you. This module
+comes with perl version 5.004 and later. To manually install the CPAN
+module, or any well-behaved CPAN module for that matter, follow these
+steps:
+
+=over 4
+
+=item 1
+
+Unpack the source into a temporary area.
+
+=item 2
+
+ perl Makefile.PL
+
+=item 3
+
+ make
+
+=item 4
+
+ make test
+
+=item 5
+
+ make install
+
+=back
+
+If your version of perl is compiled without dynamic loading, then you
+just need to replace step 3 (B<make>) with B<make perl> and you will
+get a new F<perl> binary with your extension linked in.
+
+See L<ExtUtils::MakeMaker> for more details on building extensions.
+See also the next question.
+
+=head2 What's the difference between require and use?
+
+Perl offers several different ways to include code from one file into
+another. Here are the deltas between the various inclusion constructs:
+
+ 1) do $file is like eval `cat $file`, except the former:
+ 1.1: searches @INC and updates %INC.
+ 1.2: bequeaths an *unrelated* lexical scope on the eval'ed code.
+
+ 2) require $file is like do $file, except the former:
+ 2.1: checks for redundant loading, skipping already loaded files.
+ 2.2: raises an exception on failure to find, compile, or execute $file.
+
+ 3) require Module is like require "Module.pm", except the former:
+ 3.1: translates each "::" into your system's directory separator.
+ 3.2: primes the parser to disambiguate class Module as an indirect object.
+
+ 4) use Module is like require Module, except the former:
+ 4.1: loads the module at compile time, not run-time.
+ 4.2: imports symbols and semantics from that package to the current one.
+
+In general, you usually want C<use> and a proper Perl module.
+
+=head2 How do I keep my own module/library directory?
+
+When you build modules, use the PREFIX option when generating
+Makefiles:
+
+ perl Makefile.PL PREFIX=/u/mydir/perl
+
+then either set the PERL5LIB environment variable before you run
+scripts that use the modules/libraries (see L<perlrun>) or say
+
+ use lib '/u/mydir/perl';
+
+See Perl's L<lib> for more information.
+
+=head2 How do I add the directory my program lives in to the module/library search path?
+
+ use FindBin;
+ use lib "$FindBin::Bin";
+ use your_own_modules;
+
+=head2 How do I add a directory to my include path at runtime?
+
+Here are the suggested ways of modifying your include path:
+
+ the PERLLIB environment variable
+ the PERL5LIB environment variable
+ the perl -Idir commpand line flag
+ the use lib pragma, as in
+ use lib "$ENV{HOME}/myown_perllib";
+
+The latter is particularly useful because it knows about machine
+dependent architectures. The lib.pm pragmatic module was first
+included with the 5.002 release of Perl.
+
+=head1 AUTHOR AND COPYRIGHT
+
+Copyright (c) 1997, 1998 Tom Christiansen and Nathan Torkington.
+All rights reserved.
+
+When included as part of the Standard Version of Perl, or as part of
+its complete documentation whether printed or otherwise, this work
+may be distributed only under the terms of Perl's Artistic License.
+Any distribution of this file or derivatives thereof I<outside>
+of that package require that special arrangements be made with
+copyright holder.
+
+Irrespective of its distribution, all code examples in this file
+are hereby placed into the public domain. You are permitted and
+encouraged to use this code in your own programs for fun
+or for profit as you see fit. A simple comment in the code giving
+credit would be courteous but is not required.
OpenPOWER on IntegriCloud