=head1 NAME
-perlfaq8 - System Interaction ($Revision: 1.25 $, $Date: 1998/07/05 15:07:20 $)
+perlfaq8 - System Interaction ($Revision: 1.36 $, $Date: 1999/01/08 05:36:34 $)
=head1 DESCRIPTION
}
}
-
=head2 How do I decode encrypted password files?
You spend lots and lots of money on dedicated hardware, but this is
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:
+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';
$done = $start = pack($TIMEVAL_T, ());
- syscall( &SYS_gettimeofday, $start, 0)) != -1
+ syscall( &SYS_gettimeofday, $start, 0) != -1
or die "gettimeofday: $!";
##########################
=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()
+Because the pipe open takes place in two steps: first Perl calls
+fork() to start a new process, then this new process calls exec() to
+run the program you really wanted to open. The first step reports
+success or failure to your process, so open() can only tell you
+whether the fork() succeeded or not.
+
+To find out if the exec() step 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>.
+In some cases, even this won't work. If the second argument to a
+piped open() contains shell metacharacters, perl fork()s, then exec()s
+a shell to decode the metacharacters and eventually run the desired
+program. Now when you call wait(), you only learn whether or not the
+I<shell> could be successfully started. Best to avoid shell
+metacharacters.
+
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
+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?
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.
+comp.unix.questions FAQ for details.
=back
=item *
-Open /dev/tty and use the the TIOCNOTTY ioctl on it. See L<tty(4)>
+Open /dev/tty and use 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.
use POSIX qw/getpgrp tcgetpgrp/;
open(TTY, "/dev/tty") or die $!;
- $tpgrp = tcgetpgrp(TTY);
+ $tpgrp = tcgetpgrp(fileno(*TTY));
$pgrp = getpgrp();
if ($tpgrp == $pgrp) {
print "foreground\n";
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.
+ 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:
use lib '/u/mydir/perl';
+This is almost the same as:
+
+ BEGIN {
+ unshift(@INC, '/u/mydir/perl');
+ }
+
+except that the lib module checks for machine-dependent subdirectories.
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?
dependent architectures. The lib.pm pragmatic module was first
included with the 5.002 release of Perl.
+=head2 What is socket.ph and where do I get it?
+
+It's a perl4-style file defining values for system networking
+constants. Sometimes it is built using h2ph when Perl is installed,
+but other times it is not. Modern programs C<use Socket;> instead.
+
=head1 AUTHOR AND COPYRIGHT
-Copyright (c) 1997, 1998 Tom Christiansen and Nathan Torkington.
+Copyright (c) 1997-1999 Tom Christiansen and Nathan Torkington.
All rights reserved.
When included as part of the Standard Version of Perl, or as part of
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.
+
projects / p5sagit/p5-mst-13.2.git / blobdiff