Craig A. Berry wrote:
> At 03:49 AM 3/15/00 -0500, Dan Sugalski wrote:
> >Without these patches. RC2 won't build properly, install, or build modules.
>
> I have a feeling that the configure.com patch for default file types will
> fix Peter's issue with Perl_cando and lib$fid_to_name, although it may
> simply be avoiding it rather than fixing what may still be a latent problem.
> I built RC2 with these patches applied and the miniperl command we were
> testing never hit cando_by_name() in vms.c. I believe (though I really
> don't understand the code in util.c very well) that we were hitting some
> sort of fallback position when Perl couldn't find a script. These lines from
> Perl_find_script in util.c seem to be where the configure change makes a
> difference in what happens:
>
> #ifdef VMS
> # ifdef ALWAYS_DEFTYPES
> len = strlen(scriptname);
> if (!(len == 1 && *scriptname == '-') && scriptname[len-1] != ':') {
> int hasdir, idx = 0, deftypes = 1;
> bool seen_dot = 1;
>
> hasdir = !dosearch || (strpbrk(scriptname,":[</") != Nullch) ;
> # else
> if (dosearch) {
> int hasdir, idx = 0, deftypes = 1;
> bool seen_dot = 1;
>
> hasdir = (strpbrk(scriptname,":[</") != Nullch) ;
> # endif
The failure to build perl is in the descrip.mms file where it tries to
invoke miniperl.exe to run the [.vms]writemain.pl script.
$ sea descrip.mms writemain/win
perlmain.c : miniperlmain.c $(MINIPERL_EXE) [.vms]writemain.pl
$(MINIPERL) [.VMS]Writemain.pl "$(EXT)"
so default extensions are not pertinent to the problem I saw.
> It may well be that there is still a problem in the way a conflict between a
> concealed logical name and a volume label is handled. Are there any valid
> conditions under which one could have a logical name that is identical to a
> volume label (but points to a different place) and expect the file system to
> ignore the logical and use the volume label?
>
> Peter, I think your last explanation inferred that lib$fid_to_name is taking
> the volume label "DISK$USER", lopping off and discarding the "DISK$" part,
> and then getting confused because the remaining "USER" is a logical name
> pointing elsewhere. This would be surprising behavior (at least to me), but
> if you observed it doing that in the debugger I'll take your word for it.
> There is another possible explanation though: Perl_find_script also does
> something with DCL$PATH (I don't completely understand what yet), so if
> USER: appears anywhere in your DCL$PATH, that could be involved somehow also.
This is almost but not quite accurate. The call to stat() upstream of
Perl_cando results in a device name of _SNFRN$DKB100:, whereas the call to
lib$fid_to_name() returns USER:[VMSPERL.VMS]WRITEMAIN.PL, this happens
to be a problem because I have a USER rooted logical. I did not say that
lib$fid_to_name() was turning DISK$USER: to USER:, I did say that it was
turning _SNFRN$DKB100: to USER: and that we ought not use it.
$ pipe sho dev d | sea sys$input dkb100
SNFRN$DKB100: Mounted 0 USER 10150290 1 1
$ directory disk$user:[vmsperl.vms]writemain.pl
Directory DISK$USER:[VMSPERL.VMS]
WRITEMAIN.PL;1
Total of 1 file.
$ directory user:[vmsperl.vms]writemain.pl
%DIRECT-E-OPENIN, error opening USER:[VMSPERL.VMS]WRITEMAIN.PL;* as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
$ sho log user
"USER" = "DKB100:[U.]" (LNM$SYSTEM_TABLE)
So strictly speaking lib$fid_to_name() is not wrong, it is behaving as
documented and it is documented to be capable of returning file specifications
that "may not be useful". We ought not be using it (at least with DECC 6.0).
Peter Prymmer
