Craig--
Thanks for spending time on this.
> >Could you try to do a 'use Env qw(@FOO);' for some
> >well-known VMS 'environment' array and see if you
> >get the expected behavior when you loop over the
> >entries? Your script should die() if you try to
> >write to the array, though.
>
>I don't think how well-known the array is is important,
Just so that the testing/examples are for sure relevant
to something that will be used in practice. Your '$'
convention uses below are just what I was looking for.
>although there may be conventions that get us in trouble,
>such as the use of dollar signs. For future reference, an
>"environment array" is under VMS called a logical name
>search list and is documented at:
>
><http://www.openvms.digital.com:8000/72final/6489/6489pro_030.html#createsearchlist>
Thanks for the pointer.
>As far as testing the cases likely to cause trouble, my
>Perl skills aren't up to giving an array the name DCL$PATH,
>for example, which would be one of the more common logical
>names associated with a search list; is '$' even allowed in
>variable names?
Well,
bash$ perl
@{'foo$bar'} = qw(a b c);
print @{'foo$bar'}, "\n";
abc
bash$
But, FYI:
bash$ perl
use strict;
@{'foo$bar'} = qw(a b c);
print @{'foo$bar'}, "\n";
Can't use string ("foo$bar") as an ARRAY ref while "strict refs" in use at - line
2.
bash$
>It works ok as part of a logical name
>
>$ perl -e "print $ENV{'SYS$LOGIN'};"
>DISK8:[BERRYC]
>
>but if Env.pm needs to directly map logical names to variable names that could cause
>trouble.
I wonder if users and p5p would find it acceptable thusly:
use Env qw(@DCL$PATH);
print join("\n", @DCL_PATH), "\n";
I don't think it would be difficult to arrange for $ to be permitted
in the name of a var on VMS, and have it mapped to an underscore in
the variable name. It is possible to have it map to an array named
with the '$', but using it would be a bit awkward, as in the examples
above. Are there any other special
>Ordinary array processing seems to work as expected, although it
>doesn't die, it just issues a warning and continues:
This was a tyop on my part. I meant warn() when I said die(). Good
think I don't work for the police, eh?
>Here's my test program:
>------vmsenv.t-----
>use Env qw(@FOO);
>
>foreach(@FOO) { print "$_\n"; }
>push @FOO, 'fum'; # should fail
>if ($@) { die $@; }
>print "I'm still here after the error.\n";
>-----end of vmsenv.t
>
>and here's what it gives me:
>
>$ perl vmsenv.t
>FEE
>FI
>FO
>Environment arrays are read-only on VMS. Sorry. at /perl_root/lib/Env.pm line 240.
>I'm still here after the error.
>
>and here is the OS telling me what's in the FOO logical name:
>
>$ show logical foo
> "FOO" = "FEE" (LNM$PROCESS_TABLE)
> = "FI"
> = "FO"
Good. So, it does seem to be working. I do really wish we could do
read/write, but Dan Sugalski tells me that would involve XS work,
and I'm not up to that, especially since I don't have VMS access.
I suppose I'll leave that as an exercise for someone with the
appropriate tools and motivation.
BTW, I haven't seen a Unix case that would motivate the enabling
of:
use Env qw(%FOO);
especially since there would potentially be the need for two
delimiters/separators.
But, section 13.6.1 of the reference you gave seems to show usage
that might apply. However, I'm not convinced that I'm not misunderstanding
the purpose there.
Regards,
--Gregor
+--------------------------------------------------------------+
| Gregor N. Purdy [EMAIL PROTECTED] |
| |
| Swiss army chainsaw operator. y2k: perl -pe 'tr/yY/kK/' |
+--------------------------------------------------------------+
