On Tue, 8 May 2001, John Peacock wrote:
> > Nevertheless I do think that the seemingly bizarre idiom:
> >
> > 1 while unlink $file;
> >
> > ought to be documented, somewhere. It has been a part of perl for years
> > (look in perldoc - which has been that way since before 5.002 IIRC).
>
> Bingo! This is the important part. I wouldn't have bitched in the
> first place if I realized this was there for VMS to clean up after
> tests. Note that the (?) equivalent:
>
> unlink($file) while -t $file;
>
> should be documented at the same time, though the former is preferrable
> (only selfstubber.t is currently afflicted with the latter).
OK, but the former is less dependent on vaguaries of the C RTL limitations
of stat(). In looking at where to place the recommendation two places
come to mind apart from perlfunc.pod. A much requested place is
perlport.pod, but since it combines unlink() with a while "loop" one might
also mention it in perlsyn.pod. Since it is rather platform specific
(relevant primarily to VMS) perhaps perlport.pod ought to be the place
(whose VMS section could use an update to accomodate the lack of a 39.39
limit in ODS-5 anyway).
> > There is a need for better documentation on platform indpendent means of
> > common goofs in perl scripts such as:
> >
> > * coming up with a name for a temporary file (e.g. File::Temp,
> > POSIX::tmpfile(), IO::File::new_tmpfile(), etc.)
> > * C<1 while unlink $file> - why and under what circumstances you may want
> > to use it - i.e. primarily for VMS, and there only if you've created
> > the file and re-opened it for writing multiple times.
> > * Are there really enough pointers to File::Spec::* in perlport.pod?
> > Wouldn't some exemplary usage scenarios be helpful (as opposed to the
> > referential nature of the pod within the File/Spec/*.pm files)
> > * How to write a self extracting foo.PL -> (foo foo.bat foo.com) perl
> > program with reference to $Config{startperl}. That is basically to
> > document the stuff in the utils/ directory in the perl distribution and
> > how and why it's written in a peculiar fashion and how CPAN program
> > authors might benefit from similar packaging tricks. It would be good
> > to incorporate the recommendations from the [EMAIL PROTECTED] list into
> > such a doc.
However, some of this stuff might be too much for perlport.pod to carry.
Perhaps we ought to shift the discussion to [EMAIL PROTECTED]?
(I've only just subscribed and Cced that list with this reply).
Peter Prymmer
