多么“糟糕”啊！在 CentOS 上用 /usr/local/bin/perl 替换 /usr/bin/perl 吗？
回答：基本上，如果您编译了自己的 perl 并且按照操作系统的方式进行操作，则可以在没有重大副作用的情况下完成。虽然这不是推荐的做法，但我已经这样跑了一个多月了。我的结论是，如果您知道自己在做什么，那么这样做相对安全。
今天工作中得出的结论是需要将perl升级到5.10.0 CentOS 5.x 附带 perl 5.8.8。
我们确定使用 #!/usr/bin/perl 维护脚本所付出的努力是徒劳的。
根据 CPAN 和其他地方的一些安装内容，替换操作系统的 perl 版本并不是一个“好”主意。我已经更新了 /usr/bin/ 中的链接。所以我的问题是，替换 /usr/bin/perl 到底有多糟糕？
我还没有注意到我们的系统有任何不利影响，但我准备在出现问题时立即纠正链接（返回到 5.8.8）。
我担心 CentOS 标准发行版中可能有一些模块未包含在 CPAN 的源代码 5.10.0 中。我仍在试图弄清楚这些模块可能是什么。
提前致谢。
ANSWERED: Basically, it can be done with no major side-effects if you compiled your own perl and you did it the same way your OS did. While it isn't a recommended practice, I've been able to run like this for more then a month. I would conclude it is relatively safe to do if you know what you are doing.
We came to the conclusion at work today that we needed to upgrade perl to 5.10.0
CentOS 5.x comes with perl 5.8.8.
We determined that the effort involved in maintaining scripts with #!/usr/bin/perl was futile.
According to some install stuff on CPAN and other places, it isn't a 'good' idea to replace the OS's version of perl. I already updated the link in /usr/bin/. So my question is, how bad is it really to replace /usr/bin/perl?
I've not noticed any adverse effects in our systems yet, but I'm prepared to correct the link (back to 5.8.8) as soon as there is a problem.
I'm worried that there may be some modules in the CentOS standard distro that aren't included in CPAN's source 5.10.0. I'm still trying to figure out what those modules might be.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，如果您确实决定更改 Perl 的安装位置，那完全取决于您以及您喜欢的位置。但是，请记住，任何带有指向 #!/usr/bin/perl 的 shebang 行的脚本都可能会损坏。
我的建议是，安装后，在 /usr/bin/perl 中创建一个软链接，指向您安装的新版本 Perl 的可执行文件。只是一个想法。这是一种避免破坏任何东西的解决方法。
创建上面的链接肯定有助于避免“堵塞您的服务器”的可能性，正如 @Mu 指出的那样。
问候，
杰夫
Well, if you do decide to change the location of where Perl is installed, that is completely up to you and where you prefer it to be. But, keep in mind that any scripts that exist with a shebang line pointing to #!/usr/bin/perl will possibly break.
My recommendation would be that after you have installed it, create a soft link in /usr/bin/perl pointing to the executable for the new version of Perl that you installed. Just a thought. Its a work around to avoid breaking anything.
Creating the link above would certainly help to avoid the possibility of 'bricking your server' as @Mu pointed out.
Regards,
Jeff
根据我的经验，最佳实践是自己从源代码编译整个堆栈（Perl、Apache、ImageMagick...）。这使您可以完全控制使用所有内容的版本以及何时升级所有内容。
用你编译的替换
/usr/bin/perl是一件糟糕的事情。操作系统可能使用/usr/bin/perl作为其维护或init脚本的一部分，因此更改它可能会破坏您的服务器或导致奇怪的故障。因此，忽略系统 Perl，构建您自己的 Perl，并修复您的脚本以引用您的 Perl 版本。
In my experience, the best practice is to compile your entire stack (Perl, Apache, ImageMagick, ...) from source yourself. That gives you complete control over which versions of everything are used and when everything gets upgraded.
Replacing
/usr/bin/perlwith one you compiled is a crap shoot. The OS might be using/usr/bin/perlas part of its maintenance orinitscripts so changing it could brick your server or cause strange failures.So ignore the system Perl, build your own, and fix your scripts to refer to your version of Perl.
一般来说，较新版本的 Perl5 会尝试保持与旧版本的向后兼容性。但这并不能100%确定。例如，一个脚本依赖于 Perl 5.8.8 中未定义的行为（这不应该发生，但有时会发生），该行为在 5.10.0 下可能会有所不同。尽管如此，假设不涉及其他因素，通常可以相当安全地假设为 Perl 5.8.8 编写的脚本将在 5.10.0 下运行。
但通常还有其他因素（模块、XS 代码的字节兼容性等）。可能出现的问题有很多。这并不意味着他们中的任何一个都会在这次复飞中阻碍你，但可能会出现问题。
如果您已经在 /usr/local/bin 中获得了升级的 Perl，请继续使用它。但不要拆除或升级旧的 /usr/bin/ 版本。它只是硬盘驱动器的一小块（按照今天的标准来说非常小）。
顺便说一句，很多人都高度评价 perlbrew（CPAN 上的 App::Perlbrew）作为帮助维护 Perl 多个版本的工具。
Generally newer versions of Perl5 attempt to maintain backward compatibility with older versions. But that's not 100% assured. For example, a script that depends on an undefined behavior in Perl 5.8.8 (which shouldn't happen but sometimes does), that behavior may be different under 5.10.0. Nevertheless, it's usually fairly safe to assume that a script written for Perl 5.8.8 will run under 5.10.0 assuming there are no other factors involved.
But there usually are other factors (modules, byte compatibility for XS code, and so on). The list of possible gotchas is huge. That doesn't mean that any one of them will snag you on this go-around, but there is potential for problems.
If you've already got an upgraded Perl in /usr/local/bin, go ahead and use it. But don't dismantle or upgrade the old /usr/bin/ version. It's only a small chunk of hard drive (very small by today's standards).
By the way, a lot of people speak highly of perlbrew (App::Perlbrew on CPAN) as a tool to help maintain multiple versions of Perl.