perlos2 - Perl under OS/2, DOS, Win0.3*, Win0.95 and WinNT.
One can read this document in the following formats:
man perlos2
view perl perlos2
explorer perlos2.html
info perlos2to list some (not all may be available simultaneously), or it may be read as is: either as README.os2, or pod/perlos2.pod.
To read the .INF version of documentation (very recommended) outside of OS/2, one needs an IBM's reader (may be available on IBM ftp sites (?) (URL anyone?)) or shipped with PC DOS 7.0 and IBM's Visual Age C++ 3.5.
A copy of a Win* viewer is contained in the "Just add OS/2 Warp" package
ftp://ftp.software.ibm.com/ps/products/os2/tools/jaow/jaow.zipin ?:\JUST_ADD\view.exe. This gives one an access to EMX's .INF docs as well (text form is available in /emx/doc in EMX's distribution). There is also a different viewer named xview.
Note that if you have lynx.exe or netscape.exe installed, you can follow WWW links from this document in .INF format. If you have EMX docs installed correctly, you can follow library links (you need to have view emxbook working by setting EMXBOOK environment variable as it is described in EMX docs).
The target is to make OS/2 one of the best supported platform for using/building/developing Perl and Perl applications, as well as 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 too hard).
The current state is quite close to this target. Known limitations:
Some *nix programs use fork() a lot; with the mostly useful flavors of perl for OS/2 (there are several built simultaneously) this is supported; but some flavors do not support this (e.g., when Perl is called from inside REXX). Using fork() after useing dynamically loading extensions would not work with very old versions of EMX.
You need a separate perl executable perl__.exe (see "perl__.exe") if you want to use PM code in your application (as Perl/Tk or OpenGL Perl modules do) without having a text-mode window present.
While using the standard perl.exe from a text-mode window is possible too, I have seen cases when this causes degradation of the system stability. Using perl__.exe avoids such a degradation.
There is no simple way to access WPS objects. The only way I know is via OS2::REXX and SOM extensions (see OS2::REXX, SOM). However, we do not have access to convenience methods of Object-REXX. (Is it possible at all? I know of no Object-REXX API.) The SOM extension (currently in alpha-text) may eventually remove this shortcoming; however, due to the fact that DII is not supported by the SOM module, using SOM is not as convenient as one would like it.
Please keep this list up-to-date by informing me about other items.
Since OS/2 port of perl uses a remarkable EMX environment, it can run (and build extensions, and - possibly - be built 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, only one works, see "perl_.exe".
Note that not all features of Perl are available under these environments. This depends on the features the extender - most probably RSX - decided to implement.
Cf. "Prerequisites".
EMX runtime is required (may be substituted by RSX). Note that it is possible to make perl_.exe to run under DOS without any external support by binding emx.exe/rsx.exe to it, see emxbind. Note that under DOS for best results one should use RSX runtime, which has much more functions working (like fork, popen and so on). In fact RSX is required if there is no VCPI present. Note the RSX requires DPMI. Many implementations of DPMI are known to be very buggy, beware!
Only the latest runtime is supported, currently 0.9d fix 03. Perl may run under earlier versions of EMX, but this is not tested.
One can get different parts of EMX from, say
ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/emx+gcc/
http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/dev/emx/v0.9d/The runtime component should have the name emxrt.zip.
NOTE. When using emx.exe/rsx.exe, it is enough to have them on your path. One does not need to specify them explicitly (though this
emx perl_.exe -de 0will work as well.)
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 "Other OSes"). RSX would not work with VCPI only, as EMX would, it requires DMPI.
Having RSX and the latest sh.exe one gets a fully functional *nix-ish environment under DOS, say, fork, `` and pipe-open work. In fact, MakeMaker works (for static build), so one can have Perl development environment under DOS.
One can get RSX from, say
http://cd.textfiles.com/hobbesos29804/disk1/EMX09C/
ftp://crydee.sai.msu.ru/pub/comp/os/os2/leo/gnu/emx+gcc/contrib/Contact the author on rainer@mathematik.uni-bielefeld.de.
The latest sh.exe with DOS hooks is available in
http://www.ilyaz.org/software/os2/as sh_dos.zip or under similar names starting with sh, pdksh etc.
Perl does not care about file systems, but the perl library contains many files with long names, so to install it 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 EMX to truncate file names. This is not supported, read EMX docs to see how to do it.
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:/bin), or in configurable location (see "PERL_SH_DIR").
For best results use EMX pdksh. The standard binary (5.2.14 or later) runs under DOS (with "RSX") as well, see
http://www.ilyaz.org/software/os2/Start your Perl program foo.pl with arguments arg1 arg2 arg3 the same way as on any other platform, by
perl foo.pl arg1 arg2 arg3If you want to specify perl options -my_opts to the perl itself (as opposed to your program), use
perl -my_opts foo.pl arg1 arg2 arg3Alternately, if you use OS/2-ish shell, like CMD or 4os2, put the following at the start of your perl script:
extproc perl -S -my_optsrename your program to foo.cmd, and start it by typing
foo arg1 arg2 arg3Note that because of stupid OS/2 limitations the full path of the perl script is not available when you use extproc, thus you are forced to use -S perl switch, and your script should be on the PATH. As a plus side, if you know a full path to your script, you may still start it with
perl ../../blah/foo.cmd arg1 arg2 arg3(note that the argument -my_opts is taken care of by the extproc line in your script, see "extproc on the first line").
To understand what the above magic does, read perl docs about -S switch - see perlrun, and cmdref about extproc:
view perl perlrun
man perlrun
view cmdref extproc
help extprocor whatever method you prefer.
There are also endless possibilities to use executable extensions of 4os2, associations of WPS and so on... However, if you use *nixish shell (like sh.exe supplied in the binary distribution), you need to follow the syntax specified in "Command Switches" in perlrun.
Note that -S switch supports scripts with additional extensions .cmd, .btm, .bat, .pl as well.
This is what system() (see "system" in perlfunc), `` (see "I/O Operators" in perlop), and open pipe (see "open" in perlfunc) are for. (Avoid exec() (see "exec" in perlfunc) unless you know what you do).
Note however that to use some of these operators you need to have a sh-syntax shell installed (see "Pdksh", "Frequently asked questions"), and perl should be able to find it (see "PERL_SH_DIR").
The cases when the shell is used are:
One-argument system() (see "system" in perlfunc), exec() (see "exec" in perlfunc) with redirection or shell meta-characters;
Pipe-open (see "open" in perlfunc) with the command which contains redirection or shell meta-characters;
Backticks `` (see "I/O Operators" in perlop) with the command which contains redirection or shell meta-characters;
If the executable called by system()/exec()/pipe-open()/`` is a script with the "magic" #! line or extproc line which specifies shell;
If the executable called by system()/exec()/pipe-open()/`` is a script without "magic" line, and $ENV{EXECSHELL} is set to shell;
If the executable called by system()/exec()/pipe-open()/`` is not found (is not this remark obsolete?);
For globbing (see "glob" in perlfunc, "I/O Operators" in perlop) (obsolete? Perl uses builtin globbing nowadays...).
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 extproc or #! directly, without an intervention of shell. Perl uses the same algorithm to find the executable as pdksh: if the path on #! line does not work, and contains /, then the directory part of the executable is ignored, and the executable is searched in . and on PATH. To find arguments for these scripts Perl uses a different algorithm than 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 sh.exe, Perl uses the same algorithm as pdksh: if $ENV{EXECSHELL} is set, the script is given as the first argument to this command, if not set, then $ENV{COMSPEC} /c is used (or a hardwired guess if $ENV{COMSPEC} is not set).
When starting scripts directly, Perl uses exactly the same algorithm as for the search of script given by -S command-line option: it will look in the current directory, then on components of $ENV{PATH} using the following order of appended extensions: no extension, .cmd, .btm, .bat, .pl.
Note that Perl will start to look for scripts only if OS/2 cannot start the specified application, thus system 'blah' will not look for a script if there is an executable file blah.exe anywhere on PATH. In other words, PATH is essentially searched twice: once by the OS for an executable, then by Perl for scripts.
Note also that executable files on OS/2 can have an arbitrary extension, but .exe will be automatically appended if no dot is present in the name. The workaround is as simple as that: since blah. and blah denote the same file (at list on FAT and HPFS file systems), to start an executable residing in file n:/bin/blah (no extension) give an argument n:/bin/blah. (dot appended) to system().
Perl will start PM programs from VIO (=text-mode) Perl process in a separate PM session; the opposite is not true: when you start a non-PM program from a PM Perl process, Perl would not run it in a separate session. If a separate session is desired, either ensure that shell will be used, as in system 'cmd /c myprog', or start it using optional arguments to system() documented in OS2::Process module. This is considered to be a feature.
Perl binary distributions come with a testperl.cmd script which tries to detect common problems with misconfigured installations. There is a pretty large chance it will discover which step of the installation you managed to goof. ;-)
Did you run your programs with -w switch? See "Starting OS/2 (and DOS) programs under Perl".
Do you try to run internal shell commands, like `copy a b` (internal for cmd.exe), or `glob a*b` (internal for ksh)? You need to specify your shell explicitly, like `cmd /c copy a b`, since Perl cannot deduce which commands are internal to your shell.
-Zmt -Zcrtdll?Well, nowadays Perl DLL should be usable from a differently compiled program too... If you can run Perl code from REXX scripts (see OS2::REXX), then there are some other aspect of interaction which are overlooked by the current hackish code to support differently-compiled principal programs.
If everything else fails, 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.
Some time ago I had reports it does not work. Nowadays it is checked in the Perl test suite, so grep ./t subdirectory of the build tree (as well as *.t files in the ./lib subdirectory) to find how it should be done "correctly".
`` and pipe-open do not work under DOS.This may a variant of just "I cannot run external programs", or a deeper problem. Basically: you need RSX (see "Prerequisites") for these commands to work, and you may need a port of sh.exe which understands command arguments. One of such ports is listed in "Prerequisites" under RSX. Do not forget to set variable "PERL_SH_DIR" as well.
DPMI is required for RSX.
find.exe "pattern" fileThe whole idea of the "standard C API to start applications" is that the forms foo and "foo" of program arguments are completely interchangeable. find breaks this paradigm;
find "pattern" file
find pattern fileare not equivalent; find cannot be started directly using the above API. One needs a way to surround the doublequotes in some other quoting construction, necessarily having an extra non-Unixish shell in between.
Use one of
system 'cmd', '/c', 'find "pattern" file';
`cmd /c 'find "pattern" file'`This would start find.exe via cmd.exe via sh.exe via perl.exe, but this is a price to pay if you want to use non-conforming program.
The most convenient way of installing a binary distribution of perl is via perl installer install.exe. Just follow the instructions, and 99% of the installation blues would go away.
Note however, that you need to have unzip.exe on your path, and EMX environment running. The latter means that if you just installed EMX, and made all the needed changes to Config.sys, you may need to reboot in between. Check EMX runtime by running
emxrevBinary installer also creates a folder on your desktop with some useful objects. If you need to change some aspects of the work of the binary installer, feel free to edit the file Perl.pkg. This may be useful e.g., if you need to run the installer many times and do not want to make many interactive changes in the GUI.
Things not taken care of by automatic binary installation:
PERL_BADLANGmay be needed if you change your codepage after perl installation, and the new value is not supported by EMX. See "PERL_BADLANG".
PERL_BADFREEsee "PERL_BADFREE".
This file resides somewhere deep in the location you installed your perl library, find it out by
perl -MConfig -le "print $INC{'Config.pm'}"While most important values in this file are updated by the binary installer, some of them may need to be hand-edited. I know no such data, please keep me informed if you find one. Moreover, manual changes to the installed version may need to be accompanied by an edit of this file.
NOTE. Because of a typo the binary installer of 5.00305 would install a variable PERL_SHPATH into Config.sys. Please remove this variable and put "PERL_SH_DIR" instead.
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 zip files are not absolute, but relative to some directory.
Note that the extraction with the stored paths is still necessary (default with unzip, specify -d to pkunzip). However, you need to know where to extract the files. You need also to manually change entries in Config.sys to reflect where did you put the files. Note that if you have some primitive unzipper (like pkunzip), you may get a lot of warnings/errors during unzipping. Upgrade to (w)unzip.
Below is the sample of what to do to reproduce the configuration on my machine. In VIEW.EXE you can press Ctrl-Insert now, and cut-and-paste from the resulting file - created in the directory you started VIEW.EXE from.
For each component, we mention environment variables related to each installation directory. Either choose directories to match your values of the variables, or create/append-to variables to take into account the directories.
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 *.exe on PATH, and *.dll on LIBPATH);
unzip perl_aou.zip -d f:/emx.add/bin(have the directory on PATH);
unzip perl_utl.zip -d f:/emx.add/bin(have the directory on PATH);
unzip perl_mlb.zip -d f:/perllib/libIf this directory is exactly the same as the prefix which was compiled into perl.exe, you do not need to change anything. However, for perl to find the library if you use a different path, you need to set PERLLIB_PREFIX in Config.sys, see "PERLLIB_PREFIX".
unzip perl_ste.zip -d f:/perllib/lib/site_perl/5.24.0/Same remark as above applies. Additionally, if this directory is not one of directories on @INC (and @INC is influenced by PERLLIB_PREFIX), you need to put this directory and subdirectory ./os2 in PERLLIB or PERL5LIB variable. Do not use PERL5LIB unless you have it set already. See "ENVIRONMENT" in perl.
[Check whether this extraction directory is still applicable with the new directory structure layout!]
unzip perl_blb.zip -d f:/perllib/libSame remark as for perl_ste.zip.
unzip perl_man.zip -d f:/perllib/manThis directory should better be on MANPATH. You need to have a working man to access these files.
unzip perl_mam.zip -d f:/perllib/manThis directory should better be on MANPATH. You need to have a working man to access these files.
unzip perl_pod.zip -d f:/perllib/libThis is used by the perldoc program (see perldoc), and may be used to generate HTML documentation usable by WWW browsers, and documentation in zillions of other formats: info, LaTeX, Acrobat, FrameMaker and so on. [Use programs such as pod2latex etc.]