good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I think the system's perl belongs to the system and you should not be doing stuff like installing non packaged perl modules and running your production application with it.
I disagree. If an OS depends on a certain version/build of perl (or python, or whatever), then they shouldn't put it in /usr/bin/perl. Solaris got this one right (assuming they haven't changed their policy, it's been a while since I last used Solaris). They too have quite a number of scripts that may break if you replace the default perl. So they put perl somewhere else (say /some/path/to/perl) and start their programs that use perl with #!/some/path/to/perl. /usr/bin/perl is then a link to /some/path/to/perl. Now, if you want to put your own perl in /usr/bin/perl, you can do it. The systems scripts will not refer to it, and they'll keep using the default perl that came with the system. In reply to Re: blaming perl for not using a build policy
by JavaFan
|
|