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. > >The processing of these specifications is now done by RMS and not by the CRTL >so there is a way to use them with almost all existing 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? >The CRTL will have a new feature setting to indicate when the user has >selected that UNIX style pathnames should be parsed in POSIX style, and while >I can easily test for this in the C code, but it looks like I 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 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 the filename. 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. >It 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. If Perl is to support DECC$FILENAME_UNIX_ONLY and/or 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. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
