Re^2: Executable bit sloppiness in modules

Replies are listed 'Best First'.
Re^3: Executable bit sloppiness in modules by demerphq (Chancellor) on Dec 19, 2004 at 11:28 UTC
IME its standard practice to convert CPAN modules to unix lines endings before upload. I know that I have had to do so for all of my modules. So im not sure you can rely on the line endings as being indicitive. For instance what mode are the modules from Data::Dump::Streamer? --- demerphq	[reply]
Re^4: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 19, 2004 at 11:44 UTC
Data::Dump::Streamer has unix line endings, but all files and directories are mode 755. I just don't like that, and makes me leary of automatic Cpan installs. It makes me want to give all the files a "look-over" first. I can see how this could be abused by introducing executable files to your system.( Like license.txt....how many people actually check it?) For instance, what if I'm a little groggy, and want to look at the README file, and accidently double click it, instead of opening it for viewing, and the first line was a system command? I just think that part of CPAN's rules, should be correct file permissions for the file types. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^5: Executable bit sloppiness in modules by demerphq (Chancellor) on Dec 19, 2004 at 11:55 UTC
How do I on Win32 make sure that `nmake dist` produces a file with the correct permissions? I mean execute priviledges on Win32 dont have the same meaning as they do on Unix. So what to do when permission semantics are not platform portable? (Executable permissions on a file that isnt a registered executable type do nothing on Win32) --- demerphq	[reply] [d/l]
Re^3: Executable bit sloppiness in modules by Mutant (Priest) on Dec 20, 2004 at 13:05 UTC
A bit of a side-track from the actual issue, but it's possible to save files in windows with unix newlines (and vice verca), so this isn't really a good indication of where the files orignally came from. But to the issue at hand.. I agree, I don't think files should be executable unless they need to be. One reason this might have happened is that if you have multiple authors working on a project using CVS, and one or more of them are running Windows, you often get files that are set to 755 checked into CVS. Once in CVS, you can't (easily) change the permissions, so everytime they're checked out, you have to manually change them.	[reply]
Re^3: Executable bit sloppiness in modules by iburrell (Chaplain) on Dec 20, 2004 at 21:30 UTC
It has nothing to do with line endings. Tar archives from Windows tend to have mode 777 for all filesbecause Windows does not have standard mode bits and the archive program can't know if files are executable or not. This also happens when Windows disks are mounted on Unix. Every file is usually has mode 777 for the same reason.	[reply]
Re^4: Executable bit sloppiness in modules by zentara (Cardinal) on Dec 21, 2004 at 13:35 UTC
Yes I know it has nothing to do with lineendings, but I was using lineendings as a "clue", as to which OS the modules were written on. I'm not really a human, but I play one on earth. flash japh	[reply]