Sebb wrote:
If you try the same experiment from DCL you will get a different result.
How are you doing it using DCL?
I am pretty sure that I used to do it with $open/append. It appears
since I put a reproducer on comp.os.vms several years ago that the
behavior has been changed. Now I get an error message instead about not
finding the file, and the HELP documentation states that the destination
file must exist.
I can't reproduce the behaviour you are reporting.
And from DCL, I can not either at the moment. I remember that it used
to be pretty easy to demonstrate it.
And it is quite possible that if you use the RMS extensions to the
UNIXIO, Standard IO open/creat calls to convert an open for write to do
a "create if non-existent", it may behave differently than fopen().
This behaves the same as fopen():
#include stdio
#include fcntl
#include unistd
main(){
int fd = open("chain:c.tmp",O_APPEND|O_CREAT);
if (fd==-1) perror("open");
close(fd);
}
Omitting the O_CREAT causes a failure if the file does not exist (as expected).
That is still using the CRTL, and not the RMS extension to create if
non-existent.
Personally I think that having append go to the end of the search list
to create a new file is an undesired and unexpected feature, but that is
the way it works.
I agree it's undesired and unexpected.
I just don't see that it is working that way ...
Perhaps someone agreed with my now ancient post in comp.os.vms that it
was a bit of a surprise. A number of rarely seen mis-features seem have
disappeared after they became somewhat public.
That is why I can no longer rename directories to be named "-.dir" back
when the "-" became a legal character for files. The contents of those
directories became a little hard to reach. That is another trick that
you can do if you go far enough back on VAX/VMS.
I do not have time now to do further experimentation. It may be that
the behavior that I saw before got deemed a bug by someone and fixed.
After all, if it caused a system specific file to be put in sys$common:
at run time just because append was used to create it instead of open,
that probably would not be good.
Like Perl, the CRTL is in many ways trying to be more compatible with
UNIX behavior than it is with expected VMS behavior. Unfortunately
But Unix does not have chained logicals, so there's no behaviour to be
compatible with.
On UNIX the shell does the expansion of environment variables that
contain paths and also wild card expansion. That could be the type of
behavior that the CRTL would be trying to emulate.
The current CRTL manual documents some expansions that were previously
undocumented that were done to ODS-2 filenames automatically because
they can not be made to work reliable with EFS filenames.
-John
[EMAIL PROTECTED]
Personal Opinion Only
