At 6:21 PM -0500 2/18/05, John E. Malmberg wrote:
I am still working on getting the symlink support going but there
>>are significant implications to using symbolic links on OpenVMS >>once the ECO kit is available.
Perl is affected by this, so here is a preview:
Symbolic links introduce and for some operations require the use
>>of a new UNIX style filename convention that is being called POSIX >>format.
>>by the CRTL so there is a way to use them with almost all existing
The processing of these specifications is now done by RMS and not
OpenVMS programs.
Because of the differences in processing a symbolic link references,
>>any program that does it's own translation of file specifications >>from UNIX format to OpenVMS native format will not return the right
answer for symbolic links.I find this curious, since I'm not aware of any difference in the
syntax of a filename that indicates whether or not it's a symbolic
link on unix systems. What is there about the file specification of
a symbolic link that cannot be expressed in VMS syntax?
It is expressible in VMS syntax, it is just that currently the CRTL routines that operate on symbolic links require POSIX syntax, not VMS syntax. I do not know if that limitation will be removed in the future.
RMS will deal with symbolic links transparently, using RMS routines to non-transparently operate on symbolic links requires special coding.
The most obvious case shows up with the file [.testlink] that is a symbolic link to _a_/_deeper_/_directory_/_level_
From the CRTL with POSIX file translations enabled, doing a dir of testlink/../ will give you the files in _a_/_deeper_/_directory_/
Translating that to a VMS format requires that the translation routine knows when it has encountered a symbolic link. Much easier just to let the CRTL deal with it.
And DCL will not know how to deal with [.TESTLINK.-] in the same way that the GNV bash or the CRTL will do.
>> and while I can easily test for this in the C code, but it looks like IThe CRTL will have a new feature setting to indicate when the user has selected that UNIX style pathnames should be parsed in POSIX style,
would need a way to let the .PM scripts know that this feature has been activated by the user in order to for the special cased OpenVMS code to work with symbolic links.
Possibly.
>> the filename.The perl absolute path routine is one of the ones that is affected by this as it is special cased for OpenVMS to do a manual parse of
It calls VMS::Filespec::rmsexpand, which invokes mp_do_rmsexpand() in
[.vms]vms.c. We could check for the feature involved here and omit
the call to do_tovmsspec() in mp_do_rmsexpand() on the assumption
that, as you seem to be implying above, sys$parse can handle unix
syntax filenames when the symlink feature is available. There may be
side effects and this would have to be studied carefully.
sys$parse with the RMS SYMLINK kit will handle POSIX style names as long as they are prefixed with ^UP^ to identify them. So it is not automagically transparent.
To have it return the real path name requires a qualifier to tell it not to work. And from a quick glance, this qualifier is only in the expanded NAML block. So it looks like if this were to be done at rmsexpand, there would need to be two versions of it, one where it was not supposed to reveal the contents of the symbolic link, and one where it does. And so far, it appears that it only one place requires the symbolic link be revealed.
If Perl is to support DECC$FILENAME_UNIX_ONLY and/orIt looks like the way to do that is to have the affected scripts look up the setting of the DECC feature logicals while they run.
DECC$FILENAME_UNIX_REPORT, then yes, there will have to be some
changes to various things and these will not be particularly easy
changes. Historically, way back when the CRTL kinda sorta supported
unix syntax filenames but often failed to handle them properly, the
safest thing to do was just always convert to VMS syntax before
calling the CRTL, and of course calls to system services and other
RTLs have always had to do this as well. The Perl implementation is
a very mixed bag of calls to the CRTL and to native APIs, so it might
well be rather difficult to disentangle when we need unix syntax and
when we need VMS syntax under conditions where we can no longer
assume it's always safe to convert to VMS syntax.
I agree, and this is something that will probably take a while to phase in.
And the existing method of perl's operation should be the maintained and be the default.
These feature logicals would only be set when someone specifically wanted to modify perl's behavior on VMS to pretend that it is UNIX.
I have run into one problem with that so far though. In order for opendir()/readdir() to function correctly, I had to set the code to use the CRTL versions when the POSIX feature is on.
This meant that I had to make the CRTL dirent and DIR structure used for OpenVMS 8.2 the one that is visible outside of VMS.C, and then if the Posix feature logical is not set, use the existing structure internally. The side effect of this is that the structure member d_namlen is not present. As near as I can tell only one C module is affected by this PP_SYS.C, and if config.h shows that member is not present, instead of calculating the value manually, it just passes 0 for it. So I am not sure that there is even any real impact to the non-posix mode. The rest of the code that references d_namlen will use strlen() to get the value.
-John [EMAIL PROTECTED] Personal Opinion Only
