Sebb wrote:
On 03/10/05, John E. Malmberg <[EMAIL PROTECTED]> wrote:
New files opened for write are created in the first directory of a
search list. New files opened for append are created in the last
directory of a search list.
Are you sure appended files use the last directory?
This doesn't happen with Perl 5.5-3A3.
I am going by the behavior of the file system. Perl on VMS has many
cases where it does it's own thing instead of what OpenVMS or the CRTL does.
In particular, implementations inside of Perl of converting to/from VMS
and UNIX pathnames can cause unexpected behavior when there is a search
list.
In some cases, Perl only looks up the first member of the search list
when doing a translation. The precise method used in translating a path
name to or from UNIX/VMS may depend on if the pathname is apparently
absolute or relative, so what should be equivalent VMS paths in UNIX
syntax may not be translated the same.
Perl on VMS currently uses several different methods to convert
pathnames, and I have found errors in all of them. Some errors I have
not found a fix to, in other cases, I have found core modules depending
on the bug to be present. Many of the errors only show up in corner
cases, and only showed up in the tests of the core modules when I
started adding support for ODS-5.
At present time, things mostly work for ODS-2, and for a very restricted
set of ODS-5.
My recommendation for Perl programming to avoid using the
unixify()/vmsify() and related methods unless it is known for sure that
the resulting file specification must be in the syntax for a specific
operating system. Most Perl APIs on VMS will take either UNIX or VMS
syntax just fine.
The conversion of a pathname from UNIX to VMS syntax may not be
reversible, even though currently Pathtools assumes that it is.
So that means that how ever tempting it may be to make a task easier, a
pathname should never be converted from VMS->UNIX->VMS syntax to do it,
or the reverse of UNIX->VMS->UNIX.
That is slightly unreliable on ODS-2, more problematic on ODS-5, and
symbolic link support makes things even more different, because then
".." and [-] can have significantly different meanings.
I plan to be updating the documentation. In most cases it is not that I
am changing a current behavior, but to document the existing behavior
and some unexpected side effects of it.
For example, some undocumented features of unixify().
1. unixify() preserves trailing line terminators on input file
specifications. This is a side effect on how glob support is implemented.
2. unixify() preserves the input file specification to the output if it
finds that it is not a legal VMS file specification. MakeMaker depends
on this behavior.
Both of these significantly impact adding ODS-5 support to Perl, but
were probably not noticed by most Perl programs. I also recommended
that other Perl programs not depend on these undocumented behaviors.
-John
[EMAIL PROTECTED]
Personal Opinion Only
