Run Perl Scripts Reliably on OS/2 and DOS

You will finish with a repeatable way to run an existing Perl script on OS/2 or DOS, choose the correct launcher for a shell script, and separate runtime problems from quoting and PATH problems. The installed reference is perlos2(1) from Perl 5.38.2, packaged here as perl-doc 5.38.2-3.2ubuntu0.6. The page describes a legacy port, so check the exact executable and extender on the target machine before planning a new deployment.

Allow about 20 minutes for a configured system, or longer if EMX and RSX are missing. You need an OS/2 or DOS Perl binary, the EMX runtime or its RSX substitute, a filesystem that preserves long names for a full installation, and an OS/2-style shell or sh.exe when your commands need shell syntax. The examples only run programs and inspect configuration. They do not alter Config.sys unless you deliberately make that change in step 2.

1. Confirm the runtime before debugging Perl

Start with the runtime check supplied by the binary distribution:

C:\> emxrev
0.9d fix 03

The manual identifies EMX 0.9d fix 03 as the supported runtime in this documentation. Earlier EMX releases may run Perl, but are not tested by the reference. RSX is needed on DPMI platforms such as DOS-inside-OS/2 and Windows, and it requires DPMI. The manual warns that buggy DPMI implementations can make the result unreliable.

Checkpoint: if emxrev is not found, fix the runtime or PATH first. When emx.exe or rsx.exe is on PATH, you normally do not need to name it in every command. The explicit form below is valid, but is mainly useful for checking which extender is being used:

C:\> emx perl_.exe -de 0

2. Check the installation layout

For a binary installation, keep the executable directory on PATH and the DLL directory on LIBPATH. The Perl library must also be installed with its long filenames intact. A truncated library tree is not a harmless cosmetic problem: modules and support files may become impossible to load.

The installer also uses Config.pm to record paths. Ask Perl where the installed copy is:

C:\> perl -MConfig -le "print $INC{'Config.pm'}"
F:\perllib\lib\Config.pm

If the library is somewhere other than the prefix compiled into perl.exe, the manual says to configure PERLLIB_PREFIX in Config.sys. Editing that file changes boot-time environment state. Back it up first, make one deliberate change, and reboot when your platform requires it; to undo the change, restore the previous line and reboot again. Do not add the obsolete installer variable PERL_SHPATH; this reference specifically says to use PERL_SH_DIR instead.

3. Run a script directly

Use the ordinary Perl invocation when you want the least surprising launcher. Replace the placeholders with real values:

C:\work> perl report.pl input.dat output.txt
report complete

Arguments after the script belong to the script. Options intended for Perl go before the script name:

C:\work> perl -w report.pl input.dat output.txt

Keep this distinction visible in batch files. A common distraction is putting a Perl option after the script and then wondering why the program received it as ordinary data.

Checkpoint: use a harmless script or your program's existing self-test, then check the return code immediately in the same shell. If the program is not found, inspect the current directory and PATH before changing Perl configuration.

4. Make a script launchable from an OS/2 shell

For CMD or 4OS2, put an extproc line at the start of the script, then rename it with a .cmd extension:

extproc perl -S -w

print "hello from Perl\n";

C:\work> ren report.pl report.cmd
C:\work> report input.dat output.txt
hello from Perl

The -S switch is required here because OS/2 does not provide the script's full path through extproc. The script therefore needs to be on PATH. If it is not on PATH, use an explicit Perl path instead:

C:\work> perl ..\tools\report.cmd input.dat output.txt

-S also searches script names with no extension, then .cmd, .btm, .bat and .pl. The search starts in the current directory and then checks PATH. Do not assume that a script will win over a real executable with the same name: the operating system looks for an executable first.

5. Choose the shell boundary for child commands

Perl uses system(), backticks and pipe-open for external programs. A sh-compatible shell is needed when the command contains pipes, redirection, quoting or other shell metacharacters. With the OS/2 port, that shell should be named sh.exe and be available in the compiled location or through PERL_SH_DIR.

Do not pass an internal command from the wrong shell and expect Perl to infer it. For example, copy belongs to cmd.exe, so call that shell explicitly:

system 'cmd', '/c', 'copy input.dat output.dat';

This also makes the boundary easier to audit. Treat data inserted into a shell command as security-sensitive: quote it for the shell you selected, and avoid constructing a command from untrusted text.

6. Fix DOS failures without guessing

If backticks or pipe-open fail under DOS, the reference points first to RSX, a suitable sh.exe, and PERL_SH_DIR. Verify those three prerequisites before rewriting Perl code. If you need the separate GUI-facing executable, use perl__.exe for PM code such as Perl/Tk; the standard text-mode perl.exe is not the right choice for that windowing case.

For a command with awkward Windows-style quoting, use cmd.exe as an explicit intermediate shell:

system 'cmd', '/c', 'find "pattern" file';

The extra shell is intentional. The manual calls out find.exe because its quoted and unquoted forms are not equivalent through the ordinary C argument interface. If an external program still fails, run the distribution's testperl.cmd; it is intended to detect common misconfiguration.