Re: glob() on VMS totally different than Unix.

Peter Prymmer wrote:
> "Craig A. Berry" <[email protected]> wrote on 01/21/2009 08:59:51 PM:
> 
>> On Jan 19, 2009, at 9:05 PM, John Malmberg wrote:
>>
>>> In investigating a failure of lib/Module/Build/t/compat.t, I 
>>> discovered that it was because glob() was behaving differently.
>>>
>>> glob('foo') on vms is interpreted as glob('foo.*') would be on Unix.
>> That's pretty much what would be expected from native utilities.  For 
>> example,
>>
>> $ dir foo
>>
>> Directory D0:[CRAIG.TEST]
>>
>> FOO.-ORIG;1         FOO.BAR;1           FOO.C;7             FOO.COM;25
>> FOO.CXX;5           FOO.DIR;1           FOO.H;4             FOO.LIS;4
>> FOO.MMS;5           FOO.OBJ;1           FOO.PATCH;1         FOO.TMP2;1
>> FOO.TXT;4
>>
>> Total of 13 files.
> 
> This was work intentionally carried out by Charles Bailey several years 
> ago.
> It is currently working and passing tests not only as discussed on vmsperl
> and as designed, but also as documented.  Here is a relevant passage
> from perlvms.pod that shipped with perl 5.8.7:
> 
>   In both the case of unquoted command line arguments or in calls
>   to C<glob()> VMS wildcard expansion is performed. (csh-style 
>   wildcard expansion is available if you use C<File::Glob::glob>.)
> 
> There is also some advice in the perlport.pod document:
> 
>   Don't count on filename globbing.  Use C<opendir>, C<readdir>, and
>   C<closedir> instead.

Based on that, the Module::Build component that is using glob needs to 
be changed to use File::Glob::glob instead.

I just completed build/test run of blead perl that was modified as per 
my previous e-mail, and found that no tests were dependent on the VMS 
specific behavior of glob(), and this resulted in the Module::Build test 
now passing.

Since there is a high risk in changing this default behavior, I will 
keep the old behavior as the default.  I will set the new behavior to be 
in effect when the DECC$FILENAME_REPORT_UNIX setting is active.

> vmsperl readers might note that perl on VMS is a programming
> language that runs on VMS.  It is not a programming environment.
> If you really want a Unix like programming environment you should
> consider running GNV instead of relying on a single programming
> language to provide your environment.

However GNV applications that use PERL require a Perl that behaves like 
it does on UNIX.  The patches that I am in the process of submitting 
allows Perl to be put in a mode to do that.  That way you can have one 
version of Perl and set behavior on a per application process.

> Perhaps it is worth noting that another difference between perl in 
> a Unix like environment and perl on VMS environment is that a call 
> to C<unlink($file);> will only delete the latest RMS version of $file. 
> Since Unix does not support RMS versioning one could point out 
> that the function call seems to differ between the two environments. 
> However, the function does not differ (since the $file;0 is deleted) 
> and leaving previous versions may be more useful to someone 
> writing a perl script to handle files on VMS the behavior is as 
> desired, intended, and most useful to users of the language.

An upcoming patch to blead-perl implements this as an environment 
option, controlled by a logical name.  It also covers the rename() case.

-John
[email protected]
Personal Opinion Only