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

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 programmming 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.


Jordan Henderson
Compaq Services - Contracted to DAASC
Phone: (937) 656 3804

Trying is the first step to failure.   -Homer J. Simpson 

 






> -----Original Message-----
> From: Peter Prymmer [mailto:[email protected]]
> Sent: Thursday, September 13, 2001 11:44 PM
> To: Michael G Schwern
> Cc: Craig A. Berry; Chris Nandor; Nicholas Clark;
> [email protected]; [email protected]; [email protected]
> Subject: Re: [MacPerl-Porters] Re: portability.pm (was Re: 1 while
> unlink "file")
> 
> 
> 
> On Thu, 13 Sep 2001, Michael G Schwern wrote:
> 
> > The concern here is not that "unlink($file)" is less to type than "1
> > while unlink($file)".  The concern here is that I have to 
> *know* that
> > I have to use "1 while unlink($file)".  This and dozens of other
> > little tricks you need to know when writing test programs that are
> > supposed to work on OS's you've probably never touched in your life.
> > Not only that I have to know, but that everyone who writes tests has
> > to know this.
> >
> > I'm trying to lower the barrier to writing core tests so we can get
> > more people working on it.  I'm also trying to clean them up.  Right
> > now, there's a lot of "do_weird_thing if $^O eq ..." scattered all
> > over the tests.  This frightens people.
> >
> > If we can encapsulate the bulk of this wonky logic, it makes for
> > cleaner tests and it's less for people to need to learn, which means
> > more people writing tests.
> >
> > Perhaps I should have suggested it not be called something 
> as generic
> > as portable.pm.
> 
> Yours is a fine and noble goal.
> 
> In all honesty I would recommend that you write:
> 
>   unlink($file);
> 
> and thereby lower the barrier to writing more tests.  In the unusual
> cases (e.g. a file open()ed for write or append more than 
> once) where the
> C<1 while> VMS-ism would be needed in order to keep the VMS `mms test`
> result a bit tidier than it ordinarily would have been (e.g. to
> C<unlink("${file};1");>) then that could be added later by a 
> vmsperler.
> If it was not added then the worst case scenario has a few 
> more temp files
> lying about in the subdirectory know to VMSers as [.T].  That 
> is not a big
> deal.  In most cases where you want to unlink() a temp file 
> for testing
> you can get away without the C<1 while> prependage.
> 
> Peter Prymmer
> 
>