Re: symlink support in VMS and Perl
Craig A. Berry wrote: At 9:41 AM +0930 10/22/07, Jeremy Begg wrote: Thanks for the reply. You mentioned having to define logical names such as DECC$POSIX_COMPLIANT_PATHNAMES to get certain behaviour from CRTL, but this runs the risk of breaking other applications. Did you know you can enable and disable this and similar behaviours from within a C program? Check out the decc$feature_xxx() routines, e.g. decc$feature_get() and decc$feature_set(). Another problem with using the decc$feature* routines or logical names is that they are global to the program, and affect all threads or ASTs that may be running. So setting a feature temporarily for one operation can break other asynchronous applications. Blead perl is now tracking several DECC features that change how the CRTL treats filenames and its environment and adjusts the behavior of perl to match. On the TODO list is to fix the core modules in Perl to also adjust their behavior to match the CRTL. This is a requirement for many of the ODS-5 extended filenames to work. Symbolic link and mount point processing is done by RMS, not the CRTL, and the DECC$POSIX_COMPLIANT_PATHNAMES is supposed to switch off most of the CRTL handling of UNIX to VMS translation and turn it over to RMS. In the past, the only testing that I am aware of for symbolic links was with the CRTL in the POSIX Compliant mode 3, and that was hampered because RMS could not handle the logical name translation in the POSIX pathnames. And it basically demonstrated that unless a program worked around that limitation in RMS, it could not use the POSIX compliant pathnames. So again, the DECC$POSIX_COM,PLIANT_PATHNAME settings, are not real useful until RMS gets another update. Using SYMLINKS and the CRTL in the default mode is something that will probably shake out a lot of bugs. Note that non CRTL programs, like DCL utilities support and act on symbolic links when the POSIX ROOT is set up correctly. So by that analysis, symbolic links should work with out the CRTL being in the POSIX_COMPLIANT_PATHNAMES mode. I'm aware of that capability and have used it before. I'm not sure that'd work for posix-compliant pathnames as you also have to have a root defined, which appears to be a system-wide setting (see HELP SET ROOT). The root is a system wide setting, and by default it is set on the system disk. The system wide root needs to be on an ODS-5 volume. You need mount points to access other volumes. In order to get GNV to work for me, I had to reorganize it to not mount / deep in the file system. I have fed that back to the GNV maintainer, along with updated DCL scripts, but have not received any response. The POSIX path name mode in RMS is designed to closely emulate UNIX path name processing. Mounting / at [vms$common.gnv] causes an infinite loop when doing a directory of [vms$commmon]. And for that reason should never be done. It causes the equivalent infinite loop on a UNIX system, and it also should not be done there, so in that respect RMS is behaving the same way as UNIX. -John [EMAIL PROTECTED] Personal Opinion Only
symlink support in VMS and Perl
At the moment I've enabled as the default (on systems that have the infrastructure) John Malmberg's symlink support in the Perl that will become 5.10. I'm having second thoughts about whether the underlying support in VMS is good enough or complete enough to make it the default, so I thought I would throw it out there for discussion. Not long ago, we found out that the unlink() function in the CRTL doesn't work on symlinks unless DECC$POSIX_COMPLIANT_PATHNAMES is defined, and defining that is likely to break lots of things. John worked around that by writing his own unlink() based on SYS$ERASE, and other projects have done the same, for example Python: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1157019 I've been trying to track down test failures in the File::Find tests in blead, and have discovered that chdir() also does not work on symlinks. The obvious solution is to call realpath() in our chdir() wrapper before calling the CRTL's chdir(), but this obvious solution doesn't work. It doesn't work because realpath() does not work unless posix-compliant pathnames are enabled. Unlike the unlink case, that's documented behavior in the v8.3 CRTL: http://h71000.www7.hp.com/doc/83final/5763/5763pro_021.html#crtl_symlinks I can probably get around this by doing a SYS$PARSE on the symlink name without setting the special flag (NAML$M_OPEN_SPECIAL), so SYS$PARSE will follow the symbolic link and give me a resulting directory spec I can pass to chdir(). Actually the resulting spec will probably need further conversion because in my experiments if the symbolic link points to /disk/dir/subdir, SYS$PARSE gives me disk:[dir]subdir as the resulting spec, and I need to make that disk:[dir.subdir] to work with chdir(). Or I could perhaps try something based on readlink(), but then I don't know if that will work outside of PCP mode either. So rolling our own chdir() should be doable, one way or another. But this made me stop and wonder how many other CRTL routines that operate on files need to be changed to handle symbolic links properly, but haven't been as of OpenVMS v8.3. Anyone know of cases besides unlink() and chdir() that don't work? Should we be bold and enable this support in Perl even though we don't know how much of it actually works? -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: symlink support in VMS and Perl
Craig A. Berry wrote: At the moment I've enabled as the default (on systems that have the infrastructure) John Malmberg's symlink support in the Perl that will become 5.10. I'm having second thoughts about whether the underlying support in VMS is good enough or complete enough to make it the default, so I thought I would throw it out there for discussion. Not long ago, we found out that the unlink() function in the CRTL doesn't work on symlinks unless DECC$POSIX_COMPLIANT_PATHNAMES is defined, and defining that is likely to break lots of things. John worked around that by writing his own unlink() based on SYS$ERASE, and other projects have done the same, for example Python: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1157019 I've been trying to track down test failures in the File::Find tests in blead, and have discovered that chdir() also does not work on symlinks. The obvious solution is to call realpath() in our chdir() wrapper before calling the CRTL's chdir(), but this obvious solution doesn't work. It doesn't work because realpath() does not work unless posix-compliant pathnames are enabled. Unlike the unlink case, that's documented behavior in the v8.3 CRTL: http://h71000.www7.hp.com/doc/83final/5763/5763pro_021.html#crtl_symlinks I thought that I had the File::Find tests working with symbolic links. The only thing that I had not gotten working was the ones that needed realpath(). Symbolic links do have some special requirements, they must be in UNIX syntax to be resolved, and they must be either a relative specification to the directory they are in, or there must be a valid path to them from the VMS root set with the SET ROOT. To go off volume a mount point needs to be set. I have not set an off volume mount point. Other paths may need an on-volume mount point to work. So rolling our own chdir() should be doable, one way or another. But this made me stop and wonder how many other CRTL routines that operate on files need to be changed to handle symbolic links properly, but haven't been as of OpenVMS v8.3. Anyone know of cases besides unlink() and chdir() that don't work? Should we be bold and enable this support in Perl even though we don't know how much of it actually works? I think until we get some more testing done, we should not consider the symbolic link stuff ready. I have only had a chance to glance at your patch to the cwd.t routines, but they are completely different than what I had to do to get Perl 5.8.7 to work with symbolic links in the Posix Compliant Mode. The major work in getting the symbolic link code working, based on my past work in this area is in getting the ODS-5 support working in both UNIX and VMS file specifications. Also, until HP gets the logical name support for POSIX pathnames into RMS, the Posix compliant pathnames are not very useful, as just about every existing library written in C is likely to break. A significant amount of the work that I did in my prior work in Perl was to work around RMS not handling logical names in the POSIX Compliant path names. -John [EMAIL PROTECTED] Personal Opinion Only
Re: symlink support in VMS and Perl
Jeremy Begg wrote: Hello Craig, Can I suggest the thing to do would be to work out which CRTL routines you would use, then ask HP OpenVMS Engineering to tell you how they behave with symlinks, subject to the presence or absence of assorted DECC$ logical names? (I assume here your problem is that symlink handling isn't well documented.) Almost all of the Symbolic links implementation is part of RMS, not the CRTL. The unlink() behavior is clearly a bug in the CRTL though. I have not been able to get the realpath() routine to work from the VMS debugger while in Perl, regardless of how I have set the DECC$ features. But this could be that I have not fully set up the directories under designated VMS root directory. You mentioned having to define logical names such as DECC$POSIX_COMPLIANT_PATHNAMES to get certain behaviour from CRTL, but this runs the risk of breaking other applications. Did you know you can enable and disable this and similar behaviours from within a C program? Check out the decc$feature_xxx() routines, e.g. decc$feature_get() and decc$feature_set(). The problem is that the DECC features globally affect all libraries written in C, the DECC$POSIX_COMPLIANT_PATHNAME modes turn almost all of the UNIX to VMS translation over to RMS, and not to the CRTL. The X11 libraries and the DECW debugger depend on logical names being translated as part of the UNIX to VMS translation. RMS at the last time I looked could not do logical name translation, so that means that any library routine that depends on /foo/bar being treated as foo:bar or foo:[00]bar will not work unless you create a directory, symbolic link, or mount point or named foo in the directory designated by the SET_ROOT command. It is totally unknown how many and what logical name translations that the existing run time libraries written in C require, so there is no way to predict which of these are needed. The directories under this new ROOT are also global and must be shared by all applications. Which is a problem if you have conflicting files of the same name, which logical names now allow. The last I saw, it was on the HP roadmap to add the logical name translation for the Posix names into RMS. Until that happens, though, I would not expect that the Posix modes to be used in production programs. HP does need feedback from real world programs and real customers about the Posix modes. I am no longer working on VMS except for my home hobby system. -John [EMAIL PROTECTED] Personal Opinion Only
Re: symlink support in VMS and Perl
At 9:41 AM +0930 10/22/07, Jeremy Begg wrote: Thanks for the reply. So rolling our own chdir() should be doable, one way or another. But this made me stop and wonder how many other CRTL routines that operate on files need to be changed to handle symbolic links properly, but haven't been as of OpenVMS v8.3. Anyone know of cases besides unlink() and chdir() that don't work? Should we be bold and enable this support in Perl even though we don't know how much of it actually works? Can I suggest the thing to do would be to work out which CRTL routines you would use, Avoiding that is one of my reasons for raising the issue :-). Someone should do a full audit of everything in the CRTL that uses path names, figure out when and where those path names can be symbolic links and should or should not be followed based on any standards governing the routines in question. I would really like that someone not to be me. I was just curious whether there were other cases that people had run into. then ask HP OpenVMS Engineering to tell you how they behave with symlinks, subject to the presence or absence of assorted DECC$ logical names? (I assume here your problem is that symlink handling isn't well documented.) It does sort of look as though the limitations aren't documented consistently, and those that are documented are documented as likely to be lifted in the future. You mentioned having to define logical names such as DECC$POSIX_COMPLIANT_PATHNAMES to get certain behaviour from CRTL, but this runs the risk of breaking other applications. Did you know you can enable and disable this and similar behaviours from within a C program? Check out the decc$feature_xxx() routines, e.g. decc$feature_get() and decc$feature_set(). I'm aware of that capability and have used it before. I'm not sure that'd work for posix-compliant pathnames as you also have to have a root defined, which appears to be a system-wide setting (see HELP SET ROOT). -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig A. Berry wrote: At 11:40 PM -0500 3/3/05, John E. Malmberg wrote: Building an on-the-fly program, usually called try.c, is the standard way to go. There are quite a few examples in configure.com. There is no reason to even run the test on VAX or on non-VAX prior to v7.3-1. I will see about writing such a program for hard links being enabled, right now, I can only easily test it on 8.2. What do you need for a patch to be submitted? GNU unified diffs of any files that have changed would be ideal. It's not clear to me to what extent the various changes you have in progress can be separated out, but I'm willing to help with the separating if you have something we can go ahead and get into bleadperl. I'm assuming configure.com, [.vms]vmsish.h, and [.vms]descrip_mms.template at a minimum are involved. Actually as I posted before, there are two modules utils/c2ph.pl, x2p/pl, involved that you provided a better change to, and a change to configure.com to enable hard links. No changes to vmsish.h or descrip_mms.template are needed. It may be better to change the .PM modules so that for the VMS platform they can detect if hard links are available on the target, or detect that the link() call fails, they then fall back to the copy, and have the hard link test also skip that tests when hard links are not available. That way perl can be built with hard link support even on disks that do not support hard links. The only real outstanding issue for me with hard links is that the perl umask function is not working as expected, and this is only effectively tested if hard links are enabled. It looks like that perl test [.t.io]fs.t is wrong. It should be testing to see if the first file protection mask matches the what was set by the umask() call, even when hard links are not enabled. Then it should be checking to see that the triply linked file has the same umask as the original if hard links exist I probably will not have time to find out why the perl umask code is not working as expected for a little while as that appears to be an existing bug. It also appears that umask issues are present on other platforms as there are special case codes in the test. I will see what I can do to get some patches for bleadperl. Actually there really should not be any reason not to enable large file support when it is available. I think it's slower, and also we try to track whatever defaults the unix builds use. I do not see why it would be slower, it is probably just alternate inputs to the same I/O routines with larger data types for the transfers. Are the UNIX builds not auto-enabling large file support when they detect that it is available? -John [EMAIL PROTECTED] Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
At 11:40 PM -0500 3/3/05, John E. Malmberg wrote: At this time, I can only test it on v8.2, and v8.2 is the earliest that DCL can easily check to see if hard links are available. The lexical function to check if hard links are enabled on the hard drive starts with v8.2. For prior versions, either the output of $SHOW DEVICE/FULL would need to be parsed, or a temporary program written to do the test. Building an on-the-fly program, usually called try.c, is the standard way to go. There are quite a few examples in configure.com. There is no reason to even run the test on VAX or on non-VAX prior to v7.3-1. What do you need for a patch to be submitted? GNU unified diffs of any files that have changed would be ideal. It's not clear to me to what extent the various changes you have in progress can be separated out, but I'm willing to help with the separating if you have something we can go ahead and get into bleadperl. I'm assuming configure.com, [.vms]vmsish.h, and [.vms]descrip_mms.template at a minimum are involved. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. Actually there really should not be any reason not to enable large file support when it is available. I think it's slower, and also we try to track whatever defaults the unix builds use. There is a lot of work to get the symlink stuff working, because it also requires getting Perl to honor the DECC$FILENAME_UNIX_ONLY and DECC$FILENAME_UNIX_REPORT logical names every where it returns a filename. Yup. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
On Mon, 28 Feb 2005, Craig Berry wrote: I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If you specify more than one macro definition in ccflags the /DEFINE macros need to be in parenthesis. This causes the test lib/ExtUtils/t/Embed.t to fail because it passes the parenthesis back with an \ character in front of them to the DCL command. It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. -John [EMAIL PROTECTED]
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
At 8:26 AM -0600 3/3/05, John E. Malmberg wrote: On Mon, 28 Feb 2005, Craig Berry wrote: I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If you specify more than one macro definition in ccflags the /DEFINE macros need to be in parenthesis. This causes the test lib/ExtUtils/t/Embed.t to fail because it passes the parenthesis back with an \ character in front of them to the DCL command. Hmm. We may need to modify the test to do for /DEFINE what it already does for /INCLUDE. It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. Excellent. I look forward to your patch. I suppose there's no reason to do the check unless we're on v7.3-1 or later. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig A. Berry wrote: At 8:26 AM -0600 3/3/05, John E. Malmberg wrote: It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. Excellent. I look forward to your patch. I suppose there's no reason to do the check unless we're on v7.3-1 or later. At this time, I can only test it on v8.2, and v8.2 is the earliest that DCL can easily check to see if hard links are available. The lexical function to check if hard links are enabled on the hard drive starts with v8.2. For prior versions, either the output of $SHOW DEVICE/FULL would need to be parsed, or a temporary program written to do the test. What do you need for a patch to be submitted? I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. Actually there really should not be any reason not to enable large file support when it is available. There is a lot of work to get the symlink stuff working, because it also requires getting Perl to honor the DECC$FILENAME_UNIX_ONLY and DECC$FILENAME_UNIX_REPORT logical names every where it returns a filename. -John [EMAIL PROTECTED] Personal Opinion Only
SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. -John [EMAIL PROTECTED] Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
On Monday, February 28, 2005, at 02:58PM, John E. Malmberg [EMAIL PROTECTED] wrote: The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly.
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig Berry wrote: On Monday, February 28, 2005, at 02:58PM, John E. Malmberg wrote: The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). Annother option is to use the /FIRST_INCLUDE option. And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If I understand your uselargefiles change, you used a variable substitution for ~LARGEFILES~ and passed it as a parameter to the script that built the outer descrip.mms. I did not see a ccflags change, but I will look for it tomorrow. Did you get a chance to look at the hard link support modifications that I posted about? I am not sure how to resolve the issue on the test that fails. I think it is wrong for a test script to assume that the default protection would be PROT=(O:RWD, G:RWD, W:RWD). -John [EMAIL PROTECTED] Personal Opinion Only
Re: symlink support
Craig A. Berry wrote: 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? 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. 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. 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. 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. 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
symlink support (was Re: Changing osname or ^O from VMS.C at startup?)
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
