Skip to content
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

Closed
p5pRT opened this issue Jan 11, 2010 · 13 comments
Closed

ExtUtils::Install problem: execute permission missing from some utils #10074

p5pRT opened this issue Jan 11, 2010 · 13 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 11, 2010

Migrated from rt.perl.org#72028 (status was 'resolved')

Searchable as RT72028$

@p5pRT
Copy link
Author

p5pRT commented Jan 11, 2010

From zefram@fysh.org

Created by zefram@vigo.rous.org

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.

Perl Info

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

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2010

From @rgarcia

2010/1/11 Zefram <perlbug-followup@​perl.org>​:

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 ?

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2010

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jan 12, 2010

From zefram@fysh.org

Rafael Garcia-Suarez wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2010

From zefram@fysh.org

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

@p5pRT
Copy link
Author

p5pRT commented Feb 20, 2013

From @jkeenan

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?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Jul 13, 2013

From @jkeenan

On Tue Feb 19 18​:44​:44 2013, jkeenan wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2014

From @iabyn

(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​:

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!

@p5pRT
Copy link
Author

p5pRT commented Mar 29, 2014

From zefram@fysh.org

Dave Mitchell wrote​:

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.

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.

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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2014

From @iabyn

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.

--
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

@p5pRT
Copy link
Author

p5pRT commented Apr 6, 2014

From @steve-m-hay

On 6 April 2014 13​:37, Dave Mitchell <davem@​iabyn.com> wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2014

From @iabyn

On Sun, Apr 06, 2014 at 01​:37​:46PM +0100, Dave Mitchell wrote​:

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 98656ab

--
Standards (n). Battle insignia or tribal totems.

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2014

@iabyn - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant