At 1:02 PM -0600 12/8/07, John E. Malmberg wrote: >Craig A. Berry wrote:
>>1.) The first nit is that vms_realname and vms_realpath do not honor >>the setting (or lack thereof) of DECC$EFS_CASE_PRESERVE. > >That makes sense. Great. This change is in as part of #32601: http://public.activestate.com/cgi-bin/perlbrowse/p/32601 >The getcwd() routine also needs this as it is currently returning exact case. Hmm. Isn't that just using the CRTL getcwd()? > >vms_realname has done the equivalent of passing NO_CONCEAL as > >the fifth argument to F$PARSE. >This is intentional, vms_realname/vms_realpath return the absolute path of >what in UNIX terms the primary link of the file from the point of the file >system, not the path given. > >That is what the UNIX realpath does, it resolves all symbolic links in the >path. So the VMS equivalent should remove all logical names from the path. >LIB$FID_TO_NAME is the closest equivalent to the UNIX realpath that VMS has. OK, that does make sense, though what it is currently giving me is DISK$ALPHASYS, which is still a logical name, though it's the one created by the mount command based on the volume label (DVI$_LOGVOLNAM ?) and arguably not changeable in a valid way during the life of the mount. >I am expecting that these routines will be used in the Pathtools module. > >The past implementation of the abs_path on VMS using RMSEXPAND has been >different in behavior than the UNIX equivalent, especially in the handling of >non-existant files or directories. > >There should be some tests added for the error cases on all platforms. I think >it that were done earlier, the inconsistencies in the VMS implementation as >compared to UNIX would have been noticed. More tests are always welcome. There is a lot of work in progress on PathTools and we'll need to contribute to that, but this will now have to be post 5.10.0, unfortunately. >> To be consistent with what >>the VMS::Filespec namespace is about, I think we should rename these >>functions as follows: >> >>vms_realpath --> unixrealpath >>vms_realname --> vmsrealpath > >I do not have a problem with that, I put the vms_ prefix on them only to >prevent issues with a realpath() being exposed by another module that was also >in scope. These changes are also in #32601. >>We could also export these by default (as we do with all the existing >>VMS::Filespec functions) since I think the chance of collision with >>these names is slight. >> >>vms_case_tolerant is a bit different since it doesn't return a >>filespec, but I think case_tolerant_process would be a better name >>that would make its purpose clearer. I also *don't* think it should >>be exported by default, i.e., it could be in @EXPORT_OK but should >>not be in @EXPORT. > >I am ok with a different name. As of #32601 it's case_tolerant_process and can be exported if requested but is not exported by default. >My original intention was for it to override the File::Spec->case_tolerant >routine. > >My intention is also for there to be a way for perl to specify if it wants to >change the process to be case_tolerant while it is running. Yes, it occurred to me that we would eventually want to set as well as get this property. For now it's read-only with no arguments, but it shouldn't break the interface to add an optional boolean argument somewhere down the road, the value of which means, when true, turn on case tolerance (disable case sensitivity) and when false, turn off case tolerance (enable case sensitivity). Changing this function will probably be the least of our problems if we try to get Perl working in a case sensitive environment. >I am also coming to the conclusion after the discussion on the perl5-porters >list, that the vms symlink() function should internally translate the target >to UNIX format unless: > 1. DECC$FILENAME_REPORT_UNIX is active. > 2. DECC$FILENAME_UNIX_ONLY is active. > 3. DECC$POSIX_COMPLIANT_PATHNAMES is non-zero. > >I think that this would make the behavior match what the typical perl program >that is using symlink expects. That sounds about right. I think what we have now for shipping with 5.10.0 will do the right thing if you talk to it nicely and have read chapter 12 of the CRTL manual and understand how symbolic links work on VMS. We can surely improve default behavior and corner cases for 5.10.1. The current plan is to release 5.10.0 on December 18, which is Perl's 20th birthday. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
