At 3:53 PM -0800 12/20/03, Michael G Schwern wrote:
>On Sat, Dec 20, 2003 at 01:08:45PM -0600, Craig A. Berry wrote:
>> https://rt.cpan.org/NoAuth/Bug.html?id=4676
>>
>> I at first thought it was because there was a problem with passing a
>> directory spec in the form [.foo.bar] to chmod, but it's really
>> because MakeMaker is expanding the directory spec before it passes it
>> to chmod.
>
>That doesn't sound right. ExtUtils::Command::expand_wildcards() checks
>each argument to see if it has a wildcard in it before running it through
>glob().
Sigh. That's true of course. I now return to my original theory,
which is that chmod on a path spec that contains only the directory
part of a path and no filename part doesn't always do the right
thing. I've confirmed this with the following test program, which
assumes there is a valid but empty subdirectory called [.foo].
$ type chmod_test.c
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stat.h>
int
main () {
int status = chmod("[.foo]", 0755);
if (status == 0) {
printf("Succeeded\n");
}
else {
printf("Failed: %s\n", strerror(errno));
}
}
******
Running this after SET WATCH FILE/CLASS=ALL, the following snippet of output:
%XQP, Thread #0, Directory scan for: .;0, Status: 00000000
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
shows that it is indeed trying to find the noname file ".;0" and the
0x910 status is SS$_NOSUCHFILE. This happens on any version of VMS
I've been able to test on (7.1, 7.2-1, 7.3-1, all Alpha). What
happens next, though, is what makes the difference. With recent
versions of the C run-time, it proceeds to also do a lookup on
FOO.DIR;1 and set its protections if it exists. This last step
succeeds, and that success is the final status of the chmod call. If
that last step is skipped, as happens with those systems that are
experiencing the MakeMaker blibdirs problem, the final status of
chmod is file not found.
I've not been able to find anything in the CRTL ECO release notes
indicating when the behavior of chmod changed. All I know is that
the problem occurs on v7.1 Alpha and whatever Saku is running (v7.3
VAX?). Given the rather painful contortions that would be necessary
to either replace the CRTL's chmod or to handle this differently in
MakeMaker, the minus sign in front of the command in descrip.mms does
seem like the best solution. Someone who has fairly restrictive
default file protections and tries to run an uninstalled Perl from a
different account than the one used to build it could potentially run
into trouble, but if they did they could simply set the protections
(or better yet install Perl) and be off and running.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
