New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExtUtils::Install problem: execute permission missing from some utils #10074
Comments
From zefram@fysh.orgCreated by zefram@vigo.rous.orgThe utility programs config_data, pod2text, and shasum are installed $ ls -l *(^x) Subsequent installations of the three programs, from their respective Perl Info
|
From @rgarcia2010/1/11 Zefram <perlbug-followup@perl.org>:
This is not reproduced here : [rafael@stcosmo bin]$ ls -l config_data5.11.3 pod2text5.11.3 shasum5.11.3 Are you building from a tarball or from a git checkout ? |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgRafael Garcia-Suarez wrote:
It was from the 5.11.3 tarball. If you're testing on blead, maybe it's -zefram |
From zefram@fysh.orgTurns out this isn't a problem with the original core install. -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 Immediately after installation, I routinely create symlinks for the lrwxrwxrwx 1 zefram zefram 17 Jan 13 22:42 config_data -> config_data5.11.3 If I then do "cpan Module::Build", this installs a newer Module::Build, -r-xr-xr-x 1 zefram zefram 7244 Jan 13 22:46 config_data The culprit is ExtUtils::Install. Needing to install something as Here's the minimal demonstration: $ mkdir from to -zefram |
From @jkeenanOn Wed Jan 13 16:38:48 2010, zefram@fysh.org wrote:
I was able to reproduce Zefram's minimal case demonstration tonight. Thank you very much. |
From @jkeenanOn Tue Feb 19 18:44:44 2013, jkeenan wrote:
Is there anyone who could take a look at ExtUtils::Install? Thank you very much. |
From @iabyn(changing the subject line to ensure any followups are attached to the On Wed, Mar 26, 2014 at 01:08:55PM +0000, Zefram wrote:
Yes, that's the ticket I'm looking at fixing. But thinking a little further, it makes no sense (on UNIXy systems at So I guess the chmod 066 is only for Windows etc? Do platforms like that I think I'm a bit out of my depth on such portability issues, and I think -- |
From zefram@fysh.orgDave Mitchell wrote:
Indeed. I'm pretty annoyed that correctness on Unix has become a casualty
I believe on Windows permission to delete a file is the same as permission On VMS, permission to delete a file is a separate permission bit,
What we need is a way to determine whether the chmod is needed. $^O is Digging in the git history and BackPAN, the chmod logic came in while I'd be inclined to make the chmod conditional on $^O =~ -zefram |
From @iabynOn Sat, Mar 29, 2014 at 08:18:47PM +0000, Zefram wrote:
I've now pushed something similar as smoke-me/davem/ext-install. I'd be particularly keen for owners of non-POSIX platforms to check it by -- |
From @steve-m-hayOn 6 April 2014 13:37, Dave Mitchell <davem@iabyn.com> wrote:
It works fine for me in normal usage on Windows -- as I'd expect, Hard links, soft links ("junctions") and symbolic links are all I tried following Zefram's minimal demonstration from #72028 (noting C:\Dev\Temp>mkdir from to C:\Dev\Temp>echo oldoldold >to\b C:\Dev\Temp>perl -e "chmod 0755, 'to/b'" C:\Dev\Temp>mklink to\a to\b C:\Dev\Temp>echo new >from\a C:\Dev\Temp>perl -e "chmod 0755, 'from/a'" C:\Dev\Temp>dir to Directory of C:\Dev\Temp\to 06/04/2014 19:07 <DIR> . C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]" The file from\a does exist, and is readable and not empty, so I can And indeed if I replace "mklink to\a to\b" with "copy to\b to\a" above It also works with a hard link, but the chmod 0666 seems not to have C:\Dev\Temp>mkdir from to C:\Dev\Temp>echo oldoldold >to\b C:\Dev\Temp>perl -e "chmod 0755, 'to/b'" C:\Dev\Temp>mklink /h to\a to\b C:\Dev\Temp>echo new >from\a C:\Dev\Temp>perl -e "chmod 0755, 'from/a'" C:\Dev\Temp>dir to Directory of C:\Dev\Temp\to 06/04/2014 19:13 <DIR> . C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]" C:\Dev\Temp>dir to Directory of C:\Dev\Temp\to 06/04/2014 19:15 <DIR> . C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]" I think this demonstrates that nobody is using symbolic links like I don't think the chmod is necessary, btw, but since it doesn't hurt C:\Dev\Temp>echo junk>a C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'a')[2]" C:\Dev\Temp>attrib +r a C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'a')[2]" C:\Dev\Temp>del a C:\Dev\Temp>perl -e "unlink 'a' or die $!" C:\Dev\Temp>dir /b a unlink() won't be able to delete a file that has been made read-only So your (no-op) change on Windows is fine with me. |
From @iabynOn Sun, Apr 06, 2014 at 01:37:46PM +0100, Dave Mitchell wrote:
And now in blead with 98656ab -- |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#72028 (status was 'resolved')
Searchable as RT72028$
The text was updated successfully, but these errors were encountered: