ftp://ftp.software.ibm.com/ps/products/os2/tools/jaow/jaow.zip
-in F<?:\JUST_ADD\view.exe>. This gives one an access to B<EMX>'s
+in F<?:\JUST_ADD\view.exe>. This gives one an access to EMX's
F<.INF> docs as well (text form is available in F</emx/doc> in
-B<EMX>'s distribution).
+EMX's distribution).
+
+Note that if you have F<lynx.exe> installed, you can follow WWW links
+from this document in F<.INF> format. If you have EMX docs installed
+correctly, you can follow library links (you need to have C<view emxbook>
+working by setting C<EMXBOOK> environment variable as it is described
+in EMX docs).
=cut
- Target
- Other OSes
- Prerequisites
- - Starting Perl programs under OS/2
- - Starting OS/2 programs under Perl
+ - Starting Perl programs under OS/2 (and DOS and...)
+ - Starting OS/2 (and DOS) programs under Perl
Frequently asked questions
- I cannot run external programs
- I cannot embed perl into my program, or use perl.dll from my program.
- `` and pipe-open do not work under DOS.
+ - Cannot start find.exe "pattern" file
INSTALLATION
- Automatic binary installation
- Manual binary installation
- Some problem (forget which ;-)
- Library ... not found
- Segfault in make
- Specific (mis)features of OS/2 port
+ Specific (mis)features of EMX port
- setpriority, getpriority
- system()
+ - extproc on the first line
- Additional modules:
- Prebuilt methods:
- Misfeatures
- Threading
- Calls to external programs
- Memory allocation
+ - Threads
AUTHOR
SEE ALSO
The target is to make OS/2 the best supported platform for
using/building/developing Perl and I<Perl applications>, as well as
-make Perl the best language to use under OS/2.
+make Perl the best language to use under OS/2. The secondary target is
+to try to make this work under DOS and Win* as well (but not B<too> hard).
The current state is quite close to this target. Known limitations:
=item *
-There is no simple way to access B<WPS> objects. The only way I know
+There is no simple way to access WPS objects. The only way I know
is via C<OS2::REXX> extension (see L<OS2::REXX>), and we do not have access to
-convenience methods of B<Object REXX>. (Is it possible at all? I know
-of no B<Object-REXX> API.)
+convenience methods of Object-REXX. (Is it possible at all? I know
+of no Object-REXX API.)
=back
=head2 Other OSes
-Since OS/2 port of perl uses a remarkable B<EMX> environment, it can
+Since OS/2 port of perl uses a remarkable EMX environment, it can
run (and build extensions, and - possibly - be build itself) under any
environment which can run EMX. The current list is DOS,
DOS-inside-OS/2, Win0.3*, Win0.95 and WinNT. Out of many perl flavors,
Note that not all features of Perl are available under these
environments. This depends on the features the I<extender> - most
-probably C<RSX> - decided to implement.
+probably RSX - decided to implement.
Cf. L<Prerequisites>.
=over 6
-=item B<EMX>
+=item EMX
-B<EMX> runtime is required (may be substituted by B<RSX>). Note that
+EMX runtime is required (may be substituted by RSX). Note that
it is possible to make F<perl_.exe> to run under DOS without any
external support by binding F<emx.exe>/F<rsx.exe> to it, see L<emxbind>. Note
-that under DOS for best results one should use B<RSX> runtime, which
+that under DOS for best results one should use RSX runtime, which
has much more functions working (like C<fork>, C<popen> and so on). In
-fact B<RSX> is required if there is no C<VCPI> present. Note the
-B<RSX> requires C<DPMI>.
+fact RSX is required if there is no VCPI present. Note the
+RSX requires DPMI.
-Only the latest runtime is supported, currently C<0.9c>.
+Only the latest runtime is supported, currently C<0.9c>. Perl may run
+under earlier versions of EMX, but this is not tested.
-One can get different parts of B<EMX> from, say
+One can get different parts of EMX from, say
- ftp://ftp.cdrom.com/pub/os2/emx0.9c/
- ftp://hobbes.nmsu.edu/os2/unix/gnu/
+ ftp://ftp.cdrom.com/pub/os2/emx09c/
+ ftp://hobbes.nmsu.edu/os2/unix/emx09c/
The runtime component should have the name F<emxrt.zip>.
will work as well.)
-=item B<RSX>
+=item RSX
-To run Perl on C<DPMI> platforms one needs B<RSX> runtime. This is
+To run Perl on DPMI platforms one needs RSX runtime. This is
needed under DOS-inside-OS/2, Win0.3*, Win0.95 and WinNT (see
-L<"Other OSes">). B<RSX> would not work with C<VCPI>
-only, as B<EMX> would, it requires C<DMPI>.
+L<"Other OSes">). RSX would not work with VCPI
+only, as EMX would, it requires DMPI.
-Having B<RSX> and the latest F<sh.exe> one gets a fully functional
+Having RSX and the latest F<sh.exe> one gets a fully functional
B<*nix>-ish environment under DOS, say, C<fork>, C<``> and
pipe-C<open> work. In fact, MakeMaker works (for static build), so one
can have Perl development environment under DOS.
-One can get B<RSX> from, say
+One can get RSX from, say
- ftp://ftp.cdrom.com/pub/os2/emx0.9c/contrib
+ ftp://ftp.cdrom.com/pub/os2/emx09c/contrib
ftp://ftp.uni-bielefeld.de/pub/systems/msdos/misc
+ ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/contrib
Contact the author on C<rainer@mathematik.uni-bielefeld.de>.
The latest F<sh.exe> with DOS hooks is available at
- ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.exe
+ ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.zip
-=item B<HPFS>
+=item HPFS
Perl does not care about file systems, but to install the whole perl
library intact one needs a file system which supports long file names.
Note that if you do not plan to build the perl itself, it may be
-possible to fool B<EMX> to truncate file names. This is not supported,
-read B<EMX> docs to see how to do it.
+possible to fool EMX to truncate file names. This is not supported,
+read EMX docs to see how to do it.
+
+=item pdksh
+
+To start external programs with complicated command lines (like with
+pipes in between, and/or quoting of arguments), Perl uses an external
+shell. With EMX port such shell should be named <sh.exe>, and located
+either in the wired-in-during-compile locations (usually F<F:/bin>),
+or in configurable location (see L<"PERL_SH_DIR">).
+
+For best results use EMX pdksh. The soon-to-be-available standard
+binary (5.2.12?) runs under DOS (with L<RSX>) as well, meanwhile use
+the binary from
+
+ ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.zip
=back
-=head2 Starting Perl programs under OS/2
+=head2 Starting Perl programs under OS/2 (and DOS and...)
Start your Perl program F<foo.pl> with arguments C<arg1 arg2 arg3> the
same way as on any other platform, by
perl -my_opts foo.pl arg1 arg2 arg3
-Alternately, if you use OS/2-ish shell, like C<CMD> or C<4os2>, put
+Alternately, if you use OS/2-ish shell, like CMD or 4os2, put
the following at the start of your perl script:
- extproc perl -x -S
- #!/usr/bin/perl -my_opts
+ extproc perl -S -my_opts
rename your program to F<foo.cmd>, and start it by typing
foo arg1 arg2 arg3
-(Note that having *nixish full path to perl F</usr/bin/perl> is not
-necessary, F<perl> would be enough, but having full path would make it
-easier to use your script under *nix.)
-
Note that because of stupid OS/2 limitations the full path of the perl
script is not available when you use C<extproc>, thus you are forced to
use C<-S> perl switch, and your script should be on path. As a plus
side, if you know a full path to your script, you may still start it
with
- perl -x ../../blah/foo.cmd arg1 arg2 arg3
+ perl ../../blah/foo.cmd arg1 arg2 arg3
-(note that the argument C<-my_opts> is taken care of by the C<#!> line
-in your script).
+(note that the argument C<-my_opts> is taken care of by the C<extproc> line
+in your script, see L<C<extproc> on the first line>).
To understand what the above I<magic> does, read perl docs about C<-S>
-
and C<-x> switches - see L<perlrun>, and cmdref about C<extproc>:
+
switch - see L<perlrun>, and cmdref about C<extproc>:
view perl perlrun
man perlrun
or whatever method you prefer.
There are also endless possibilities to use I<executable extensions> of
-B<4OS2>, I<associations> of B<WPS> and so on... However, if you use
+4os2, I<associations> of WPS and so on... However, if you use
*nixish shell (like F<sh.exe> supplied in the binary distribution),
you need to follow the syntax specified in L<perlrun/"Switches">.
-=head2 Starting OS/2 programs under Perl
+Note that B<-S> switch enables a search with additional extensions
+F<.cmd>, F<.btm>, F<.bat>, F<.pl> as well.
+
+=head2 Starting OS/2 (and DOS) programs under Perl
This is what system() (see L<perlfunc/system>), C<``> (see
L<perlop/"I/O Operators">), and I<open pipe> (see L<perlfunc/open>)
do).
Note however that to use some of these operators you need to have a
-C<sh>-syntax shell installed (see L<"Pdksh">,
+sh-syntax shell installed (see L<"Pdksh">,
L<"Frequently asked questions">), and perl should be able to find it
(see L<"PERL_SH_DIR">).
-The only cases when the shell is not used is the multi-argument
-system() (see L<perlfunc/system>)/exec() (see L<perlfunc/exec>), and
-one-argument version thereof without redirection and shell
-meta-characters.
+The cases when the shell is used are:
+
+=over
+
+=item 1
+
+One-argument system() (see L<perlfunc/system>), exec() (see L<perlfunc/exec>)
+with redirection or shell meta-characters;
+
+=item 2
+
+Pipe-open (see L<perlfunc/open>) with the command which contains redirection
+or shell meta-characters;
+
+=item 3
+
+Backticks C<``> (see L<perlop/"I/O Operators">) with the command which contains
+redirection or shell meta-characters;
+
+=item 4
+
+If the executable called by system()/exec()/pipe-open()/C<``> is a script
+with the "magic" C<#!> line or C<extproc> line which specifies shell;
+
+=item 5
+
+If the executable called by system()/exec()/pipe-open()/C<``> is a script
+without "magic" line, and C<$ENV{EXECSHELL}> is set to shell;
+
+=item 6
+
+If the executable called by system()/exec()/pipe-open()/C<``> is not
+found;
+
+=item 7
+
+For globbing (see L<perlfunc/glob>, L<perlop/"I/O Operators">).
+
+=back
+
+For the sake of speed for a common case, in the above algorithms
+backslashes in the command name are not considered as shell metacharacters.
+
+Perl starts scripts which begin with cookies
+C<extproc> or C<#!> directly, without an intervention of shell. Perl uses the
+same algorithm to find the executable as F<pdksh>: if the path
+on C<#!> line does not work, and contains C</>, then the executable
+is searched in F<.> and on C<PATH>. To find arguments for these scripts
+Perl uses a different algorithm than F<pdksh>: up to 3 arguments are
+recognized, and trailing whitespace is stripped.
+
+If a script
+does not contain such a cooky, then to avoid calling F<sh.exe>, Perl uses
+the same algorithm as F<pdksh>: if C<$ENV{EXECSHELL}> is set, the
+script is given as the first argument to this command, if not set, then
+C<$ENV{COMSPEC} /c> is used (or a hardwired guess if C<$ENV{COMSPEC}> is
+not set).
+
+If starting scripts directly, Perl will use exactly the same algorithm as for
+the search of script given by B<-S> command-line option: it will look in
+the current directory, then on components of C<$ENV{PATH}> using the
+following order of appended extensions: no extension, F<.cmd>, F<.btm>,
+F<.bat>, F<.pl>.
+
+Note that Perl will start to look for scripts only if OS/2 cannot start the
+specified application, thus C<system 'blah'> will not look for a script if
+there is an executable file F<blah.exe> I<anywhere> on C<PATH>.
+
+Note also that executable files on OS/2 can have an arbitrary extension,
+but F<.exe> will be automatically appended if no dot is present in the name.
+The workaround as as simple as that: since F<blah.> and F<blah> denote the
+same file, to start an executable residing in file F<n:/bin/blah> (no
+extension) give an argument C<n:/bin/blah.> to system().
+
+The last note is that currently it is not straightforward to start PM
+programs from VIO (=text-mode) Perl process and visa versa. Either ensure
+that shell will be used, as in C<system 'cmd /c epm'>, or start it using
+optional arguments to system() documented in C<OS2::Process> module. This
+is considered a bug and should be fixed soon.
+
=head1 Frequently asked questions
=item
Did you run your programs with C<-w> switch? See
-L<Starting OS/2 programs under Perl>.
+L<Starting OS/2 (and DOS) programs under Perl>.
=item
=over 4
-=item Is your program B<EMX>-compiled with C<-Zmt -Zcrtdll>?
+=item Is your program EMX-compiled with C<-Zmt -Zcrtdll>?
If not, you need to build a stand-alone DLL for perl. Contact me, I
did it once. Sockets would not work, as a lot of other stuff.
-=item Did you use C<ExtUtils::Embed>?
+=item Did you use L<ExtUtils::Embed>?
I had reports it does not work. Somebody would need to fix it.
=head2 C<``> and pipe-C<open> do not work under DOS.
This may a variant of just L<"I cannot run external programs">, or a
-deeper problem. Basically: you I<need> B<RSX> (see L<"Prerequisites">)
+deeper problem. Basically: you I<need> RSX (see L<"Prerequisites">)
for these commands to work, and you may need a port of F<sh.exe> which
understands command arguments. One of such ports is listed in
-L<"Prerequisites"> under B<RSX>.
+L<"Prerequisites"> under RSX. Do not forget to set variable
+C<L<"PERL_SH_DIR">> as well.
+
+DPMI is required for RSX.
+
+=head2 Cannot start C<find.exe "pattern" file>
+
+Use one of
+
+ system 'cmd', '/c', 'find "pattern" file';
+ `cmd /c 'find "pattern" file'`
-C<DPMI> is required for B<RSX>.
+This would start F<find.exe> via F<cmd.exe> via C<sh.exe> via
+C<perl.exe>, but this is a price to pay if you want to use
+non-conforming program. In fact F<find.exe> cannot be started at all
+using C library API only. Otherwise the following command-lines were
+equivalent:
+
+ find "pattern" file
+ find pattern file
=head1 INSTALLATION
installation blues would go away.
Note however, that you need to have F<unzip.exe> on your path, and
-B<EMX> environment I<running>. The latter means that if you just
-installed B<EMX>, and made all the needed changes to F<Config.sys>,
-you may need to reboot in between. Check B<EMX> runtime by running
+EMX environment I<running>. The latter means that if you just
+installed EMX, and made all the needed changes to F<Config.sys>,
+you may need to reboot in between. Check EMX runtime by running
emxrev
=item C<PERL_BADLANG>
may be needed if you change your codepage I<after> perl installation,
-and the new value is not supported by B<EMX>. See L<"PERL_BADLANG">.
+and the new value is not supported by EMX. See L<"PERL_BADLANG">.
=item C<PERL_BADFREE>
=back
+B<NOTE>. Because of a typo the binary installer of 5.00305
+would install a variable C<PERL_SHPATH> into F<Config.sys>. Please
+remove this variable and put C<L<PERL_SH_DIR>> instead.
+
=head2 Manual binary installation
As of version 5.00305, OS/2 perl binary distribution comes split
into 11 components. Unfortunately, to enable configurable binary
-installation, the file paths in the C<zip> files are not absolute, but
+installation, the file paths in the zip files are not absolute, but
relative to some directory.
Note that the extraction with the stored paths is still necessary
-(default with C<unzip>, specify C<-d> to C<pkunzip>). However, you
+(default with unzip, specify C<-d> to pkunzip). However, you
need to know where to extract the files. You need also to manually
change entries in F<Config.sys> to reflect where did you put the
files. Note that if you have some primitive unzipper (like
-C<pkunzip>), you may get a lot of warnings/errors during
+pkunzip), you may get a lot of warnings/errors during
unzipping. Upgrade to C<(w)unzip>.
Below is the sample of what to do to reproduce the configuration on my
unzip perl_exc.zip *.exe *.ico -d f:/emx.add/bin
unzip perl_exc.zip *.dll -d f:/emx.add/dll
-(have the directories with C<*.exe> on C<PATH>, and C<*.dll> on
-C<LIBPATH>);
+(have the directories with C<*.exe> on PATH, and C<*.dll> on
+LIBPATH);
=item Perl_ VIO executable (statically linked)
unzip perl_aou.zip -d f:/emx.add/bin
-(have the directory on C<PATH>);
+(have the directory on PATH);
=item Executables for Perl utilities
unzip perl_utl.zip -d f:/emx.add/bin
-(have the directory on C<PATH>);
+(have the directory on PATH);
=item Main Perl library
unzip perl_man.zip -d f:/perllib/man
This directory should better be on C<MANPATH>. You need to have a
-working C<man> to access these files.
+working man to access these files.
=item Manpages for Perl modules
unzip perl_mam.zip -d f:/perllib/man
This directory should better be on C<MANPATH>. You need to have a
-working C<man> to access these files.
+working man to access these files.
=item Source for Perl documentation
unzip perl_pod.zip -d f:/perllib/lib
This is used by by C<perldoc> program (see L<perldoc>), and may be used to
-generate B<HTML> documentation usable by WWW browsers, and
+generate HTML documentation usable by WWW browsers, and
documentation in zillions of other formats: C<info>, C<LaTeX>,
C<Acrobat>, C<FrameMaker> and so on.
-=item Perl manual in .INF format
+=item Perl manual in F<.INF> format
unzip perl_inf.zip -d d:/os2/book
Set C<PERL_SH_DIR> (see L<"PERL_SH_DIR">) if you move F<sh.exe> from
the above location.
-B<Note.> It may be possible to use some other C<sh>-compatible shell
+B<Note.> It may be possible to use some other sh-compatible shell
(I<not tested>).
=back
=head2 OS/2 F<.INF> file
-Most probably the most convenient form. View it as
+Most probably the most convenient form. Under OS/2 view it as
view perl
view perl perlfunc
view perl ExtUtils::MakeMaker
(currently the last two may hit a wrong location, but this may improve
-soon).
+soon). Under Win* see L<"SYNOPSIS">.
If you want to build the docs yourself, and have I<OS/2 toolkit>, run
=head2 Plain text
If you have perl documentation in the source form, perl utilities
-installed, and B<GNU> C<groff> installed, you may use
+installed, and GNU groff installed, you may use
perldoc perlfunc
perldoc less
=head2 Manpages
-If you have C<man> installed on your system, and you installed perl
+If you have man installed on your system, and you installed perl
manpages, use something like this:
man perlfunc
set MANPATH=c:/man;f:/perllib/man
-=head2 B<HTML>
+=head2 HTML
If you have some WWW browser available, installed the Perl
documentation in the source form, and Perl utilities, you can build
-B<HTML> docs. Cd to directory with F<.pod> files, and do like this
+HTML docs. Cd to directory with F<.pod> files, and do like this
cd f:/perllib/lib/pod
pod2html
explore file:///f:/perllib/lib/pod/perl.html
-Alternatively you may be able to get these docs prebuilt from C<CPAN>.
+Alternatively you may be able to get these docs prebuilt from CPAN.
-=head2 B<GNU> C<info> files
+=head2 GNU C<info> files
-Users of C<Emacs> would appreciate it very much, especially with
+Users of Emacs would appreciate it very much, especially with
C<CPerl> mode loaded. You need to get latest C<pod2info> from C<CPAN>,
or, alternately, prebuilt info pages.
=head2 Prerequisites
-You need to have the latest B<EMX> development environment, the full
-B<GNU> tool suite (C<gawk> renamed to C<awk>, and B<GNU> F<find.exe>
+You need to have the latest EMX development environment, the full
+GNU tool suite (gawk renamed to awk, and GNU F<find.exe>
earlier on path than the OS/2 F<find.exe>, same with F<sort.exe>, to
check use
). You need the latest version of F<pdksh> installed as F<sh.exe>.
+Check that you have B<BSD> libraries and headers installed, and -
+optionally - Berkeley DB headers and libraries, and crypt.
+
Possible locations to get this from are
- ftp://hobbes.nmsu.edu/os2/unix/gnu/
+ ftp://hobbes.nmsu.edu/os2/unix/
ftp://ftp.cdrom.com/pub/os2/unix/
ftp://ftp.cdrom.com/pub/os2/dev32/
- ftp://ftp.cdrom.com/pub/os2/emx0.9c/
+ ftp://ftp.cdrom.com/pub/os2/emx09c/
+
+It is reported that the following archives contain enough utils to
+build perl: gnufutil.zip, gnusutil.zip, gnututil.zip, gnused.zip,
+gnupatch.zip, gnuawk.zip, gnumake.zip and ksh527rt.zip. Note that
+all these utilities are known to be available from LEO:
+ ftp://ftp.leo.org/pub/comp/os/os2/leo/gnu
Make sure that no copies or perl are currently running. Later steps
of the build may fail since an older version of perl.dll loaded into
if you use something like F<CMD.EXE> or latest versions of F<4os2.exe>.
-Make sure your C<gcc> is good for C<-Zomf> linking: run C<omflibs>
+Make sure your gcc is good for C<-Zomf> linking: run C<omflibs>
script in F</emx/lib> directory.
-Check that you have C<link386> installed. It comes standard with OS/2,
+Check that you have link386 installed. It comes standard with OS/2,
but may be not installed due to customization. If typing
link386
shows you do not have it, do I<Selective install>, and choose C<Link
object modules> in I<Optional system utilities/More>. If you get into
-C<link386>, press C<Ctrl-C>.
+link386, press C<Ctrl-C>.
=head2 Getting perl source
You may see a message about errors while extracting F<Configure>. This is
because there is a conflict with a similarly-named file F<configure>.
-Rename F<configure> to F<configure.gnu>. Extract F<Configure> like this
-
- tar --case-sensitive -vzxf perl5.00409.tar.gz perl5.00409/Configure
-
Change to the directory of extraction.
=head2 Application of the patches
You may also need to apply the patches supplied with the binary
distribution of perl.
-Note also that the F<db.lib> and F<db.a> from the B<EMX> distribution
+Note also that the F<db.lib> and F<db.a> from the EMX distribution
are not suitable for multi-threaded compile (note that currently perl
-is not multithreaded, but is compiled as multithreaded for
-compatibility with B<XFree86>-OS/2). Get a corrected one from
+is not multithread-safe, but is compiled as multithreaded for
+compatibility with XFree86-OS/2). Get a corrected one from
ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/db_mt.zip
+To make C<-p> filetest work, one may also need to apply the following patch
+to EMX headers:
+
+ --- /emx/include/sys/stat.h.orig Thu May 23 13:48:16 1996
+ +++ /emx/include/sys/stat.h Sun Jul 12 14:11:32 1998
+ @@ -53,7 +53,7 @@ struct stat
+ #endif
+
+ #if !defined (S_IFMT)
+ -#define S_IFMT 0160000 /* Mask for file type */
+ +#define S_IFMT 0170000 /* Mask for file type */
+ #define S_IFIFO 0010000 /* Pipe */
+ #define S_IFCHR 0020000 /* Character device */
+ #define S_IFDIR 0040000 /* Directory */
+
+
=head2 Hand-editing
You may look into the file F<./hints/os2.sh> and correct anything
sh Configure -des -D prefix=f:/perllib
-Prefix means where to install the resulting perl library. Giving
+C<prefix> means: where to install the resulting perl library. Giving
correct prefix you may avoid the need to specify C<PERLLIB_PREFIX>,
see L<"PERLLIB_PREFIX">.
I<Ignore the message about missing C<ln>, and about C<-c> option to
-C<tr>>. In fact if you can trace where the latter spurious warning
+tr>. In fact if you can trace where the latter spurious warning
comes from, please inform me.
Now
At some moment the built may die, reporting a I<version mismatch> or
I<unable to run F<perl>>. This means that most of the build has been
finished, and it is the time to move the constructed F<perl.dll> to
-some I<absolute> location in C<LIBPATH>. After this done the build
-should finish without a lot of fuss. I<One can avoid it if one has the
-correct prebuilt version of F<perl.dll> on C<LIBPATH>.>
+some I<absolute> location in LIBPATH. After this is done the build
+should finish without a lot of fuss. I<One can avoid the interruption
+if one has the correct prebuilt version of F<perl.dll> on LIBPATH, but
+probably this is not needed anymore, since F<miniperl.exe> is linked
+statically now.>
Warnings which are safe to ignore: I<mkfifo() redefined> inside
F<POSIX.c>.
=head2 Testing
+If you haven't yet moved perl.dll onto LIBPATH, do it now (alternatively, if
+you have a previous perl installation you'd rather not disrupt until this one
+is installed, copy perl.dll to the t directory).
+
Now run
make test
-Some tests (4..6) should fail. Some perl invocations should end in a
-segfault (system error C<SYS3175>). To get finer error reports,
+All tests should succeed (with some of them skipped). Note that on one
+of the systems I see intermittent failures of F<io/pipe.t> subtest 9.
+Any help to track what happens with this test is appreciated.
- cd t
- perl -I ../lib harness
+Some tests may generate extra messages similar to
-The report you get may look like
+=over 4
- Failed Test Status Wstat Total Fail Failed List of failed
- ---------------------------------------------------------------
- io/fs.t 26 11 42.31% 2-5, 7-11, 18, 25
- lib/io_pipe.t 3 768 6 ?? % ??
- lib/io_sock.t 3 768 5 ?? % ??
- op/stat.t 56 5 8.93% 3-4, 20, 35, 39
- Failed 4/140 test scripts, 97.14% okay. 27/2937 subtests failed, 99.08% okay.
+=item A lot of C<bad free>
-Note that using `make test' target two more tests may fail: C<op/exec:1>
-because of (mis)feature of C<pdksh>, and C<lib/posix:15>, which checks
-that the buffers are not flushed on C<_exit> (this is a bug in the test
-which assumes that tty output is buffered).
+in database tests related to Berkeley DB. This is a confirmed bug of
+DB. You may disable this warnings, see L<"PERL_BADFREE">.
-I submitted a patch to B<EMX> which makes it possible to fork() with EMX
-dynamic libraries loaded, which makes F<lib/io*> tests pass. This means
-that soon the number of failing tests may decrease yet more.
+There is not much we can do with it (but apparently it does not cause
+any real error with data).
-However, the test F<lib/io_udp.t> is disabled, since it never terminates, I
-do not know why. Comments/fixes welcome.
+=item Process terminated by SIGTERM/SIGINT
-The reasons for failed tests are:
+This is a standard message issued by OS/2 applications. *nix
+applications die in silence. It is considered a feature. One can
+easily disable this by appropriate sighandlers.
-=over 8
+However the test engine bleeds these message to screen in unexpected
+moments. Two messages of this kind I<should> be present during
+testing.
+
+=back
-=item F<io/fs.t>
+Two F<lib/io_*> tests may generate popups (system error C<SYS3175>),
+but should succeed anyway. This is due to a bug of EMX related to
+fork()ing with dynamically loaded libraries.
-Checks I<file system> operations. Tests:
+I submitted a patch to EMX which makes it possible to fork() with EMX
+dynamic libraries loaded, which makes F<lib/io*> tests pass without
+skipping offended tests. This means that soon the number of skipped tests
+may decrease yet more.
-=over 10
+To get finer test reports, call
-=item 2-5, 7-11
+ perl t/harness
-Check C<link()> and C<inode count> - nonesuch under OS/2.
+The report with F<io/pipe.t> failing may look like this:
+
+ Failed Test Status Wstat Total Fail Failed List of failed
+ ------------------------------------------------------------
+ io/pipe.t 12 1 8.33% 9
+ 7 tests skipped, plus 56 subtests skipped.
+ Failed 1/195 test scripts, 99.49% okay. 1/6542 subtests failed, 99.98% okay.
+
+The reasons for most important skipped tests are:
+
+=over 8
+
+=item F<op/fs.t>
=item 18
-Checks C<atime> and C<mtime> of C<stat()> - I could not understand this test.
+Checks C<atime> and C<mtime> of C<stat()> - unfortunately, HPFS
+provides only 2sec time granularity (for compatibility with FAT?).
=item 25
=item F<lib/io_pipe.t>
-Checks C<IO::Pipe> module. Some feature of B<EMX> - test fork()s with
+Checks C<IO::Pipe> module. Some feature of EMX - test fork()s with
dynamic extension loaded - unsupported now.
=item F<lib/io_sock.t>
-Checks C<IO::Socket> module. Some feature of B<EMX> - test fork()s
+Checks C<IO::Socket> module. Some feature of EMX - test fork()s
with dynamic extension loaded - unsupported now.
=item F<op/stat.t>
=over 4
-=item 3
-
-Checks C<inode count> - nonesuch under OS/2.
-
=item 4
-Checks C<mtime> and C<ctime> of C<stat()> - I could not understand this test.
-
-=item 20
-
-Checks C<-x> - determined by the file extension only under OS/2.
-
-=item 35
-
-Needs F</usr/bin>.
-
-=item 39
-
-Checks C<-t> of F</dev/null>. Should not fail!
-
-=back
+Checks C<atime> and C<mtime> of C<stat()> - unfortunately, HPFS
+provides only 2sec time granularity (for compatibility with FAT?).
=back
-In addition to errors, you should get a lot of warnings.
-
-=over 4
-
-=item A lot of `bad free'
-
-in databases related to Berkeley DB. This is a confirmed bug of
-DB. You may disable this warnings, see L<"PERL_BADFREE">.
-
-=item Process terminated by SIGTERM/SIGINT
-
-This is a standard message issued by OS/2 applications. *nix
-applications die in silence. It is considered a feature. One can
-easily disable this by appropriate sighandlers.
-
-However the test engine bleeds these message to screen in unexpected
-moments. Two messages of this kind I<should> be present during
-testing.
-
-=item F<*/sh.exe>: ln: not found
+=item F<lib/io_udp.t>
-=item C<ls>: /dev: No such file or directory
-
-The last two should be self-explanatory. The test suite discovers that
-the system it runs on is not I<that much> *nixish.
+It never terminates, apparently some bug in storing the last socket from
+which we obtained a message.
=back
-A lot of `bad free'... in databases, bug in DB confirmed on other
-platforms. You may disable it by setting PERL_BADFREE environment variable
-to 1.
-
=head2 Installing the built perl
+If you haven't yet moved perl.dll onto LIBPATH, do it now.
+
Run
make install
It would put the generated files into needed locations. Manually put
F<perl.exe>, F<perl__.exe> and F<perl___.exe> to a location on your
-C<PATH>, F<perl.dll> to a location on your C<LIBPATH>.
+PATH, F<perl.dll> to a location on your LIBPATH.
Run
make cmdscripts INSTALLCMDDIR=d:/ir/on/path
to convert perl utilities to F<.cmd> files and put them on
-C<PATH>. You need to put F<.EXE>-utilities on path manually. They are
+PATH. You need to put F<.EXE>-utilities on path manually. They are
installed in C<$prefix/bin>, here C<$prefix> is what you gave to
F<Configure>, see L<Making>.
make aout_test
make aout_install
-Manually put F<perl_.exe> to a location on your C<PATH>.
+Manually put F<perl_.exe> to a location on your PATH.
Since C<perl_> has the extensions prebuilt, it does not suffer from
the I<dynamic extensions + fork()> syndrome, thus the failing tests
You do not have MT-safe F<db.lib>. See L<Prerequisites>.
-=head2 Problems with C<tr>
+=head2 Problems with tr or sed
-reported with very old version of C<tr>.
+reported with very old version of tr and sed.
=head2 Some problem (forget which ;-)
-You have an older version of F<perl.dll> on your C<LIBPATH>, which
+You have an older version of F<perl.dll> on your LIBPATH, which
broke the build of extensions.
=head2 Library ... not found
=head2 Segfault in make
-You use an old version of
C<GNU> make. See L<Prerequisites>.
+You use an old version of
GNU make. See L<Prerequisites>.
=head1 Specific (mis)features of OS/2 port
argument. The meaning of this argument is described in
L<OS2::Process>.
+=head2 C<extproc> on the first line
+
+If the first chars of a script are C<"extproc ">, this line is treated
+as C<#!>-line, thus all the switches on this line are processed (twice
+if script was started via cmd.exe).
+
=head2 Additional modules:
-L<OS2::Process>, L<OS2::REXX>, L<OS2::PrfDB>, L<OS2::ExtAttr>. This
-modules provide access to additional numeric argument for C<system>,
+L<OS2::Process>, L<OS2::REXX>, L<OS2::PrfDB>, L<OS2::ExtAttr>. These
+modules provide access to additional numeric argument for C<system>
+and to the list of the running processes,
to DLLs having functions with REXX signature and to REXX runtime, to
OS/2 databases in the F<.INI> format, and to Extended Attributes.
=item C<File::Copy::syscopy>
-used by C<File::Copy::copy>, see L<File::Copy/copy>.
+used by C<File::Copy::copy>, see L<File::Copy>.
=item C<DynaLoader::mod2fname>
=item C<Cwd::sys_cwd(name)>
-Interface to cwd from B<EMX>. Used by C<Cwd::cwd>.
+Interface to cwd from EMX. Used by C<Cwd::cwd>.
=item C<Cwd::sys_abspath(name, dir)>
=item
-Since <flock> is present in B<EMX>, but is not functional, the same is
-true for perl. Here is the list of things which may be "broken" on
+Since L<flock(3)> is present in EMX, but is not functional, it is
+emulated by perl. To disable the emulations, set environment variable
+C<USE_PERL_FLOCK=0>.
+
+=item
+
+Here is the list of things which may be "broken" on
EMX (from EMX docs):
- - The functions recvmsg(), sendmsg(), and socketpair() are not
- implemented.
- - sock_init() is not required and not implemented.
- - flock() is not yet implemented (dummy function).
- - kill:
- Special treatment of PID=0, PID=1 and PID=-1 is not implemented.
- - waitpid:
+=over
+
+=item *
+
+The functions L<recvmsg(3)>, L<sendmsg(3)>, and L<socketpair(3)> are not
+implemented.
+
+=item *
+
+L<sock_init(3)> is not required and not implemented.
+
+=item *
+
+L<flock(3)> is not yet implemented (dummy function). (Perl has a workaround.)
+
+=item *
+
+L<kill(3)>: Special treatment of PID=0, PID=1 and PID=-1 is not implemented.
+
+=item *
+
+L<waitpid(3)>:
+
WUNTRACED
Not implemented.
waitpid() is not implemented for negative values of PID.
+=back
+
Note that C<kill -9> does not work with the current version of EMX.
=item
of F<sh.exe> plague perl as well.
In particular, uppercase letters do not work in C<[...]>-patterns with
-the current C<pdksh>.
+the current pdksh.
=back
C<os2_stat> special-cases F</dev/tty> and F</dev/con>.
+=item C<flock>
+
+Since L<flock(3)> is present in EMX, but is not functional, it is
+emulated by perl. To disable the emulations, set environment variable
+C<USE_PERL_FLOCK=0>.
+
=back
=head1 Perl flavors
Because of idiosyncrasies of OS/2 one cannot have all the eggs in the
-same basket (though C<EMX> environment tries hard to overcome this
+same basket (though EMX environment tries hard to overcome this
limitations, so the situation may somehow improve). There are 4
executables for Perl provided by the distribution:
The main workhorse. This is a chimera executable: it is compiled as an
C<a.out>-style executable, but is linked with C<omf>-style dynamic
-library F<perl.dll>, and with dynamic B<CRT> DLL. This executable is a
-C<VIO> application.
+library F<perl.dll>, and with dynamic CRT DLL. This executable is a
+VIO application.
It can load perl dynamic extensions, and it can fork(). Unfortunately,
-with the current version of B<EMX> it cannot fork() with dynamic
-extensions loaded (may be fixed by patches to B<EMX>).
+with the current version of EMX it cannot fork() with dynamic
+extensions loaded (may be fixed by patches to EMX).
B<Note.> Keep in mind that fork() is needed to open a pipe to yourself.
but cannot load dynamic Perl extensions. The supplied executable has a
lot of extensions prebuilt, thus there are situations when it can
perform tasks not possible using F<perl.exe>, like fork()ing when
-having some standard extension loaded. This executable is a C<VIO>
+having some standard extension loaded. This executable is a VIO
application.
B<Note.> A better behaviour could be obtained from C<perl.exe> if it
were statically linked with standard I<Perl extensions>, but
-dynamically linked with the I<Perl DLL> and C<CRT> DLL. Then it would
+dynamically linked with the I<Perl DLL> and CRT DLL. Then it would
be able to fork() with standard extensions, I<and> would be able to
dynamically load arbitrary extensions. Some changes to Makefiles and
hint files should be necessary to achieve this.
=head2 F<perl__.exe>
-This is the same executable as <perl___.exe>, but it is a C<PM>
+This is the same executable as F<perl___.exe>, but it is a PM
application.
-B<Note.> Usually C<STDIN>, C<STDERR>, and C<STDOUT> of a C<PM>
+B<Note.> Usually STDIN, STDERR, and STDOUT of a PM
application are redirected to C<nul>. However, it is possible to see
them if you start C<perl__.exe> from a PM program which emulates a
-console window, like I<Shell mode> of C<Emacs> or C<EPM>. Thus it I<is
+console window, like I<Shell mode> of Emacs or EPM. Thus it I<is
possible> to use Perl debugger (see L<perldebug>) to debug your PM
application.
-This flavor is required if you load extensions which use C<PM>, like
+This flavor is required if you load extensions which use PM, like
the forthcoming C<Perl/Tk>.
=head2 F<perl___.exe>
This is an C<omf>-style executable which is dynamically linked to
-F<perl.dll> and C<CRT> DLL. I know no advantages of this executable
+F<perl.dll> and CRT DLL. I know no advantages of this executable
over C<perl.exe>, but it cannot fork() at all. Well, one advantage is
that the build process is not so convoluted as with C<perl.exe>.
-It is a C<VIO> application.
+It is a VIO application.
=head2 Why strange names?
This I<greatly> increases the load time for the application (as well as
the number of problems during compilation). Since interpreter is in a DLL,
-the C<CRT> is basically forced to reside in a DLL as well (otherwise
-extensions would not be able to use C<CRT>).
+the CRT is basically forced to reside in a DLL as well (otherwise
+extensions would not be able to use CRT).
=head2 Why chimera build?
-Current C<EMX> environment does not allow DLLs compiled using Unixish
+Current EMX environment does not allow DLLs compiled using Unixish
C<a.out> format to export symbols for data. This forces C<omf>-style
compile of F<perl.dll>.
-Current C<EMX> environment does not allow F<.EXE> files compiled in
+Current EMX environment does not allow F<.EXE> files compiled in
C<omf> format to fork(). fork() is needed for exactly three Perl
operations:
=head1 ENVIRONMENT
-Here we list environment variables with are either OS/2-specific, or
-are more important under OS/2 than under other OSes.
+Here we list environment variables with are either OS/2- and DOS- and
+Win*-specific, or are more important under OS/2 than under other OSes.
=head2 C<PERLLIB_PREFIX>
-Specific for OS/2. Should have the form
+Specific for EMX port. Should have the form
path1;path2
Should be used if the perl library is moved from the default
location in preference to C<PERL(5)LIB>, since this would not leave wrong
-entries in <@INC>.
+entries in @INC. Say, if the compiled version of perl looks for @INC
+in F<f:/perllib/lib>, and you want to install the library in
+F<h:/opt/gnu>, do
+
+ set PERLLIB_PREFIX=f:/perllib/lib;h:/opt/gnu
=head2 C<PERL_BADLANG>
=head2 C<PERL_SH_DIR>
-Specific for OS/2. Gives the directory part of the location for
+Specific for EMX port. Gives the directory part of the location for
F<sh.exe>.
+=head2 C<USE_PERL_FLOCK>
+
+Specific for EMX port. Since L<flock(3)> is present in EMX, but is not
+functional, it is emulated by perl. To disable the emulations, set
+environment variable C<USE_PERL_FLOCK=0>.
+
=head2 C<TMP> or C<TEMP>
-Specific for OS/2. Used as storage place for temporary files, most
+Specific for EMX port. Used as storage place for temporary files, most
notably C<-e> scripts.
=head1 Evolution
=head2 Threading
-As of release 5.003_01 perl is linked to multithreaded C<CRT>
-DLL. Perl itself is not multithread-safe, as is not perl
+As of release 5.003_01 perl is linked to multithreaded CRT
+DLL. If perl itself is not compiled multithread-enabled, so will not be perl
malloc(). However, extensions may use multiple thread on their own
risk.
-Needed to compile C<Perl/Tk> for C<XFreeOS/2> out-of-the-box.
+Needed to compile C<Perl/Tk> for XFree86-OS/2 out-of-the-box.
=head2 Calls to external programs
whatever is the override, see L<"PERL_SH_DIR">.
Thus means that you need to get some copy of a F<sh.exe> as well (I
-use one from pdksh). The drive F: above is set up automatically during
+use one from pdksh). The drive F<F:> above is set up automatically during
the build to a correct value on the builder machine, but is
overridable at runtime,
one non-overridable shell per platform. The obvious choices for OS/2
are F<cmd.exe> and F<sh.exe>. Having perl build itself would be impossible
with F<cmd.exe> as a shell, thus I picked up C<sh.exe>. Thus assures almost
-100% compatibility with the scripts coming from *nix.
+100% compatibility with the scripts coming from *nix. As an added benefit
+this works as well under DOS if you use DOS-enabled port of pdksh
+(see L<"Prerequisites">).
-B<Disadvantages:> currently F<sh.exe> of C<pdksh> calls external programs
+B<Disadvantages:> currently F<sh.exe> of pdksh calls external programs
via fork()/exec(), and there is I<no> functioning exec() on
OS/2. exec() is emulated by EMX by asyncroneous call while the caller
waits for child completion (to pretend that the C<pid> did not change). This
I will include it into distribution. I have no need for such a module, so
cannot test it.
+For the details of the current situation with calling external programs,
+see L<Starting OS/2 (and DOS) programs under Perl>.
+
+=over
+
+=item
+
+External scripts may be called by name. Perl will try the same extensions
+as when processing B<-S> command-line switch.
+
+=back
+
=head2 Memory allocation
Perl uses its own malloc() under OS/2 - interpreters are usually malloc-bound
-for speed, but perl is not, since its malloc is lightning-fast.
-Unfortunately, it is also quite frivolous with memory usage as well.
-
-Since kitchen-top machines are usually low on memory, perl is compiled with
-all the possible memory-saving options. This probably makes perl's
-malloc() as greedy with memory as the neighbor's malloc(), but still
-much quickier. Note that this is true only for a "typical" usage,
-it is possible that the perl malloc will be worse for some very special usage.
+for speed, but perl is not, since its malloc is lightning-fast.
+Perl-memory-usage-tuned benchmarks show that Perl's malloc is 5 times quickier
+than EMX one. I do not have convincing data about memory footpring, but
+a (pretty random) benchmark showed that Perl one is 5% better.
Combination of perl's malloc() and rigid DLL name resolution creates
a special problem with library functions which expect their return value to
the prefix C<emx_> added. (Currently only DLL perl has this, it should
propagate to F<perl_.exe> shortly.)
+=head2 Threads
+
+One can build perl with thread support enabled by providing C<-D usethreads>
+option to F<Configure>. Currently OS/2 support of threads is very
+preliminary.
+
+Most notable problems:
+
+=over
+
+=item C<COND_WAIT>
+
+may have a race condition. Needs a reimplementation (in terms of chaining
+waiting threads, with linker list stored in per-thread structure?).
+
+=item F<os2.c>
+
+has a couple of static variables used in OS/2-specific functions. (Need to be
+moved to per-thread structure, or serialized?)
+
+=back
+
+Note that these problems should not discourage experimenting, since they
+have a low probability of affecting small programs.
+
=cut
OS/2 extensions
files - and maybe some other extensions at the time you read it.
Note that OS2 perl defines 2 pseudo-extension functions
-OS2::Copy::copy and DynaLoader::mod2fname.
+OS2::Copy::copy and DynaLoader::mod2fname (many more now, see
+L<Prebuilt methods>).
The -R switch of older perl is deprecated. If you need to call a REXX code
which needs access to variables, include the call into a REXX compartment
https://perl5.git.perl.org / perl5.git / blobdiff