man perlos2 view perl perlos2 explorer perlos2.html info perlos2
to 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.zip
in ?:\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).
Note that if you have lynx.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 current state is quite close to this target. Known limitations:
*nix programs use fork a lot, but currently
fork is not supported after useing dynamically loaded extensions.
OS2::REXX extension (see REXX), and we do not have access to convenience methods of Object-REXX. (Is it
possible at all? I know of no Object-REXX API.)
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.
fork, popen and so on). In fact RSX is required if there is no VCPI present. Note the
RSX requires DPMI.
Only the latest runtime is supported, currently 0.9c. Perl may run under earlier versions of EMX, but this is not tested.
One can get different parts of EMX from, say
ftp://ftp.cdrom.com/pub/os2/emx09c/ ftp://hobbes.nmsu.edu/os2/unix/emx09c/
The runtime component should have the name emxrt.zip.
NOTE. It is enough to have emx.exe/rsx.exe on your path. One does not need to specify them explicitly (though this
emx perl_.exe -de 0
will work as well.)
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
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 rainer@mathematik.uni-bielefeld.de.
The latest sh.exe with DOS hooks is available at
ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.zip
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.
For best results use EMX pdksh. The soon-to-be-available standard binary (5.2.12?) runs under DOS (with RSX) as well, meanwhile use the binary from
ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2/sh_dos.zip
arg1 arg2 arg3 the same way as on any other platform, by
perl foo.pl arg1 arg2 arg3
If you want to specify perl options -my_opts to the perl itself (as opposed to to your program), use
perl -my_opts foo.pl arg1 arg2 arg3
Alternately, 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_opts
rename your program to foo.cmd, and start it by typing
foo arg1 arg2 arg3
Note 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 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 the perlrun manpage, and cmdref about extproc:
view perl perlrun man perlrun view cmdref extproc help extproc
or 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 Switches.
system (see system), `` (see
I/O Operators), and open pipe (see open) are for. (Avoid exec (see exec) 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 only cases when the shell is not used is the multi-argument
system (see system)/exec() (see exec), and one-argument version thereof without redirection and shell
meta-characters.
-w switch? See
Starting OS.
`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.
`` and pipe-open do not work under DOS.
PERL_SH_DIR as well.
DPMI is required for RSX.
find.exe "pattern" file
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. In
fact 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
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
emxrev
A folder is created on your desktop which contains some useful objects.
Things not taken care of by automatic binary installation:
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.
PERL_SHPATH into Config.sys. Please remove this variable and put PERL_SH_DIR instead.
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 unzip.
Below is the sample of what to do to reproduce the configuration on my machine:
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/lib
If this directory is preserved, you do not need to change anything.
However, for perl to find it if it is changed, you need to
set PERLLIB_PREFIX in Config.sys, see PERLLIB_PREFIX.
unzip perl_ste.zip -d f:/perllib/lib/site_perl
If you do not change this directory, do nothing. Otherwise put this
directory and subdirectory ./os2 in PERLLIB or PERL5LIB
variable. Do not use PERL5LIB unless you have it set already. See
ENVIRONMENT.
unzip perl_blb.zip -d f:/perllib/lib
If this directory is preserved, you do not need to change anything.
However, for perl to find it if it is changed, you need to
set PERLLIB_PREFIX in Config.sys, see PERLLIB_PREFIX.
unzip perl_man.zip -d f:/perllib/man
This directory should better be on MANPATH. You need to have a working man to access these files.
unzip perl_mam.zip -d f:/perllib/man
This directory should better be on MANPATH. You need to have a working man to access these files.
unzip perl_pod.zip -d f:/perllib/lib
This is used by by 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.
unzip perl_inf.zip -d d:/os2/book
This directory should better be on BOOKSHELF.
unzip perl_sh.zip -d f:/bin
This is used by perl to run external commands which explicitly require shell, like the commands using redirection and shell metacharacters. It is also used instead of explicit /bin/sh.
Set PERL_SH_DIR (see PERL_SH_DIR) if you move sh.exe from the above location.
Note. It may be possible to use some other sh-compatible shell (not tested).
perl -MConfig -le "print $INC{'Config.pm'}"
You need to correct all the entries which look like file paths (they
currently start with f:/).
view perl view perl perlfunc view perl less view perl ExtUtils::MakeMaker
(currently the last two may hit a wrong location, but this may improve soon). Under Win* see SYNOPSIS.
If you want to build the docs yourself, and have OS/2 toolkit, run
pod2ipf > perl.ipf
in /perllib/lib/pod directory, then
ipfc /inf perl.ipf
(Expect a lot of errors during the both steps.) Now move it on your BOOKSHELF path.
perldoc perlfunc perldoc less perldoc ExtUtils::MakeMaker
to access the perl documentation in the text form (note that you may get better results using perl manpages).
Alternately, try running pod2text on .pod files.
man perlfunc man 3 less man ExtUtils.MakeMaker
to access documentation for different components of Perl. Start with
man perl
Note that dot (.) is used as a package separator for documentation for packages, and as
usual, sometimes you need to give the section - 3
above - to avoid shadowing by the less(1) manpage.
Make sure that the directory above the directory with manpages is on our MANPATH, like this
set MANPATH=c:/man;f:/perllib/man
cd f:/perllib/lib/pod pod2html
After this you can direct your browser the file perl.html in this directory, and go ahead with reading docs, like this:
explore file:///f:/perllib/lib/pod/perl.html
Alternatively you may be able to get these docs prebuilt from CPAN.
info files
CPerl mode loaded. You need to get latest pod2info from CPAN, or, alternately, prebuilt info pages.
Acrobat are available on CPAN (for slightly old version of perl).
LaTeX docs
pod2latex.
find --version sort --version
). You need the latest version of pdksh installed as sh.exe.
Possible locations to get this from are
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/emx09c/
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 memory may be found.
Also make sure that you have /tmp directory on the current drive, and . directory in your LIBPATH. One may try to correct the latter condition by
set BEGINLIBPATH .
if you use something like CMD.EXE or latest versions of 4os2.exe.
Make sure your gcc is good for -Zomf linking: run omflibs
script in /emx/lib directory.
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 Selective install, and choose Link
object modules in Optional system utilities/More. If you get into link386, press Ctrl-C.
http://www.perl.com/CPAN/src/5.0 http://www.perl.com/CPAN/src/5.0/unsupported
If not, you may need to dig in the indices to find it in the directory of the current maintainer.
Quick cycle of developers release may break the OS/2 build time to time, looking into
http://www.perl.com/CPAN/ports/os2/ilyaz/
may indicate the latest release which was publicly released by the maintainer. Note that the release may include some additional patches to apply to the current source of perl.
Extract it like this
tar vzxf perl5.00409.tar.gz
You may see a message about errors while extracting Configure. This is because there is a conflict with a similarly-named file configure.
Change to the directory of extraction.
gnupatch -p0 < os2\POSIX.mkfifo gnupatch -p0 < os2\diff.configure
You may also need to apply the patches supplied with the binary distribution of perl.
Note also that the db.lib and db.a from the EMX distribution are not suitable for multi-threaded compile (note that currently perl 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
sh Configure -des -D prefix=f:/perllib
prefix means: where to install the resulting perl library. Giving correct prefix
you may avoid the need to specify PERLLIB_PREFIX, see PERLLIB_PREFIX.
Ignore the message about missing ln, and about -c option to
tr. In fact if you can trace where the latter spurious warning comes from,
please inform me.
Now
make
At some moment the built may die, reporting a version mismatch or unable to run perl. This means that most of the build has been finished, and it is the time to move the constructed perl.dll to some absolute location in LIBPATH. After this is done the build should finish without a lot of fuss. One can avoid the interruption if one has the correct prebuilt version of perl.dll on LIBPATH, but probably this is not needed anymore, since miniperl.exe is linked statically now.
Warnings which are safe to ignore: mkfifo() redefined inside POSIX.c.
make test
Some tests (4..6) should fail. Some perl invocations should end in a
segfault (system error SYS3175). To get finer error reports,
cd t perl harness
The report you get may look like
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.
Note that using `make test' target two more tests may fail: op/exec:1
because of (mis)feature of pdksh, and lib/posix:15, which checks that the buffers are not flushed on _exit (this is a bug in the test which assumes that tty output is buffered).
I submitted a patch to EMX which makes it possible to fork
with EMX dynamic libraries loaded, which makes lib/io* tests pass. This means that soon the number of failing tests may decrease
yet more.
However, the test lib/io_udp.t is disabled, since it never terminates, I do not know why. Comments/fixes welcome.
The reasons for failed tests are:
IO::Pipe module. Some feature of EMX - test forks with dynamic
extension loaded - unsupported now.
IO::Socket module. Some feature of EMX - test forks with dynamic
extension loaded - unsupported now.
inode count - nonesuch under OS/2.
mtime and ctime of stat - I could not understand this test.
-x - determined by the file extension only under OS/2.
-t of /dev/null. Should not fail!
*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 should be present during testing.
make install
It would put the generated files into needed locations. Manually put perl.exe, perl__.exe and perl___.exe to a location on your PATH, perl.dll to a location on your LIBPATH.
Run
make cmdscripts INSTALLCMDDIR=d:/ir/on/path
to convert perl utilities to .cmd files and put them on PATH. You need to put .EXE-utilities on path manually. They are installed in $prefix/bin, here $prefix is what you gave to
Configure, see Making.
a.out-style build
make perl_
test and install by
make aout_test make aout_install
Manually put perl_.exe to a location on your PATH.
Since perl_ has the extensions prebuilt, it does not suffer from the dynamic extensions + fork() syndrome, thus the failing tests look like
Failed Test Status Wstat Total Fail Failed List of failed --------------------------------------------------------------- io/fs.t 26 11 42.31% 2-5, 7-11, 18, 25 op/stat.t 56 5 8.93% 3-4, 20, 35, 39 Failed 2/118 test scripts, 98.31% okay. 16/2445 subtests failed, 99.35% okay.
Note. The build process for perl_ does not know about all the dependencies, so you should make sure that anything is
up-to-date, say, by doing
make perl.dll
first.
/ became \ in pdksh.
'errno' - unresolved external
omflibs. See Prerequisites.
setpriority, getpriority
system
system allows an additional numeric argument. The meaning of this argument is
described in
Process.
extproc on the first line
"extproc ", this line is treated as #!-line, thus all the switches on this line are processed (twice if script
was started via cmd.exe).
system, to DLLs having functions with REXX signature and to REXX runtime, to OS/2
databases in the .INI format, and to Extended Attributes.
Two additional extensions by Andreas Kaiser, OS2::UPM, and
OS2::FTP, are included into my ftp directory, mirrored on CPAN.
File::Copy::copy, see Copy.
DynaLoader for DLL name mangling.
[/\\] (maybe after a drive-letter:).
Cwd::cwd.
name if CWD were dir. Dir defaults to the current dir.
type is present and true, works with END_LIBPATH, otherwise with
BEGIN_LIBPATH.
type is present and true, works with END_LIBPATH, otherwise with
BEGIN_LIBPATH.
WUNTRACED
Not implemented.
waitpid() is not implemented for negative values of PID.
kill -9 does not work with the current version of EMX.
In particular, uppercase letters do not work in [...]-patterns with the current pdksh.
my_popen uses sh.exe if shell is required, cf. PERL_SH_DIR.
TMP or TEMP environment variable, via
tempnam.
os2_stat special-cases /dev/tty and /dev/con.
a.out-style executable, but is linked with omf-style dynamic library 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 EMX it cannot fork
with dynamic extensions loaded (may be fixed by patches to EMX).
Note. Keep in mind that fork is needed to open a pipe to yourself.
a.out-style executable. It can fork, 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 perl.exe, like forking when having some standard extension loaded.
This executable is a VIO application.
Note. A better behaviour could be obtained from perl.exe if it were statically linked with standard Perl extensions, but dynamically linked with the Perl DLL and CRT DLL. Then it would be able to fork with standard
extensions, and would be able to dynamically load arbitrary extensions. Some changes to
Makefiles and hint files should be necessary to achieve this.
This is also the only executable with does not require OS/2. The friends locked into M$ world would appreciate the fact that this executable runs under DOS,
Win0.3*, Win0.95 and WinNT with an appropriate extender. See Other OSes.
Note. Usually STDIN, STDERR, and STDOUT of a PM application are redirected to nul. However, it is possible to see them if you start perl__.exe from a PM program which emulates a console window, like Shell mode of Emacs or EPM. Thus it is
possible to use Perl debugger (see the perldebug manpage) to debug your PM application.
This flavor is required if you load extensions which use PM, like the
forthcoming Perl/Tk.
omf-style executable which is dynamically linked to
perl.dll and CRT DLL. I know no advantages of this executable over perl.exe, but it cannot fork at all. Well, one advantage is that the
build process is not so convoluted as with perl.exe.
It is a VIO application.
#!-line (cf.
DESCRIPTION, Switches,
Not a perl script,
No Perl script found in input), it should know when a program is a Perl. There is some naming convention which allows Perl to distinguish correct
lines from wrong ones. The above names are almost the only names allowed by
this convention which do not contain digits (which have absolutely
different semantics).
The address tables of DLLs are patched only once, when they are loaded. The addresses of entry points into DLLs are guaranteed to be the same for all programs which use the same DLL, which reduces the amount of runtime patching - once DLL is loaded, its code is read-only.
While this allows some performance advantages, this makes life terrible for developers, since the above scheme makes it impossible for a DLL to be resolved to a symbol in the .EXE file, since this would need a DLL to have different relocations tables for the executables which use it.
However, a Perl extension is forced to use some symbols from the perl executable, say to know how to find the arguments provided on the perl internal evaluation stack. The solution is that the main code of interpreter should be contained in a DLL, and the .EXE file just loads this DLL into memory and supplies command-arguments.
This greatly increases the load time for the application (as well as the number of problems during compilation). Since interpreter is in a DLL, the CRT is basically forced to reside in a DLL as well (otherwise extensions would not be able to use CRT).
a.out format to export symbols for data. This forces omf-style compile of perl.dll.
Current EMX environment does not allow .EXE files compiled in
omf format to fork. fork is needed for exactly three
Perl operations:
a.out-style compile of
perl.exe.
PERLLIB_PREFIX
path1;path2
or
path1 path2
If the beginning of some prebuilt path matches path1, it is substituted with path2.
Should be used if the perl library is moved from the default location in
preference to PERLLIB, since this would not leave wrong entries in <@INC>.
setlocale failing. May be useful with some
strange locales.
free. May
be useful in conjunction with the module DB_File, since Berkeley DB memory
handling code is buggy.
PERL_SH_DIR
TMP or TEMP
-e scripts.
setpriority and getpriority are not compatible with earlier ports by Andreas Kaiser. See "setpriority, getpriority".
malloc. However,
extensions may use multiple thread on their own risk.
Needed to compile Perl/Tk for XFree86-OS/2 out-of-the-box.
Thus means that you need to get some copy of a sh.exe as well (I use one from pdksh). The drive F: above is set up automatically during the build to a correct value on the builder machine, but is overridable at runtime,
Reasons: a consensus on perl5-porters was that perl should use one non-overridable shell per platform. The
obvious choices for OS/2 are cmd.exe and sh.exe. Having perl build itself would be impossible with cmd.exe as a shell, thus I picked up sh.exe. Thus assures almost 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 Prerequisites).
Disadvantages: currently sh.exe of pdksh calls external programs via fork/exec, and there is 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 pid did not change). This means that 1 extra copy of sh.exe is made active via fork/exec, which may lead to some resources
taken from the system (even if we do not count extra work needed for
forking).
Note that this a lesser issue now when we do not spawn sh.exe unless needed (metachars found).
One can always start cmd.exe explicitly via
system 'cmd', '/c', 'mycmd', 'arg1', 'arg2', ...
If you need to use cmd.exe, and do not want to hand-edit thousands of your scripts, the long-term solution proposed on p5-p is to have a directive
use OS2::Cmd;
which will override system, exec, ``, and
open. With current perl you may override only system,
readpipe - the explicit version of ``, and maybe exec. The code will substitute the one-argument
call to system by
CORE::system.
If you have some working code for OS2::Cmd, please send it to me, I will include it into distribution. I have no need
for such a module, so cannot test it.
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.
Combination of perl's malloc and rigid DLL name resolution
creates a special problem with library functions which expect their return
value to be freed by system's free. To facilitate
extensions which need to call such functions, system memory-allocation
functions are still available with the prefix emx_ added. (Currently only DLL perl has this, it should propagate to perl_.exe shortly.)
perl.