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
