I ran into pretty much the same thing just over a year ago (though I didn't have
occasion to notice that it was dependent on the operating system version), and
reported it to this same list.
Below is a quote from a message from Craig Berry, October 1 2001, which contains the
most essential findings:
-- snip --
>$ SET SYMBOL /SCOPE=NOGLOBAL
>
>$ perl -e "$res = `show default`; print $res;"
>Fatal VMS error (status=1409924) at
>$1$DUA330:[HOSTVAX.TOEDEL.PERL.MY_PERL.PERL-5_6_1]VMS.C;1, line 2105 at -e
>line 1.
>%LIB-F-UNECLIERR, unexpected CLI error
This actually appears to be a bug in LIB$SET_SYMBOL, whose table of
"condition values returned" says:
LIB$_UNECLIERR Unexpected CLI error. The CLI returned an error status
which was not recognized. This error may be caused by use of a nonstandard
CLI. If this error occurs while using the DCL command language interpreter,
please report the problem to your Compaq support representative.
Unfortunately this makes it hard to do anything sensible in Perl, since
ordinarily an error like this means everything's bonkers and you *do* want
to bail out.
>The cause is pretty obvious: line 2105 of VMS.C is trying to set a
>global
>symbol, and SET SYMBOL /SCOPE=NOGLOBAL tells VMS not to allow that. So
>likely there's no easy fix: the implementation of backticks on VMS would
>have to change significantly in order to remove the limitation.
Yeah, it looks like for the forseeable future subprocesses created with
pipes and backticks will need to use symbols to keep track of their input
and output devices.
>Too bad, because SET SYMBOL /SCOPE=(NOGLOBAL,NOLOCAL) is an easy way to
>protect against unexpected behavior -- inadvertant or malicious -- arising
>from users having redefined things.
If you're only concerned about command redefinition, you can use SET
SYMBOL/VERB/SCOPE=(NOGLOBAL,NOLOCAL) and I don't think that will cause any
problems for Perl.
-- snip --
I don't know that anyone mentioned the names of the offending symbols, but the above
explains what they're for. They probably exist only during your Perl session -- maybe
only during the processing of the backtick command -- which would make it anywhere
from tricky to nearly impossible for the user to detect them, other than by this side
effect.
I was, indeed, "only concerned about command redefinition", so adding "/VERB" to my
SET SYMBOL command has proved to be an acceptable workaround for my code.
Hope this helps.
/ Tom Edelson
VMS Release Engineering
SAS Institute, Inc.
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:David.Hansen@;ubsw.com]
Sent: Monday, October 28, 2002 10:29 AM
To: [EMAIL PROTECTED]
Subject: RE: Compaq Perl 5.6.1 and back-tick (qx() ) commands
Hello,
We have just upgraded our OS from Alpha VMS 7.2.1 to 7.3, and suddenly Perl scripts
which worked in the past are now failing.
The failure occurs whenever the script tries to execute an external command using
back-ticks (actually, the "qx()" syntax). This appears to be related to a symbol or
symbols, but we don't know which might be involved. Here's an example COM file which
hilights the problem.:
SITE1::ENV1$ type test.com
$
$ set symbol/scope=noglobal
$ perl = "$perl_root:[000000]perl"
$ perl -e " print `sho time` "
$
SITE1::ENV1$ @test
Fatal VMS error (status=1409924) at ROOT$:[PERL5_006_01]VMS.C;2, line 2208 at -e line
1. %LIB-F-UNECLIERR, unexpected CLI error
Now, running the above, without the "set symbol/scope=noglobal", causes it to work
fine. It seems that some symbol dependencies cause this back-tick mechanism to fail
when they are not in scope.
Does anyone know what symbols might be involved here? We checked and the only symbol
with "perl" in the name was the location of the perl executable itself, i.e. symbol
"perl".
Regards,
David Hansen
UBS Warburg Switzerland
And now, sit back and enjoy a lengthy legal disclaimer...
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
