'user1' looks like a volume logical name not a physical device name.
configure.com ought to have f$parse()ed out the physical device name.
Peter Prymmer
"Craig A.
Berry" To: Michael G Schwern <[EMAIL PROTECTED]>
<craigberry@m cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
ac.com>
Subject: Re: Dusting out vms/test.com
11/06/2001
01:31 PM
At 01:11 PM 11/6/2001 -0500, Michael G Schwern wrote:
>On Mon, Nov 05, 2001 at 11:42:07PM -0600, Craig A. Berry wrote:
>> Do this (and you might want to put these lines in the file login.com):
>>
>> $ @[schwern.perl]perl_setup
>> $ define/translation=concealed perl_root dkb300:[schwern.perl.]
Oops. You changed directories on me. See below.
>so I tried this:
>
>$ @perl_setup
>%DCL-I-SUPERSEDE, previous value of PERL_ROOT has been superseded
>%DCL-I-SUPERSEDE, previous value of PERLSHR has been superseded
>$ define/translation=concealed perl_root
user1:[schwern.src.perl-current.t.perl.]
This should work if you you replace
user1:[schwern.src.perl-current.t.perl.]
with
user1:[schwern.src.perl-current.]
PERL_ROOT points to the root *directory*, not to the copy of the perl
executable in the test directory. The reason for running PERL_SETUP.COM is
that it sets up everything relative to PERL_ROOT, including perldoc, etc.
It also sets up PERL_ROOT but makes it point to where it expects you to
install Perl, not to the build directory, thus the need to redefine
PERL_ROOT
to point to the build directory. On VMS it is extremely easy to run
multiple versions of Perl; you just redefine PERL_ROOT to point to the one
you're interested in and off you go.
