Chip: Windows 2000 Professional Resource Kit

home *** CD-ROM | disk | FTP | other *** search

/ Chip: Windows 2000 Professional Resource Kit / W2KPRK.iso / apps / perl / ActivePerl.exe / data.z / perlwin32faq5.html < prev next >

Wrap

Extensible Markup Language | 1999-10-15 | 17.6 KB | 474 lines

<?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/transitional.dtd"> <html xmlns="http://www.w3.org/TR/xhtml1"> <head> <title>perlwin32faq5 - Implementation Quirks</title> <link rev="made" href="mailto:bjepson@debian.ids.net" /> <meta name="GENERATOR" charset="iso-8859-1" /> <link rel="STYLESHEET" href="../win32prk.css" type="text/css" media="screen" /> </head> <body bgcolor="#ffffff">  <table width="100%"> <tr> <td bgcolor="000000" width="70" height="31"><a href= "http://www.activestate.com/"><img src="ASbutton.gif" alt= "ActiveState Home Page" border="0" width="68" height= "30" /></a></td> <td width="10" bgcolor="#ffffff"> </td> <td valign="middle" bgcolor="#cc0066"> Win32 FAQ</td> </tr> </table>  <ul> <li><a href="#NAME">NAME</a></li> <li> <a href="#DESCRIPTION">DESCRIPTION</a> <ul> <li><a href="#Certain_functions_don_t_seem_to_">Certain functions don't seem to work on Perl for Win32.</a></li> <li><a href="#The_exec_function_doesn_t_seem_t">The exec function doesn't seem to work under Perl for ISAPI, Perl for WebSite, or PerlScript. Why not?</a></li> <li><a href="#What_s_the_difference_between_Pe">What's the difference between Perl for Win32 and the old 3xx builds?</a></li> <li><a href="#What_s_the_difference_between_ru">What's the difference between running Perl for Win32 on Windows NT</a></li> <li><a href="#Why_don_t_the_examples_from_the_">Why don't the examples from the Camel book work?</a></li> <li><a href="#Why_don_t_certain_standard_libra">Why don't certain standard library modules work?</a></li> <li><a href="#How_do_I_make_a_UNIX_based_scrip">How do I make a UNIX-based script work?</a></li> <li><a href="#How_does_the_chmod_function_work">How does the chmod function work on Win32 platforms?</a></li> <li><a href="#4DOS_doesn_t_recognize_on_the">4DOS doesn't recognize \" on the command line.</a></li> <li><a href="#STDIN_and_STDOUT_and_Piping_don">STDIN and STDOUT, and Piping don't always work on NT.</a></li> <li><a href="#Signal_Handling">Why doesn't signal handling work on Windows.</a></li> </ul> </li> <li><a href="#AUTHOR_AND_COPYRIGHT">AUTHOR AND COPYRIGHT</a></li> </ul>  <hr /> <h1><a name="NAME">NAME</a></h1> perlwin32faq5 - Implementation Quirks <hr /> <h1><a name="DESCRIPTION">DESCRIPTION</a></h1> Issues specific to the Win32 port of Perl. <hr /> <h2><a name="Certain_functions_don_t_seem_to_">Certain functions don't seem to work on Perl for Win32.</a></h2> There are several functions that are unimplemented in the Perl for Win32 system. Primary among these are <code> alarm()</code> and <code>fork(),</code> which are used in a few Perl modules. Because they're missing in Perl for Win32, you can't use those modules. Here is a complete list of unimplemented functions: <dl> <dt>Functions for processes and process groups</dt> <dd> <code>alarm(),</code> <code>fork(),</code> <code> getpgrp(),</code> <code>getppid(),</code> <code> getpriority(),</code> <code>setpgrp(),</code> <code> setpriority()</code> </dd> <dt><a name="item_Fetching">Fetching user and group info</a></dt> <dd> <code>endgrent(),</code> <code>endpwent(),</code> <code> getgrent(),</code> <code>getgrgid(),</code> <code> getgrnam(),</code> <code>getpwent(),</code> <code> getpwnam(),</code> <code>getpwuid(),</code> <code> setgrent(),</code> <code>setpwent()</code> </dd> <dt><a name="item_System">System V interprocess communication functions</a></dt> <dd> <code>msgctl(),</code> <code>msgget(),</code> <code> msgrcv(),</code> <code>msgsnd(),</code> <code> semctl(),</code> <code>semget(),</code> <code> semop(),</code> <code>shmctl(),</code> <code> shmget(),</code> <code>shmread(),</code> <code> shmwrite()</code> </dd> <dt>Functions for filehandles, files, or directories</dt> <dd> <code>link(),</code> <code>symlink(),</code> <code> chroot()</code> </dd> <dt><a name="item_Input">Input and output functions</a></dt> <dd> <code>syscall()</code> </dd> <dt>Fetching network info</dt> <dd> <code>getnetbyname(),</code> <code> getnetbyaddr(),</code> <code>getnetent(),</code> <code> getprotoent(),</code> <code>getservent(),</code> <code> sethostent(),</code> <code>setnetent(),</code> <code> setprotoent(),</code> <code>setservent(),</code> <code> endhostent(),</code> <code>endnetent(),</code> <code> endprotoent(),</code> <code>endservent(),</code> <code> socketpair()</code> </dd> </dl> See the perlport and perlwin32 documentation pages for more information on the portability of builtin functions in Perl for Win32. <hr /> <h2><a name="The_exec_function_doesn_t_seem_t">The exec function doesn't seem to work under Perl for ISAPI, Perl for WebSite, or PerlScript. Why not?</a></h2> Perl for ISAPI, Perl for WebSite, and PerlScript share a process space with the web server and any number of other extensions. As a result, the <code> exec()</code> function is unimplemented, because it would cause the web server to terminate (the <code>exec()</code> function executes a system command and never returns). <hr /> <h2><a name="What_s_the_difference_between_Pe">What's the difference between Perl for Win32 and the old 3xx builds?</a></h2> At one time, Perl on the Win32 platform was found in two versions, Gurusamy Sarathy's port, and the ActiveState port. The ActiveState port of Perl included such tools as Perl for ISAPI and PerlScript, at the expense of exposing Perl's internals in a slightly different fashion than standard Perl. Sarathy's port featured a high degree of compatibility with standard Perl, which enabled users of Sarathy's port to use many modules that were not compatible with ActiveState Perl. The oneperl effort brought both ports of Perl together, and Perl for Win32 is the standard perl distribution for the Win32 system. All modules that can be used on Win32 can be used with this port. You no longer have to worry about whose perl the module is for. Just grab it, compile it (if needed), and use it. <hr /> <h2><a name="What_s_the_difference_between_ru">What's the difference between running Perl for Win32 on Windows NT versus running it on Windows 95?</a></h2> There should be little difference between running Perl on the two operating systems. You should watch for the following, though: <ul> <li> The Win32::NetAdmin, Win32::NetResource, and Win32::EventLog modules will not run on Windows 95. </li> <li> Some functions that work on Windows NT reportedly do not work or are buggy on Windows 95. An example is <code>flock().</code> </li> <li> Finally, many helpful programs that are available on Windows NT are not there on Windows 95. <code>hostname</code>, for example, is not available on Windows 95. </li> </ul> If you're worried about using a feature from one or the other, check the result of the function Win32::IsWinNT() to see what OS you're running on. See <a href= "perlwin32faq9.html#What_modules_come_with_the_Perl_">What modules come with the Perl for Win32 distribution?</a>. <hr /> <h2><a name="Why_don_t_the_examples_from_the_">Why don't the examples from the Camel book work?</a></h2> The Camel book (aka Programming Perl, Wall et.al., O'Reilly & Associates 1996) was written by UNIX people for, in general, UNIX people. Some of the examples in the Camel book will work. Some will not. If they fail, it's because either the functions used are not available, the external tools used are not available, or the modules used are not available. Usually, for small scripts, it's not to hard to fiddle with them until they come out correct (see <a href="#How_do_I_make_a_UNIX_based_scrip">How do I make a UNIX-based script work?</a>). The Camel and Llama books are good learning tools. However, one of the things you learn as a Perl for Win32 programmer is how to port UNIX-targeted scripts and modules to Perl for Win32. For better examples of using Perl for Win32, you may want to look at the Gecko book, ``Learning Perl on Win32 Systems,'' published by O'Reilly. <hr /> <h2><a name="Why_don_t_certain_standard_libra">Why don't certain standard library modules work?</a></h2> With Perl for Win32, almost all modules will work with Perl for Win32 as long as they can be built to run on Win32. The problems that existed with the 3xx versions of Perl for Win32 no longer exist: modules work on Win32, not just this port or that port of Perl for the Win32 platform! If a module doesn't work, it may be because the functions it uses are specific to UNIX and won't work on Win32, or specific to NT and won't work on Windows 95 or Windows 98. <hr /> <h2><a name="How_do_I_make_a_UNIX_based_scrip">How do I make a UNIX-based script work?</a></h2> First, make extra-super sure that you are using the script or module in the way it was intended. Many of us are quick to blame the module, the operating system, or the interpreter when, in reality, it is our own code that isn't working right. If you're sure that it's not a problem in your code, the best way to make a UNIX-based script work is to desk-check it before running it. Look for some of the following things: <ul> <li> Calls to functions unimplemented in Perl for Win32. For a list, see <a href="#Certain_functions_don_t_seem_to_"> Certain functions don't seem to work on Perl for Win32.</a>. </li> <li> Calls to standard library modules or CPAN modules that aren't available on Perl for Win32, or that don't work. </li> <li> <code>system()</code> or backtick (``) calls to system tools that aren't available on Perl for Win32. </li> <li> Reading and writing files that may be binary. See <a href="perlwin32faq8.html#Reading_from_and_writing_to_file"> Reading from and writing to files mysteriously fails. What's wrong?</a>. </li> <li> File-system dependent path names and path name parsing. Watch for hard-coded UNIX paths like /usr/lib. </li> <li> The module or script may require a specific version of Perl or another module. Watch out for things like <code> require 5.003;</code> or <code>require Sockets 1.03;</code> Check to see if the script or module really requires the new version. </li> </ul> Of course, it should go without saying that for everything you take out you'll have to put in a work-around. Once you've worked around UNIX dependencies in the script or module, try running it through the debugger to see if what you did helps. If the script or module comes with a .t test file, try using that to test your changed version. If you do make a change to a UNIX-based script or module, please let the author know. Sometimes the author will be gracious enough to make changes that will let the program run on Perl for Win32. If the author won't change the program, ask if you can make the altered version available to other users. <hr /> <h2><a name="How_does_the_chmod_function_work">How does the chmod function work on Win32 platforms?</a></h2> <code>chmod()</code> is supported in Perl for Win32. However, it can only be used for setting "owner" read/write access. (The "group" and "other" bits are ignored.) UNIX-style security for files is not applicable to files on Win32 systems. Win32 systems inherit from DOS four possible file attributes: archived (A), read-only (R), hidden (H), and system (S). These can be checked and set with the Win32::File::Get/SetAttributes(). Windows NT systems using NTFS can also have more specific permissions granted on individual files to users and groups. For builds 300 and above, and the Perl Resource Kit for Win32, you can use the Win32::FileSecurity module to maintain file permissions. <hr /> <h2><a name="4DOS_doesn_t_recognize_on_the">4DOS doesn't recognize \" on the command line.</a></h2> 4DOS doesn't recognize the escaped quote on the command line, because all double-quote characters are seen as delimiters for command line parameters. This is one of the few points (if not the only one) where 4DOS doesn't quite match up to COMMAND.COM. To get around this, you can enter <pre> perl -e "print \"Hello, World\n\"" </pre> as <pre> perl -e "print qq(Hello, World\n)" </pre> using Perl's alternative quoting mechanism. The alternative quotes are <code>qq()</code> for double quotes, <code> q()</code> for single quotes, <code>qx()</code> for backquotes, and <code>qw()</code> for list quotes. The parentheses can be substituted for just about anything (like + or | or {} or <> or #), but that looks weird. <hr /> <h2><a name="STDIN_and_STDOUT_and_Piping_don">STDIN and STDOUT, and Piping don't always work on NT.</a></h2> You may get unexpected results when you try to redirect the output of files that use Windows NT's file association feature. You can use pl2exe or pl2bat to convert a Perl script to an executable or a batch file. This should solve any problems you may have with redirection. <hr /> <h2><a name="#Signal_Handling">Why doesn't signal handling work on Windows?</a></h2> Signals are unsupported by the Win32 API. The C Runtime provides crude support for signals, but there are serious caveats, such as inability to die() or exit() from a signal handler. Perl itself does not guarantee that signal handlers will not interrupt critical operations such as memory allocation, which means signal invocation may throw perl internals into disarray. For these reasons, signals are unsupported at this time. <hr /> <h1><a name="AUTHOR_AND_COPYRIGHT">AUTHOR AND COPYRIGHT</a></h1> This FAQ was originally assembled and maintained by Evangelo Prodromou. <a href= "mailto:evangelo@endcontsw.com">evangelo@endcontsw.com.</a> It has been revised and updated by Brian Jepson of O'Reilly and Associates, and David Grove and David Dmytryshyn of ActiveState. This FAQ is in the public domain. If you use it, however, please ensure that you give credit to the original authors.  <table width="100%"> <tr> <td bgcolor="000000" width="70" height="31"><a href= "http://www.activestate.com/"><img src="ASbutton.gif" alt= "ActiveState Home Page" border="0" width="68" height= "30" /></a></td> <td width="10"> </td> <td valign="middle" bgcolor="#cc0066"> Win32 FAQ</td> </tr> </table>  </body> </html>