Re: utils/perldoc.Com vs utils/perldoc

2013-09-21 Thread John E. Malmberg

On 9/20/2013 8:05 PM, Craig A. Berry wrote:





On Sep 20, 2013, at 6:01 PM, John E. Malmberg

malmb...@encompasserve.org wrote:



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?


Because you may not use Perl to invoke it. You may invoke it with
DCL  which will then invoke Perl. You can invoke it by putting it in the
command tables, or by setting up a foreign command, or by placing it in
a directory listed in DCL$PATH. Any and all of which can make perldoc
run perl_root:[utils]perldoc.com as a command procedure (which then
re-runs itself using Perl). That's about as close to having a shebang
line as you're going to get on VMS.


I would agree with all of that, except that this is what you get when 
you try running it as a command procedure:


LION @perl_root:[utils]perldoc
You called the perldoc command with a name that I didn't recognize.
This might mean that someone is tricking you into running a
program you don't intend to use, but it also might mean that you
created your own link to perldoc. I think your program name is
[perldoc.Com;1].

I'll allow this if the filename only has [a-zA-Z0-9._-].

 at PERL_ROOT:[utils]perldoc.Com;1 line 11.
I think that your name for perldoc is potentially unsafe, so I'm
going to disallow it. I'd rather you be safe than sorry. If you
intended to use the name I'm disallowing, please tell the maintainers
about it. Write to:

pod-perl...@rt.cpan.org


 at PERL_ROOT:[utils]perldoc.Com;1 line 11.


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?


Seems to be working just fine and as designed.


Just printing an error message and exiting is how it was designed?

Regards,
-John



Re: utils/perldoc.Com vs utils/perldoc

2013-09-21 Thread Craig A. Berry

On Sep 21, 2013, at 11:02 AM, John E. Malmberg malmb...@encompasserve.org 
wrote:

 On 9/20/2013 8:05 PM, Craig A. Berry wrote:
 
 
 On Sep 20, 2013, at 6:01 PM, John E. Malmberg
 malmb...@encompasserve.org wrote:
 
 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?
 
 Because you may not use Perl to invoke it. You may invoke it with
 DCL  which will then invoke Perl. You can invoke it by putting it in the
 command tables, or by setting up a foreign command, or by placing it in
 a directory listed in DCL$PATH. Any and all of which can make perldoc
 run perl_root:[utils]perldoc.com as a command procedure (which then
 re-runs itself using Perl). That's about as close to having a shebang
 line as you're going to get on VMS.
 
 I would agree with all of that, except that this is what you get when you try 
 running it as a command procedure:
 
 LION @perl_root:[utils]perldoc
 You called the perldoc command with a name that I didn't recognize.

Running it explicitly with @ syntax is not one of the options I mentioned.

 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?
 
 Seems to be working just fine and as designed.
 
 Just printing an error message and exiting is how it was designed?


It was designed to be run as a command, not but running it with @.  When you 
don't use it the way it was designed to work, it in fact (unsurprisingly) 
doesn't work.  Most likely with enough effort it could be made to work that way 
as well, but it was never intended to, and I don't see the value of it.

Craig A. Berry
mailto:craigbe...@mac.com

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser



Re: utils/perldoc.Com vs utils/perldoc

2013-09-21 Thread John E. Malmberg

On 9/21/2013 12:48 PM, Craig A. Berry wrote:


On Sep 21, 2013, at 11:02 AM, John E. Malmberg malmb...@encompasserve.org 
wrote:


On 9/20/2013 8:05 PM, Craig A. Berry wrote:





On Sep 20, 2013, at 6:01 PM, John E. Malmberg

malmb...@encompasserve.org wrote:



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?


Because you may not use Perl to invoke it. You may invoke it with
DCL  which will then invoke Perl. You can invoke it by putting it in the
command tables, or by setting up a foreign command, or by placing it in
a directory listed in DCL$PATH. Any and all of which can make perldoc
run perl_root:[utils]perldoc.com as a command procedure (which then
re-runs itself using Perl). That's about as close to having a shebang
line as you're going to get on VMS.


I would agree with all of that, except that this is what you get
when  you try running it as a command procedure:

LION @perl_root:[utils]perldoc
You called the perldoc command with a name that I didn't recognize.


Running it explicitly with @ syntax is not one of the options I mentioned.


Using DCL$PATH gives the same result as using the @ syntax.

Using a foreign command to run the perldoc.com is the same as using 
either DCL$PATH or the @ syntax.


I have never seen command tables run a command script or know of a way 
to configure them to do so.


I can not see any way to run perldoc.com with out passing it as a script 
to be run from Perl and work.  And in that case, the shebang simulation 
is ignored.



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?


Seems to be working just fine and as designed.


Just printing an error message and exiting is how it was designed?


It was designed to be run as a command, not but running it with @.
When you don't use it the way it was designed to work, it in fact
(unsurprisingly) doesn't work.  Most likely with enough effort it
could be made to work that way as well, but it was never intended to,
and I don't see the value of it.


The wrapper that simulates the shebang only runs it in a way that 
produces an error message.  I can not find any way to run it that takes 
advantage of the wrapper and results in useful output.


All attempts to run perldoc.com as a command instead of as a perl script 
that I can find just result in it emitting an error message.


The perldoc.com is not working the way that you describe because it is 
testing to see what the name of the script is.  I do not know if that 
change happened after the shebang simulation was added.


Since it has been run as a perl script by the foreign command, it has 
not been obvious that that running it standalone is not working.


If the shebang simulation worked, then a simpler foreign command could 
be used.


Regards,
-John



Re: utils/perldoc.Com vs utils/perldoc

2013-09-21 Thread Craig A. Berry

On Sep 21, 2013, at 1:33 PM, John E. Malmberg malmb...@encompasserve.org 
wrote:
 
 The wrapper that simulates the shebang only runs it in a way that produces an 
 error message.  I can not find any way to run it that takes advantage of the 
 wrapper and results in useful output.
 
 All attempts to run perldoc.com as a command instead of as a perl script that 
 I can find just result in it emitting an error message.


OK.  I think I see where we are talking at cross purposes.  I was talking 
exclusively about how the shebang emulation works in the general case by having 
$Config{startperl} prepended to the .com file.  I assumed that perldoc.com 
would work just the same as any other comparable utility in this respect, but 
it doesn't.  Bad assumption on my part.  Sorry about that.

I think you might have been assuming the same thing in reverse, namely that if 
perldoc.com has a problem, there must be a more general problem with the 
shebang emulation.  But I don't think there is.

The following illustrations that the shebang emulation works just fine in the 
general case:

$ type testshebang.com
$ perl 'f$env(procedure)' ''p1' ''p2' ''p3' ''p4' ''p5' ''p6' 
''p7' ''p8'!
$ exit++ + ++$status!=0 and $exit=$status=undef; while($#ARGV != -1 and 
$ARGV[$#ARGV] eq ''){pop @ARGV;}
eval 'exec perl_root:[00]Perl.exe -S $0 ${1+$@}'
if 0;

require 5;
print hello\n;
$ define DCL$PATH SYS$DISK:[]
%DCL-I-SUPERSEDE, previous value of DCL$PATH has been superseded
$ testshebang
hello

But perldoc.com doesn't work that way, as you discovered, and it's because it's 
a pretty thin wrapper around Pod::Perldoc::run.  So there is a bug in 
Pod::Perldoc (specifically Pod::Perldoc::program_name) which makes invalid and 
non-portable assumptions about the name of the file it's running.  As far as I 
can see from a quick look, the only real problem is that it doesn't know what 
to do with the version number, i.e., perldoc.com;1 is unacceptable, whereas 
perldoc.com would be ok.

I have no time for (and not much interest in) pursuing this further, but most 
likely replacing the line in Perldoc.pm that looks like:

(?: \. (?: bat | exe | com ) )?# possible extension

with

(?: \. (?: bat | exe | com | com;\d+ ) )?# possible extension

would do the trick.  And version numbers on .exe files are also possible of 
course.  So folks interested in this bug might want to report/fix it at 
https://rt.cpan.org/Public/Dist/Display.html?Name=Pod-Perldoc.


Craig A. Berry
mailto:craigbe...@mac.com

... getting out of a sonnet is much more
 difficult than getting in.
 Brad Leithauser