Skip Menu |
Report information
Id: 72028
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: zefram [at] fysh.org
Cc:
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: low
Type: library
Perl Version: 5.11.3
Fixed In: 5.19.11



CC: zefram [...] fysh.org
Subject: execute permission missing from some utils
Date: Mon, 11 Jan 2010 20:21:17 +0000
To: perlbug [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 3.7k
This is a bug report for perl from zefram@vigo.rous.org, generated with the help of perlbug 1.39 running under perl 5.11.3. ----------------------------------------------------------------- [Please describe your issue here] The utility programs config_data, pod2text, and shasum are installed by the core distribution into the target bin directory without execute permissions: $ ls -l *(^x) -rw-rw-rw- 1 zefram zefram 7453 Jan 2 22:06 config_data5.11.3 -rw-rw-rw- 1 zefram zefram 9192 Jan 2 22:06 pod2text5.11.3 -rw-rw-rw- 1 zefram zefram 7767 Jan 2 22:06 shasum5.11.3 Subsequent installations of the three programs, from their respective module distributions on CPAN, have execute permissions as normal. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.11.3: Configured by zefram at Mon Dec 21 12:26:37 GMT 2009. Summary of my perl5 (revision 5 version 11 subversion 3) configuration: Platform: osname=linux, osvers=2.6.26-2-686, archname=i386-linux-thread-multi uname='linux vigo.rous.org 2.6.26-2-686 #1 smp wed nov 4 20:45:37 utc 2009 i686 gnulinux ' config_args='-des -Darchname=i386-linux -Dcccdlflags=-fPIC -Dccdlflags=-rdynamic -Dprefix=/home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52 -Dman1ext=1 -Dman3ext=3perl -Duselargefiles -Dusethreads -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dusedevel -Ui_db' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.3.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.7' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52/lib/5.11.3/i386-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' Locally applied patches: --- @INC for perl 5.11.3: /home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52/lib/site_perl/5.11.3/i386-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52/lib/site_perl/5.11.3 /home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52/lib/5.11.3/i386-linux-thread-multi /home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52/lib/5.11.3 . --- Environment for perl 5.11.3: HOME=/home/zefram LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/zefram/usr/perl/perl_install/perl-5.11.3-i32-f52/bin:/home/zefram/usr/perl/util:/home/zefram/pub/i686-pc-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/bin:/usr/games PERL_BADLANG (unset) SHELL=/usr/bin/zsh
Subject: Re: [perl #72028] execute permission missing from some utils
Date: Tue, 12 Jan 2010 12:25:24 +0100
To: Perl 5 Porters <perl5-porters [...] perl.org>
From: Rafael Garcia-Suarez <rgs [...] consttype.org>
Download (untitled) / with headers
text/plain 919b
2010/1/11 Zefram <perlbug-followup@perl.org>: Show quoted text
> The utility programs config_data, pod2text, and shasum are installed > by the core distribution into the target bin directory without execute > permissions: > > $ ls -l *(^x) > -rw-rw-rw- 1 zefram zefram  7453 Jan  2 22:06 config_data5.11.3 > -rw-rw-rw- 1 zefram zefram  9192 Jan  2 22:06 pod2text5.11.3 > -rw-rw-rw- 1 zefram zefram  7767 Jan  2 22:06 shasum5.11.3 > > Subsequent installations of the three programs, from their respective > module distributions on CPAN, have execute permissions as normal.
This is not reproduced here : [rafael@stcosmo bin]$ ls -l config_data5.11.3 pod2text5.11.3 shasum5.11.3 -rwxr-xr-x 1 rafael rafael 7375 2010-01-12 12:22 config_data5.11.3 -rwxr-xr-x 1 rafael rafael 9114 2010-01-12 12:22 pod2text5.11.3 -rwxr-xr-x 1 rafael rafael 7689 2010-01-12 12:22 shasum5.11.3 Are you building from a tarball or from a git checkout ?
Subject: Re: [perl #72028] execute permission missing from some utils
Date: Tue, 12 Jan 2010 11:27:43 +0000
To: Perl 5 Porters <perl5-porters [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 207b
Rafael Garcia-Suarez wrote: Show quoted text
>Are you building from a tarball or from a git checkout ?
It was from the 5.11.3 tarball. If you're testing on blead, maybe it's been fixed by updates of the modules? -zefram
Subject: Re: [perl #72028] execute permission missing from some utils
Date: Thu, 14 Jan 2010 00:38:20 +0000
To: Perl 5 Porters <perl5-porters [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.6k
Turns out this isn't a problem with the original core install. The permissions are getting broken by later module installs. Take the example of config_data. The bare install yields -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 Immediately after installation, I routinely create symlinks for the unversioned form of the name. (The install has its own directory tree, so there's no issue of conflicting with another perl.) So I have lrwxrwxrwx 1 zefram zefram 17 Jan 13 22:42 config_data -> config_data5.11.3 -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 If I then do "cpan Module::Build", this installs a newer Module::Build, including the latest version of config_data. I'm left with -r-xr-xr-x 1 zefram zefram 7244 Jan 13 22:46 config_data -rw-rw-rw- 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 The culprit is ExtUtils::Install. Needing to install something as config_data, and finding that there's something already there, it's doing a chmod to 666 before unlinking it. The chmod follows the symlink, and so affects config_data5.11.3, but the unlink successfully removes the symlink. A hard link would have the same result as the symlink. Here's the minimal demonstration: $ mkdir from to $ echo oldoldold > to/b $ chmod 755 to/b $ ln -s b to/a $ echo new > from/a $ chmod 755 from/a $ ls -l to total 4 lrwxrwxrwx 1 zefram zefram 1 Jan 14 00:36 a -> b -rwxr-xr-x 1 zefram zefram 10 Jan 14 00:36 b $ perl -MExtUtils::Install -e 'install({ "from" => "to" })' Installing to/a $ ls -l to total 8 -r-xr-xr-x 1 zefram zefram 4 Jan 14 00:37 a -rw-rw-rw- 1 zefram zefram 10 Jan 14 00:36 b $ -zefram
Subject: ExtUtils::Install problem: execute permission missing from some utils
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
On Wed Jan 13 16:38:48 2010, zefram@fysh.org wrote: Show quoted text
> Turns out this isn't a problem with the original core install. > The permissions are getting broken by later module installs. Take the > example of config_data. The bare install yields > > -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 > > Immediately after installation, I routinely create symlinks for the > unversioned form of the name. (The install has its own directory > tree, > so there's no issue of conflicting with another perl.) So I have > > lrwxrwxrwx 1 zefram zefram 17 Jan 13 22:42 config_data -> > config_data5.11.3 > -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 > > If I then do "cpan Module::Build", this installs a newer > Module::Build, > including the latest version of config_data. I'm left with > > -r-xr-xr-x 1 zefram zefram 7244 Jan 13 22:46 config_data > -rw-rw-rw- 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 > > The culprit is ExtUtils::Install. Needing to install something as > config_data, and finding that there's something already there, it's > doing > a chmod to 666 before unlinking it. The chmod follows the symlink, > and so affects config_data5.11.3, but the unlink successfully removes > the symlink. A hard link would have the same result as the symlink. > > Here's the minimal demonstration: > > $ mkdir from to > $ echo oldoldold > to/b > $ chmod 755 to/b > $ ln -s b to/a > $ echo new > from/a > $ chmod 755 from/a > $ ls -l to > total 4 > lrwxrwxrwx 1 zefram zefram 1 Jan 14 00:36 a -> b > -rwxr-xr-x 1 zefram zefram 10 Jan 14 00:36 b > $ perl -MExtUtils::Install -e 'install({ "from" => "to" })' > Installing to/a > $ ls -l to > total 8 > -r-xr-xr-x 1 zefram zefram 4 Jan 14 00:37 a > -rw-rw-rw- 1 zefram zefram 10 Jan 14 00:36 b > $ > > -zefram >
I was able to reproduce Zefram's minimal case demonstration tonight. Should we be patching ExtUtils::Install? Thank you very much. Jim Keenan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
On Tue Feb 19 18:44:44 2013, jkeenan wrote: Show quoted text
> On Wed Jan 13 16:38:48 2010, zefram@fysh.org wrote:
> > Turns out this isn't a problem with the original core install. > > The permissions are getting broken by later module installs. Take the > > example of config_data. The bare install yields > > > > -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 > > > > Immediately after installation, I routinely create symlinks for the > > unversioned form of the name. (The install has its own directory > > tree, > > so there's no issue of conflicting with another perl.) So I have > > > > lrwxrwxrwx 1 zefram zefram 17 Jan 13 22:42 config_data -> > > config_data5.11.3 > > -rwxr-xr-x 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 > > > > If I then do "cpan Module::Build", this installs a newer > > Module::Build, > > including the latest version of config_data. I'm left with > > > > -r-xr-xr-x 1 zefram zefram 7244 Jan 13 22:46 config_data > > -rw-rw-rw- 1 zefram zefram 7361 Jan 13 22:33 config_data5.11.3 > > > > The culprit is ExtUtils::Install. Needing to install something as > > config_data, and finding that there's something already there, it's > > doing > > a chmod to 666 before unlinking it. The chmod follows the symlink, > > and so affects config_data5.11.3, but the unlink successfully removes > > the symlink. A hard link would have the same result as the symlink. > > > > Here's the minimal demonstration: > > > > $ mkdir from to > > $ echo oldoldold > to/b > > $ chmod 755 to/b > > $ ln -s b to/a > > $ echo new > from/a > > $ chmod 755 from/a > > $ ls -l to > > total 4 > > lrwxrwxrwx 1 zefram zefram 1 Jan 14 00:36 a -> b > > -rwxr-xr-x 1 zefram zefram 10 Jan 14 00:36 b > > $ perl -MExtUtils::Install -e 'install({ "from" => "to" })' > > Installing to/a > > $ ls -l to > > total 8 > > -r-xr-xr-x 1 zefram zefram 4 Jan 14 00:37 a > > -rw-rw-rw- 1 zefram zefram 10 Jan 14 00:36 b > > $ > > > > -zefram > >
> > I was able to reproduce Zefram's minimal case demonstration tonight. > Should we be patching ExtUtils::Install? >
Is there anyone who could take a look at ExtUtils::Install? Thank you very much. Jim Keenan
Subject: Re: -l on win32, VMS etc Was: [perl #72028] execute permission missing from some utils
Date: Sat, 29 Mar 2014 19:09:33 +0000
To: Zefram <zefram [...] fysh.org>
From: Dave Mitchell <davem [...] iabyn.com>
CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 956b
(changing the subject line to ensure any followups are attached to the ticket) On Wed, Mar 26, 2014 at 01:08:55PM +0000, Zefram wrote: Show quoted text
> Dave Mitchell wrote:
> >and I want to change it to > > > > chmod 0666, $file unless -l $file; > > unlink $file;
> > That wouldn't be correct: it still screws up on hard links. Long-standing > problem [perl #72028].
Yes, that's the ticket I'm looking at fixing. But thinking a little further, it makes no sense (on UNIXy systems at least) to do the chmod before unlinking a file, since it's the permissions of the directory, not the file, that determine whether a file can be unlinked. So I guess the chmod 066 is only for Windows etc? Do platforms like that emulate chmod, and does such a chmod help delete a file that been previously installed 0444 or equivalent? I think I'm a bit out of my depth on such portability issues, and I think I'll stop working on this ticket. -- Monto Blanco... scorchio!
Date: Sat, 29 Mar 2014 20:18:47 +0000
To: perl5-porters [...] perl.org
Subject: Re: -l on win32, VMS etc Was: [perl #72028] execute permission missing from some utils
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.5k
Dave Mitchell wrote: Show quoted text
>But thinking a little further, it makes no sense (on UNIXy systems at >least) to do the chmod before unlinking a file, since it's the permissions >of the directory, not the file, that determine whether a file can be >unlinked.
Indeed. I'm pretty annoyed that correctness on Unix has become a casualty of the quest for portability to crippled OSes. Show quoted text
>So I guess the chmod 066 is only for Windows etc?
I believe on Windows permission to delete a file is the same as permission to write to that file. The chmod would make sense in that context. On VMS, permission to delete a file is a separate permission bit, stored on the file itself. I don't know what the chmod emulation does with it. Quite likely it sets the delete-permission bit to match the write-permission bit. Show quoted text
>I think I'm a bit out of my depth on such portability issues,
What we need is a way to determine whether the chmod is needed. $^O is probably sufficient key, if we can just be sure which values indicate an OS that needs it. Digging in the git history and BackPAN, the chmod logic came in while EU:I was bundled in the MakeMaker distro, in MakeMaker-5.27. The Changes entry describing it credits it to Ilya. It doesn't say specifically what OSes it's intended for. I'd be inclined to make the chmod conditional on $^O =~ /\A(?:MSWin32|VMS)\z/. If that breaks it for some OS of which we know even less, presumably we'll get a bug report identifying the OS. Flawed though this approach is, by fixing the module for all Unices we'd immediately make it qualitatively much less buggy. -zefram
Subject: Re: -l on win32, VMS etc Was: [perl #72028] execute permission missing from some utils
Date: Sun, 6 Apr 2014 13:37:46 +0100
To: Zefram <zefram [...] fysh.org>
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 891b
On Sat, Mar 29, 2014 at 08:18:47PM +0000, Zefram wrote: Show quoted text
> I'd be inclined to make the chmod conditional on $^O =~ > /\A(?:MSWin32|VMS)\z/. If that breaks it for some OS of which we > know even less, presumably we'll get a bug report identifying the OS. > Flawed though this approach is, by fixing the module for all Unices we'd > immediately make it qualitatively much less buggy.
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 installing an older version of a CPAN module, then installing a newer version and making sure that it deletes the older files and replaces them with newer ones. -- Wesley Crusher gets beaten up by his classmates for being a smarmy git, and consequently has a go at making some friends of his own age for a change. -- Things That Never Happen in "Star Trek" #18
Subject: Re: -l on win32, VMS etc Was: [perl #72028] execute permission missing from some utils
CC: Zefram <zefram [...] fysh.org>, "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
To: Dave Mitchell <davem [...] iabyn.com>
Date: Sun, 6 Apr 2014 19:23:30 +0100
From: Steve Hay <steve.m.hay [...] googlemail.com>
On 6 April 2014 13:37, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Sat, Mar 29, 2014 at 08:18:47PM +0000, Zefram wrote:
>> I'd be inclined to make the chmod conditional on $^O =~ >> /\A(?:MSWin32|VMS)\z/. If that breaks it for some OS of which we >> know even less, presumably we'll get a bug report identifying the OS. >> Flawed though this approach is, by fixing the module for all Unices we'd >> immediately make it qualitatively much less buggy.
> > 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 > installing an older version of a CPAN module, then installing a newer > version and making sure that it deletes the older files and replaces > them with newer ones. >
It works fine for me in normal usage on Windows -- as I'd expect, since you've not actually changed anything for Windows users. Hard links, soft links ("junctions") and symbolic links are all possible on Windows (7, at least), e.g. see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365006%28v=vs.85%29.aspx I tried following Zefram's minimal demonstration from #72028 (noting that the 'link' and 'target' arguments in Windows 7's mklink command are the opposite way around to *nix's ln command: http://technet.microsoft.com/en-us/library/cc753194.aspx), only to find that ExtUtils::Install fails to install the from/a file at all, claiming that some unnamed file doesn't exist!: 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 symbolic link created for 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 Volume in drive C is OS Volume Serial Number is 4E13-1B46 Directory of C:\Dev\Temp\to 06/04/2014 19:07 <DIR> . 06/04/2014 19:07 <DIR> .. 06/04/2014 19:07 <SYMLINK> a [to\b] 06/04/2014 19:06 12 b 2 File(s) 12 bytes 2 Dir(s) 1,286,697,168,896 bytes free C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to total 1 lrwxrwxrwx 1 Administrators None 4 Apr 6 19:07 a -> to/b -rwx------+ 1 Administrators None 12 Apr 6 19:06 b C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]" 00 C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/b')[2]" 0666 C:\Dev\Temp>perl -MExtUtils::Install -e "install({ 'from' => 'to' })" Installing to\a !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ERROR: Cannot copy 'from\a' to 'to\a': No such file or directory !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! at -e line 1. The file from\a does exist, and is readable and not empty, so I can only assume that it's complaining about some problem with the target file, to\a -- because it's a symbolic link? And indeed if I replace "mklink to\a to\b" with "copy to\b to\a" above then the install works fine. It also works with a hard link, but the chmod 0666 seems not to have followed the link like it does on *nix -- the link target (to\b) has the same (wacky!) perms as before the installation; only the installed file (to\a) is different: 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 Hardlink created for 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 Volume in drive C is OS Volume Serial Number is 4E13-1B46 Directory of C:\Dev\Temp\to 06/04/2014 19:13 <DIR> . 06/04/2014 19:13 <DIR> .. 06/04/2014 19:13 12 a 06/04/2014 19:13 12 b 2 File(s) 24 bytes 2 Dir(s) 1,286,697,095,168 bytes free C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to total 2 -rwx------+ 2 Administrators None 12 Apr 6 19:13 a -rwx------+ 2 Administrators None 12 Apr 6 19:13 b C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]" 0666 C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/b')[2]" 0666 C:\Dev\Temp>perl -MExtUtils::Install -e "install({ 'from' => 'to' })" Installing to\a C:\Dev\Temp>dir to Volume in drive C is OS Volume Serial Number is 4E13-1B46 Directory of C:\Dev\Temp\to 06/04/2014 19:15 <DIR> . 06/04/2014 19:15 <DIR> .. 06/04/2014 19:13 6 a 06/04/2014 19:13 12 b 2 File(s) 18 bytes 2 Dir(s) 1,286,697,074,688 bytes free C:\Dev\Temp>C:\Dev\Software\Cygwin\bin\ls -l to total 2 -r-x------+ 1 Administrators None 6 Apr 6 19:13 a -rwx------+ 1 Administrators None 12 Apr 6 19:13 b C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/a')[2]" 0444 C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'to/b')[2]" 0666 I think this demonstrates that nobody is using symbolic links like this on Windows since ExtUtils::Install fails in that case anyway; and if anyone is using hard links (also quite unlikely, I think) then it seems to work fine anyway. I don't think the chmod is necessary, btw, but since it doesn't hurt like it does on *nix I'd be inclined to not change it in case there is some reason for it that I'm not aware of. A read-only file (in the sense of the read-only file 'attribute', which is what chmod 0666 ... will turn off) can be deleted by perl's unlink() anyway, although Windows's own del command can't delete it!: C:\Dev\Temp>echo junk>a C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'a')[2]" 0666 C:\Dev\Temp>attrib a A C:\Dev\Temp\a C:\Dev\Temp>attrib +r a C:\Dev\Temp>perl -le "printf '0%o', 07777 & (stat 'a')[2]" 0444 C:\Dev\Temp>attrib a A R C:\Dev\Temp\a C:\Dev\Temp>del a C:\Dev\Temp\a Access is denied. C:\Dev\Temp>perl -e "unlink 'a' or die $!" C:\Dev\Temp>dir /b a File Not Found unlink() won't be able to delete a file that has been made read-only via ACLs (access control lists), and chmod 0666 ... won't help there either, but it won't hurt, and again people can't be working that way anyway. So your (no-op) change on Windows is fine with me.
To: Zefram <zefram [...] fysh.org>
Date: Mon, 14 Apr 2014 11:43:33 +0100
Subject: Re: -l on win32, VMS etc Was: [perl #72028] execute permission missing from some utils
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 646b
On Sun, Apr 06, 2014 at 01:37:46PM +0100, Dave Mitchell wrote: Show quoted text
> On Sat, Mar 29, 2014 at 08:18:47PM +0000, Zefram wrote:
> > I'd be inclined to make the chmod conditional on $^O =~ > > /\A(?:MSWin32|VMS)\z/. If that breaks it for some OS of which we > > know even less, presumably we'll get a bug report identifying the OS. > > Flawed though this approach is, by fixing the module for all Unices we'd > > immediately make it qualitatively much less buggy.
> > I've now pushed something similar as smoke-me/davem/ext-install.
And now in blead with 98656abe1a460777edc9c9dc6212d106fe843c60 -- Standards (n). Battle insignia or tribal totems.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org