From: Shawn Hargreaves 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: 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 Precedence: bulk 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