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
