Re: utils/perldoc.Com vs utils/perldoc
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
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
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
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
