>从源代码编译
>安装在/usr/local中
>切勿触摸系统perl

学习它.知道.住它.

…

哦,好吧,我会试着解释一下.触摸系统perl根本不是一个坏主意,我希望这是明显的原因. Apple的应用程序,第三方应用程序和操作系统本身期望系统perl的行为类似于系统perl – 有时与系统perl完全相同.举一个例子,iTunes安装程序一度包含一个perl脚本,其中包含如下代码：

if ($foo EQ $bar) {
    ....
}

是的,EQ而不是eq.信不信由你,这实际上适用于许多旧版本的perl – 但在新版本的perl中我并没有在我年轻的天真中安装在系统版本之上.结果是我双击iTunes安装程序,几乎没有任何事情发生. (嘿,它可能是a lot worse.)

我们可以谈谈苹果公司当时编写perl代码的猴子种类(现在质量更好)但最重要的是/ System是Apple的域名. Attempt no landing there.(多么热门.)

另一方面,Apple长期以来一直承诺不会在/usr/local中放置任何东西,同样重要的是,不要触摸系统更新期间的任何内容.这是你的安全区.在那里安装你的perl,CPAN模块所需的库等等.

最后,为什么要从源代码构建？为什么不使用包管理器？这可能看起来像脾气暴躁的老人推理,但我更愿意将其视为难得的智慧.对于Mac OS X,没有一个主流软件包管理系统,更不用说官方/内置管理系统了.所有各种第三方软件包管理器都遇到了与我使用的每个软件包管理器相同的问题：有时候你想要的软件没有打包,有时它没有按照你想要的方式打包,有时它只是简单的破坏了除了从源代码构建一些软件之外,尝试安装软件包也是一种灾难.

唯一可行的“统一”方法是从源头构建一切.目前,几乎所有常用的Unix软件都是在Mac OS X上构建的,没有任何特别的努力. (现在有很多Unix开发人员使用Mac OS X作为他们的个人系统,这很有帮助.)它通常只是解压缩,配置,制作,安装.您甚至不需要指定/usr/local作为目标;这是大多数软件的默认设置.

所以你有它：从源代码编译.安装在/usr/local中.切勿触摸系统perl.你不会后悔的.