pl2bat - wrap perl code into a batch file |
pl2bat - wrap perl code into a batch file
pl2bat -h
pl2bat [-w] [-a argstring] [-s stripsuffix] [files]
pl2bat [-w] [-n ntargs] [-o otherargs] [-s stripsuffix] [files]
This utility converts a perl script into a batch file that can be executed on DOS-like operating systems. This is intended to allow you to use a Perl script like regular programs and batch files where you just enter the name of the script [probably minus the extension] plus any command-line arguments and the script is found in your PATH and run.
There are several alternatives to this method of running a Perl script. They each have disadvantages that help you understand the motivation for using pl2bat.
C:> perl x:/path/to/script.pl [args]
C:> perl -S script.pl [args]
C:> perl -S script [args]
C:> ftype Perl=perl.exe "%1" %* C:> assoc .pl=Perl then C:> script.pl [args]
C:> ftype Perl=perl.exe "%1" %* C:> assoc .pl=Perl C:> set PathExt=%PathExt%;.PL then C:> script [args]
1 and 2 are the most basic invocation methods that should work on any system [DOS-like or not]. They require extra typing and require that the script user know that the script is written in Perl. This is a pain when you have lots of scripts, some written in Perl and some not. It can be quite difficult to keep track of which scripts need to be run through Perl and which do not. Even worse, scripts often get rewritten from simple batch files into more powerful Perl scripts in which case these methods would require all existing users of the scripts be updated.
3 works on modern Win32 versions of Perl. It allows the user to omit the ``.pl'' or ``.bat'' file extension, which is a minor improvement.
4 and 5 work on some Win32 operating systems with some command shells. One major disadvantage with both is that you can't use them in pipelines nor with file redirection. For example, none of the following will work properly if you used method 4 or 5:
C:> script.pl <infile C:> script.pl >outfile C:> echo y | script.pl C:> script.pl | more
This is due to a Win32 bug which Perl has no control over. This bug is the major motivation for pl2bat [which was originally written for DOS] being used on Win32 systems.
Note also that 5 works on a smaller range of combinations of Win32 systems and command shells while 4 requires that the user know that the script is a Perl script [because the ``.pl'' extension must be entered]. This makes it hard to standardize on either of these methods.
There are several potential traps you should be aware of when you use pl2bat.
The generated batch file is initially processed as a batch file each
time it is run. This means that, to use it from within another batch
file you should preceed it with call
or else the calling batch
file will not run any commands after the script:
call script [args]
Except under Windows NT, if you specify more than 9 arguments to the generated batch file then the 10th and subsequent arguments are silently ignored.
Except when using CMD.EXE under Windows NT, if perl.exe is not in your PATH, then trying to run the script will give you a generic ``Command not found''-type of error message that will probably make you think that the script itself is not in your PATH. When using CMD.EXE under Windows NT, the generic error message is followed by ``You do not have Perl in your PATH'', to make this clearer.
On most DOS-like operating systems, the only way to exit a batch file
is to ``fall off the end'' of the file. pl2bat implements this by
doing goto :endofperl
and adding __END__
and :endofperl
as
the last two lines of the generated batch file. This means:
:endofperl
,
:WinNT
, and :script_failed_so_exit_with_non_zero_val
should not
be used.
__END__
and the DATA
file handle.. #!perl . while( <DATA> ) { . last if /^__END__$/; . [...] . } . __END__ . lines of data . to be processed . __END__ . :endofperl
The dots in the first column are only there to prevent cmd.exe to interpret
the :endofperl
line in this documentation. Otherwise pl2bat.bat itself
wouldn't work. See the previous item. :-)
C:> echo exit(99); >fail.pl C:> pl2bat fail.pl C:> perl -e "print system('perl fail.pl')" 99 C:> perl -e "print system('fail.bat')" 0
So fail.bat always reports that it completed successfully. Actually, under Windows NT, we have:
C:> perl -e "print system('fail.bat')" 1
So, for Windows NT, fail.bat fails when the Perl script fails, but
the return code is always 1
, not the return code from the Perl script.
By default, the ``.pl'' suffix will be stripped before adding a ``.bat'' suffix
to the supplied file names. This can be controlled with the -s
option.
The default behavior is to have the batch file compare the OS
environment variable against "Windows_NT"
. If they match, it
uses the %*
construct to refer to all the command line arguments
that were given to it, so you'll need to make sure that works on your
variant of the command shell. It is known to work in the CMD.EXE shell
under Windows NT. 4DOS/NT users will want to put a ParameterChar = *
line in their initialization file, or execute setdos /p*
in
the shell startup file.
On Windows95 and other platforms a nine-argument limit is imposed
on command-line arguments given to the generated batch file, since
they may not support %*
in batch files.
These can be overridden using the -n
and -o
options or the
deprecated -a
option.
OS
environment
variable to determine which operating system it is being run from.
$
is always assumed). Defaults to /.plx?/
.
/^#!.*perl/
is found in the script, then such
a line is inserted just after the new preamble. The exact line
depends on $Config{startperl}
[see the Config manpage]. With the -w
option, " -w"
is added after the value of $Config{startperl}
.
If a line matching /^#!.*perl/
already exists in the script,
then it is not changed and the -w option is ignored.
C:\> pl2bat foo.pl bar.PM [..creates foo.bat, bar.PM.bat..] C:\> pl2bat -s "/\.pl|\.pm/" foo.pl bar.PM [..creates foo.bat, bar.bat..] C:\> pl2bat < somefile > another.bat C:\> pl2bat > another.bat print scalar reverse "rekcah lrep rehtona tsuj\n"; ^Z [..another.bat is now a certified japh application..] C:\> ren *.bat *.pl C:\> pl2bat -u *.pl [..updates the wrapping of some previously wrapped scripts..] C:\> pl2bat -u -s .bat *.bat [..same as previous example except more dangerous..]
$0
will contain the full name, including the ``.bat'' suffix
when the generated batch file runs. If you don't like this,
see runperl.bat for an alternative way to invoke perl scripts.
Default behavior is to invoke Perl with the -S flag, so Perl will search the PATH to find the script. This may have undesirable effects.
On really old versions of Win32 Perl, you can't run the script via
C:> script.bat [args]
and must use
C:> script [args]
A loop should be used to build up the argument list when not on Windows NT so more than 9 arguments can be processed.
See also Disadvantages.
perl, perlwin32, runperl.bat
pl2bat - wrap perl code into a batch file |