RE: [MacPerl-Porters] Re: portability.pm (was Re: 1 while unlink "file")

On Fri, 14 Sep 2001, Henderson, Jordan wrote:

> Would it be unreasonable to have a mode for unlink() where it only deletes the
> most recent version, making delete all versions the default?  There's no easy
> solution, as people have probably written code that depends on unlink() deleting
> only the most recent version.
>
> >From a programming standpoint it's rather bad practice to delete only the most
> recent version and depend on older versions to be there due to version limits
> anyway, so perhaps we could break those old programs with the appropriate
> warnings in the README.VMS.
>
> I think it's really important for the future of VMSPerl that it accommodate
> programs written in non-VMS environments with as little change as possible.
>
> Look at it this way.  unlink() is a Unixism, SYS$ERASE() is VMS system specific.
> Without regard to the choices made by Compaq for the C runtime behavior of the C
> routine unlink(), we should choose the behavior for unlink() that is closest to
> what would happen on a Unix system when you unlink() a file.  Typically, unless
> someone else has it open, it means that the file is gone.

In my recent talks with folks using Perl on VMS it has become apparent
that Perl competes primarily with DCL as a scripting language, rather
than C as a compiled programming language.  As such I think it makes
sense for Perl's C<unlink()> to almost match DCL's DELETE command verb.
I say almost since, as you know saying:

    $ del login.com

will not delete anything and will tell you that you were unspecific
about the version that you wanted to delete.  As opposed to Perl where:

   unlink('login.com');

is effectively equivalent to saying:

   $ delete login.com;

But you now want for Perl's unlink() to be equivalent to saying:

   $ delete login.com;*

(BTW, as you well know you can set erase on delete on a volume wide
basis.)  Which would be equivalent on a Unix running RCS to having Perl's
unlink()  automatically do all of the following:

   unlink($file);
   if (-e "${file},v") {
       unlink("${file},v");
   }
   if (-e "RCS/${file},v") {
       unlink("RCS/${file},v");
       rmdir("RCS");
   }

I think that you would be hard pressed to find a Unix programming shop
using RCS that would want their chosen scripting language making such
policy decisions for them automatically.

Using the construct:

   unlink($file);

works for most cases on Unix and VMS implementations of perl and changing
it to:

   1 while unlink($file);

may help to keep VMS temp files a bit tidier, but in most cases is
unnecessary (note that the C<1 while> prependage does not harm the
file system semantics of Unix or Windows or MacOS).

I think that Perl in this regard already has an effective compromise
between the drastically different file systems that it has to run on.
I think that adding a version glob to unspecified unlink() arguments runs
counter to the data protection philosophy behind VMS' RMS (Record
management Services).  BTW Schwern's proposal was only to add
"convenience" to writing test scripts.  He specifically mentioned that he
did not want to alter the Perl programming language.

Peter Prymmer