Michael G Schwern wrote: > On Wed, Sep 28, 2005 at 12:36:40PM -0400, John E. Malmberg wrote: > >>So then the VMS related choices for the lib/test/simple/t/create.t would be: >> >>A. Re-write it to avoid the VMS specific issue, like the patch that you >>posted earlier does. > > Ahh, except it wasn't a VMS specific issue. It was automatic, mandatory, > exclusive write locking (something not exclusive to VMS, I think Win32 does > it) and a perl bug with buffering. I didn't have to add in any more code, > its a basic cross-platform compat issue. Yes, but the locking is not "mandatory" by VMS, it is just the default behavior. The users of existing Perls on VMS can turn it off by a documented setting before running Perl, or they can put VMS specific code in their scripts to do so, even though they would probably be better off using VMS::Stdio instead. > So I guess what I'm saying here is I'm happy to code to the lowest common > denominator, or there is no intersection to do things like "if this > system has feature X, do Y". What I do not want is "if this *VMS* system > has feature X, do Y." Unfortunately I can see no way to avoid the check for an OS name and then if there then is an OS setting and maintain backwards compatibility with older Perls where that OS setting was not even considered as a possibility. > Again, without seeing the actual changes to the non-VMS modules I can't > really judge. Could you post them? I will look for a few typical cases if I can find time this evening and convert them from my 5.8.7 hacks to something that would use this proposed VMS::Filespec. If I could assume that a core module would never be used with an older version of Perl than what it was shipped with, then the test would be simpler to do. As it is, I will need to test if a method exists, and if it does, use the result from that method to determine if the existing VMS specific behavior needs to change. -John wb8tyw@qsl.net Personal Opinion OnlyThread Previous | Thread Next