Front page | perl.perl5.porters |
Postings from June 2006
In article <9b18b3110606251159xdb63ba5re71b316a91b7ea5a@mail.gmail.com>, demerphq@gmail.com (demerphq) wrote: > If the semantics of 'open' where changed to support more advanced > locking and sharing models, in memory temp files, or delete on close > semantics then UNIX would just ignore or fake it as needed. But where > the additional semantics are supported the os should do so. > In fact i once recommended that open be extended to support the idea > of opening a self deleting temporary file. On unix this would mean > that open would do the unlink logic, on win32 it would do something > else. Either way it would mean that programmers wouldnt have to worry > about how it happens. Does the unlink_on_close feature of File::Temp not work on Win32? If not, is it considered somehow difficult to make win32_tmpfile() available from Perl so that File::Temp can do the Win32-appropriate thing on Win32? Do programmers who use File::Temp "have to worry about how it happens"? You could argue that File::Temp is not the abstraction you would choose, but you can't argue that it doesn't exist. I can't see any bias against general solutions, but they usually come by building on specific solutions. When Tim wanted to put the delete-on-close feature into File::Temp, I was able to give him a one-line VMS-specific implementation because VMS::Stdio::vmssysopen had long since solved that problem and been included in the core. In fact all of the features you mention above (except, I think, in-memory temp files) have been available in the core for a decade or more if one's platform is VMS. I would suggest implementing the platform-specific features you want and (if they are general building block type features) agitate for their inclusion in the core and only then look around for affinities with other OS's that might be brought together under a common interface.