|
perlfaq8 - System Interaction ($Revision: 8539 $)
This section of the Perl FAQ covers questions involving operating
system interaction. Topics include 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, the perlvms manpage, the perlplan9 manpage, ...). These should
contain more detailed information on the vagaries of your perl.
The $^O variable ($OSNAME if you use English) contains an indication of
the name of the operating system (not its release number) that your perl
binary was built for.
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.
How you access/control keyboards, screens, and pointing devices
("mice") is system-dependent. Try the following modules:
- Keyboard
-
Term::Cap Standard perl distribution
Term::ReadKey CPAN
Term::ReadLine::Gnu CPAN
Term::ReadLine::Perl CPAN
Term::Screen CPAN
- Screen
-
Term::Cap Standard perl distribution
Curses CPAN
Term::ANSIColor CPAN
- Mouse
-
Tk CPAN
Some of these specific cases are shown as examples in other answers
in this section of the perlfaq.
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;
Controlling input buffering is a remarkably system-dependent matter.
On many systems, you can just use the stty command as shown in
getc in the perlfunc manpage, 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);
sysread(TTY, $key, 1);
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 stty for each key.
It even includes limited support for Windows.
use Term::ReadKey;
ReadMode('cbreak');
$key = ReadKey(0);
ReadMode('normal');
However, using the code 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.
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);
$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;
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)) ) {
} else {
}
ReadMode('normal');
If you only have do so infrequently, use 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');
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 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";
(This question has nothing to do with the web. See a different
FAQ for that.)
There's an example of this in crypt in the perlfunc manpage). 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 the POSIX manpage or its documentation the Camel Book), or a call
to the 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);
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, device names will doubtless differ.
Several problem areas common to all device interaction are the
following:
- lockfiles
-
Your system may use lockfiles to control multiple access. Make sure
you follow the correct protocol. Unpredictable behavior can result
from multiple processes reading from one device.
- open mode
-
If you expect to use both read and write operations on the device,
you'll have to open it for update (see open in the perlfunc manpage for
details). You may wish to open it without running the risk of
blocking by using sysopen() and O_RDWR|O_NDELAY|O_NOCTTY from the
Fcntl module (part of the standard perl distribution). See
sysopen in the perlfunc manpage for more on this approach.
- 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";
print DEV "atv1\015";
-
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 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.
- 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 $| variable to control autoflushing (see $| in the perlvar manpage
and select in the perlfunc manpage, or the perlfaq5 manpage, "How do I flush/unbuffer an
output filehandle? Why must I do this?"):
-
$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 hard code your
line terminators, in that case.
- 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
alarm in the perlfunc manpage). 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
select in the perlfunc manpage.
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");
system("/bin/stty $stty");
$_ = <MODEM_IN>;
chomp;
if ( !m/^Connected/ ) {
print STDERR "$0: cu printed `$_' instead of `Connected'\n";
}
}
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).
Several modules can start other processes that do not block
your Perl program. You can use IPC::Open3, Parallel::Jobs,
IPC::Run, and some of the POE modules. See CPAN for more
details.
You could also use
system("cmd &")
or you could use fork as documented in fork in the perlfunc manpage, with
further examples in the perlipc manpage. Some things to be aware of, if you're
on a Unix-like system:
- 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
opening a pipe (see open in the perlfunc manpage) but on some systems this
means that the child process cannot outlive the parent.
- 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 system("cmd&").
- Zombies
-
You have to be prepared to "reap" the child process when it finishes.
-
$SIG{CHLD} = sub { wait };
-
$SIG{CHLD} = 'IGNORE';
-
You can also use a double fork. You immediately wait() for your
first child, and the init daemon will wait() for your grandchild once
it exits.
-
unless ($pid = fork) {
unless (fork) {
exec "what you really wanna do";
die "exec failed!";
}
exit 0;
}
waitpid($pid, 0);
-
See Signals in the perlipc manpage for other examples of code to do this.
Zombies are not an issue with system("prog &").
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 Signals in the perlipc manpage and the
section on "Signals" in the Camel.
You c | 
