in reply to Determining if file path is absolute

File::Spec uses string operations to verify that a string looks like an absolute path (usually it's enough to just check what it starts with), but doesn't verify that such a file exists. On VMS, there is one more step:

# If it's a logical name, expand it. $file = $ENV{$file} while $file =~ /^[\w\$\-]+\Z(?!\n)/s && $ENV{$file};
I don't know enough VMS to understand why it is needed, but this is what the authors meant by "consult the working environment".

Replies are listed 'Best First'.
Re^2: Determining if file path is absolute
by Laurent_R (Canon) on Nov 04, 2018 at 10:20 UTC
    I don't know enough VMS to understand why it is needed, but this is what the authors meant by "consult the working environment".
    Just to answer this question, although it might be slightly off-topic with respect to the original post.

    VMS is lavishly using logical names, which are more or less equivalent to environment variables on other operating systems, especially for directories. These logical names are automatically translated by the OS, so that you usually don't need explicit dereferencing using the %ENV hash.

    For example, the default login directory (equivalent of the $HOME environment variable under Unix or Linux) is SYS$LOGIN. On one of my VMS systems, my SYS$LOGIN default directory is defined as follows:

    show logical sys$login "SYS$LOGIN" = "DISK$WORK:[APPL.USER.ROL]" (LNM$JOB_89C65540)
    But the DISK$WORK disk is itself a logical name pointing toward a physical disk name:
    show logical disk$work "DISK$WORK" = "$2$DKC3:" (LNM$SYSTEM_TABLE)
    So, in the end, if you use the SYS$LOGIN path in a VMS (DCL) script or in a Perl program, it actually gets translated (in this case with a two-step process) into: $2$DKC3:[APPL.USER.ROL], which is effectively an absolute VMS path. Note that the first logical name (SYS$LOGIN) is defined at the process level (in the LNM$JOB_89C65540 job level logical table, i.e. when I log into the system) where as the second logical name (DISK$WORK) is defined at the system level (LNM$SYSTEM_TABLE, when the system is started). So the logical names form a kind of cascading levels of logical indirection. The example above has only two levels of indirection, but you can sometimes have three, four, or even more such levels of indirection.

    In VMS, you almost never directly use actual absolute paths (such as $2$DKC3:[APPL.USER.ROL]), but almost always logical names (such as SYS$LOGIN). So to determine whether a name finally corresponds to an absolute path, the File::Spec module has to unroll the cascade of logical name levels to find out whether, in the end, it corresponds to an actual alsolute path, in the form of a disk name (such as $2$DKC3:) followed by directory hierarchy tree (such as [APPL.USER.ROL] in the example above).

    The module only checks whether the logical name cascade finally unrolls to a string corresponding to a typical absolute path, it does not check whether the absolute path actually exists (just as it does not do that on a Unix system either).