On Fri, 13 Jul 2001 [EMAIL PROTECTED] wrote:
> >Hmm. I also noted the following information while running:
> >Logical name T found in environment as
>DYM$SOURCE:[DYMAX.PERL5006_ACTIVE.PERL-5_6_1.HARNESS]
> > deassign before building perl5
> >A:..ACTIVE.PERL-5_6_1>
>
> I expect you may have already looked at this;
> no offense intended, but is there even a small chance
> the (process/job) environment differs between the systems
> you mentioned?
>
> I bring this up because I was bitten a few time
> by conflicts w/ cli symbols, process/job/group logicals.
>
> Notably, "TMP", "LIB", "T", and probably others.
> often enough on the core install and tests, but
> more often when building extensions.
I think that these may turn up odd `mmk test` results (failures)
particularly if you have odd $trnlnm() values. The reasons have to do
with file name and/or path conventions and do not necessarily indicate
bugs in perl. By and large perl on VMS ought to care about PERL_ROOT,
PERLSHR, SYS$TIMEZONE_DIFFERENTIAL, and how you use logical names to deal
with your file system (it will also pay attention to the well known
optional logical names like PERL5LIB etc.) Simply having any of these
others like qw(TMP LIB T) defined should not constitute brokenness for
running perl, but `mmk test` may report extra test failures (hence
configure.com warns about them).
> such that I now use a 'special' account, which is
> a member of an otherwise unused UIC group, logged
> via <username/NOCOMMAND, w/ $delete/sym/glob *,
> $delete/sym/local * to a achieve an account environment
> w/ a bare minimum of existing symbols, logicals, etc.
>
> sometimes, I'll use the same account to
> when troubleshooting errant perl scripts, to rule out
> some dependency/conflict w/ symbols/logicals
This sounds quite draconian - but it has been requested before that we
have more of a SYS$UPDATE:VMSINSTAL.COM type of installation (that does a
DELETE/SYMBOL/GLOB et alia). Have you managed to uncover any unreported
bugs in vmsperl this way? Would you want more of a $ DELETE/SYMBOL/GLOBAL
* type of installation, at least as an option?
It should still be the case that with default privs (ie TMPMBX, NETMBX)
and write access to the appropriate spots in the file system that you
could build, install, and run perl. Debugging tricky logical name
is hopefully a separate issue.
Peter Prymmer
