NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/perl/7779

Text File | 1993-01-12 | 3.9 KB | 85 lines

Newsgroups: comp.lang.perl
Path: sparky!uunet!world!aml
From: [e-mail] (Andrew M Langmead)
Subject: Re: *sigh* Yes, the eternal question: How do I run it under 4dos aga
Message-ID: <[e-mail]>
Organization: The World @ Software Tool & Die
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 12 Jan 1993 20:02:49 GMT
Lines: 74

[e-mail] (Chaim Manaster) writes:

>In article <[e-mail]> [e-mail] (Andrew M Langmead) writes:
>>In the DOS version, if you have 4DOS to execute the file FOO.PL with the
>>perl interpreter, and add a parameter BAR (FOO BAR) the command that a
>>actually gets executed is PERL.EXE FOO.PL BAR
>>BAR is now available in the @ARGV array. Any options to perl itself can
>>be specified on the first line as #!/usr/bin/perl -n
>>or by explicitly starting the perl interpreter with the appropriate options
>>PERL -n FOO.PL BAR

>I thought that the point of invoking the 4dos convention was that
>the unix #! convention doesn't work in DOS.

MS-DOS only understands how to execute .COM and .EXE files.
COMMAND.COM and 4DOS understand how to execute .BAT files, and for
each line that starts a .COM or .EXE calls the MS-DOS exec() system
call. (Slightly different than in Unix, in which /bin/sh or other
interpreters may be started when a file is passed to exec().) With
4DOS's executable extention mechanism, 4DOS is trying to figure out
what to pass to the exec() call (which has to be either .COM or .EXE)

The #! convention doesn't execute a program in MS-DOS, because MS-DOS
does not execute based on an executable attribute, and does not
decide how to execute based on the contents of the file. Since Perl
runs on other systems that don't decide how to execute based on the
first few bytes of a file it parses that line itself. (On Unix
systems that don't support #!  (SysV based) if the file has the
executable bit set, but isn't machine code it is passed to /bin/sh.)
On the systems that automatically run /bin/sh on non-machine code
files some messing around can be done to get the perl interpreter
started in a way that is syntatically different, but very similar in
theory to the @rem=...  method of having COMMAND.COM pass a perl
script to PERL.EXE (See a perl/bourne script that starts

#!/usr/bin/perl
eval "exec /usr/bin/perl -S $0 $*"
     if $running_under_some_shell;

or look at the man page for an expaination of what it is doing.)

>Also, if the perl script is named "howdy" with parameters firstname
>and lastname then the command line would not refernce perl at all,
>but only howdy, as in: howdy(.pl) firstname lastname, and
>the only refernce to perl would be IN howdy but not on the command
>line. This seems to contadict your above statement. What am I
>misunderstanding?

The line SET .PL=c:\bin\perl.exe tells 4DOS every file that ends in
.PL can be a the first word on a command line, and when one appears
the file c:\bin\perl.exe should be run. The command line that is
given to 4DOS is "howdy firstname lastname" but what 4DOS passes to
exec() is "C:\BIN\PERL.EXE HOWDY.PL firstname lastname" because 4DOS,
not MS-DOS is doing the translation. Perl then starts up, taking the
filename HOWDY.PL has the file to execute, checks the first line for
any command line options (because it can tell that it wasn't started
by the "magic numbers" in the first few bytes of the file.)

>Thanks again for the help.

>Henry Manaster

>--
>***************************************************************************
>       Henry Manaster          *     EMail: [e-mail]
>       Brooklyn, NY            *
>                                *
>       Disclaimer: The above is not necessarily MY opinion nor that
>                               of anyone else :-)  ????!
>****************************************************************************
>

--
----