From:	Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Perl 5.004_02 -
Date:	Fri, 7 Nov 1997 19:43:41 +0000
Organization:	None
Distribution:	world
Message-ID:	<tzO4IAAt92Y0Ewu+@talula.demon.co.uk>
References:	<1 DOT 5 DOT 4 DOT 32 DOT 19971107125140 DOT 006ba23c AT dce03 DOT ipt DOT br>
NNTP-Posting-Host:	talula.demon.co.uk
MIME-Version:	1.0
Lines:	33
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Cesar Scarpini Rabak writes:
>Darryl Okahata (darrylo AT sr DOT hp DOT com) suggests that to have a Perl script 
>run as a executable under M$-DOG the following be added to the script 
>and rename its extension to .BAT
>
>       @echo off
>       perl -x -S %0.bat %1 %2 %3 %4 %5 %6 %7 %8 %9 

If you are using 4DOS, there is an even easier approach: you can
associate applications with a specific file extension to make them
executable. This is done by setting an environment variable, eg. 
"set .EXT=progname".

This would probably fix your nesting problem, but in general the djgpp
system() function has problems running commands that use this method.
When some random (non-unix script) file is invoked with this sort of
4DOS association, libc gets as far as the script_exec() routine in
dosexec.c, decides that it isn't a valid script, and calls go32_exec()
instead, which bypasses the command interpreter. Is there any reason why
this is required (does it ever reach this shell script test when trying
to run a native djgpp binary?) or could that call be replaced with
__dosexec_command_exec(), which would make 4DOS associations work
correctly?

Another possibility would be to test for an environment variable of the
form .EXT, for any unknown file extensions, and invoke the command
interpreter if that is found. But I don't understand the library code
well enough to go about adding that :-)


--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Pigs use it for a tambourine" - Frank Zappa

- Raw text -