Re: utils/perldoc.Com vs utils/perldoc

"John E. Malmberg" <[email protected]> Fri, 20 Sep 2013 18:01:43 -0500
Newsgroups gmane.comp.lang.perl.ports.vms
Message-ID <[email protected]>
The perldoc command looks weird on VMS, and I do not know the origin of 
that convention.

VMS does not support shebangs.

Passing parameters on the command line to a program require that either 
the DCL shell command tables be modified to know about that command, or 
a foreign command to be created, or a DCL script be used.

Now with perldoc.com and friends, a hack was done so that the resulting 
files are both a legal DCL command script and a legal Perl script.

That is very useful  It means that all we should have to do is set a 
foreign command to the perldoc.com and all should be well.

But for some strange reason it is not, in this case, and I do not know why.

When you run a script on VMS, you prefix it with a "@" sign, and if you 
do not specify the ".xxx" extension, VMS adds a ".com" to the file.

But you do not need an an extension.

So to run perldoc.com on VMS you just do:
    @perl_root:[utils]perldoc.com "-t"

If you do not quote the "-t" it gets uppercased by the DCL shell.

But if you do the above, it fails because it sees it's argv[0] was 
"perldoc.com" and not "perldoc." and refuses to work.  Now that could 
not be too hard to fix.

It should also work to create a new file name perldoc.  The period is 
significant here in a new directory and then include the perldoc.com 
contents, and then copy the resulting file into the utils directory.

[Oddity in VMS, you can not rename or copy perldoc.com to perldoc., VMS 
assumes that you want to keep the .com extension and will preserve it :-(]

Then you could run it with the command below and it should just work. 
Note that the period is significant.

   @perl_root:[utils]perldoc. "-t"

And then the foreign command would just be:
   perldoc :== "@perlroot:[utils]perldoc. "-t".

So in theory there should not be a need to have the existing more 
complex foreign commands that are being set up.

After all, if you are going to always use Perl to invoke it, why add the 
hack to make it work as a command file?

And even more curious, why add a hack to make look like it should work 
as a command file with out actually making it work?

Regards,
-John