On Mar 7, 2014, at 6:49 PM, John E. Malmberg <malmb...@encompasserve.org> wrote:
> On 3/7/2014 8:18 AM, Craig A. Berry wrote: >> >> On Feb 26, 2014, at 11:35 PM, John E. Malmberg >> <malmb...@encompasserve.org> wrote: >> >>> On 2/25/2014 7:02 PM, Craig A. Berry wrote: >>>> >>>> On Feb 24, 2014, at 11:33 PM, John E. Malmberg >>>> <malmb...@encompasserve.org> wrote: >>> >>>>> I can not seem to do a rmdir() of an absolute or relative Unix >>>>> path with Perl 5.18.1. >>>> >>>> It works unless DECC$FILENAME_UNIX_REPORT is defined. That's not >>>> particularly well tested and you definitely found a bug. If >>>> that's defined, when rmdir calls the internal stat routine, which >>>> calls fileify, then 'abc/xyz' becomes 'abc/xyz.DIR;1'. >>> >>> If fileify is converting 'abc/xyz' to 'abc/xyz.DIR;1', that is a >>> bug that will break a lot of stuff. With the DECC$EFS_CHARSET >>> enabled, that should never happen anywhere. >>> >>> Not only should the ;1 not be present, the ".DIR" should not be >>> present either. >> >> I think we've had this discussion before. Fileify really has to >> append the .DIR;1 because there are too many things, rmdir being one >> of them, that simply cannot operate on a directory spec but only on a >> directory file. That's really the point of fileify and we wouldn't >> call it if we didn't have to > > In a UNIX format filespecification, the .DIR or .DIR;1 is always a bug. I suppose that's true if the user asked for Unix report mode and if we were reporting filespecs to the user. None of that has anything to do with the purpose of fileify, which is to provide the VMS-native filename of a directory so that it can be operated on by native services. Note in particular that readdir omits the extension and version when Unix report is in effect, so nothing should see the .DIR;1 that doesn't specifically ask for it by calling fileify. All uses of fileify in the core are in [.vms]vms.c. In fact there are only three uses: 1.) Perl_flex_stat_int. This stores an expanded filename in native format in an extended version of the stat structure so that its callers have it available if needed, and if the file is a directory, it's fileified. 2.) do_rmdir. This is ultimately based on SYS$ERASE. The format in which filenames are reported to the user is irrelevant; SYS$ERASE still has to have the .DIR extension to be able to delete a directory. 3.) Perl_rename. This is based on LIB$RENAME_FILE. What I said about SYS$ERASE in #2 applies here too. That's it. And in fact #2 seldom kicks in as rmdir normally gets the pre-fileified spec from stat() and only calls fileify directly if the stat failed. It may be that we could do a vmsify first and then fileify, but I think I tried that once and ran into trouble. It may be that we could refactor some of this code so that fileify simply becomes a flag passed to int_tovmsspec or int_rmsexpand. There is certainly a great deal of redundant processing in these routines. But changing fileify to not do what it was designed to do would break (at least) rmdir and rename and probably other things that depend on a native fileified spec in the stat buffer. > Neither DECC$EFS_CHARSET nor DECC$FILENAME_UNIX_REPORT has any impact >> on this. So I've changed vmsify in Perl to do exactly the same thing >> the CRTL does. Well, not exactly because the CRTL honors >> DECC$FILENAME_UNIX_NO_VERSION by escaping the semicolon even if the >> version spec is valid: > > Then Perl should also be using that feature. > >> $ DEFINE DECC$FILENAME_UNIX_NO_VERSION 1 >> $ mcr []to_vms >> abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file: >> [.ABC]XYZ.DAT^;32767 1 files found >> >> I haven't (yet) made Perl do this. It wouldn't be hard to do, but >> I'm a little skeptical about trying to support the whole wilderness >> of feature logicals. > > It is something that IMHO is critical to add, and I encountered this in the > test harness for GNU make and had to modify the code to work around it. OK, I'll add it. ________________________________________ Craig A. Berry mailto:craigbe...@mac.com "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
