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.
As a result, the clean target is incorrectly deleting 'foo.PL' when
it was requested to delete 'foo', along with deleting 'foo'.
Last time I checked, I thought it was because something was deleting
*.pl and assuming a case sensitive file system so *.PL got deleted as
well.
And even worse, if 'foobar' is a directory, glob('foobar') on VMS is
treated as if it were glob('foobar/*') on Unix. And it does not
matter if it is specified as glob('[.foobar]'), glob('foobar.dir'),
or glob('foobar/'), it still is treated as if it were glob('foobar/
*') on a Unix system.
In the case of a file, this appears that it may be an oversight in
the implementation. In the case of the directory, code has been
specifically added to cause this behavior.
I am trying to figure out what the fix should be.
I'm not sure either. Things have been the way they are for a very
long time, quite possibly since before any standards emerged for glob
or fnmatch.
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
