From what I’ve understood, Apple has never been able to ship up-to-date versions of scripting languages because users and third-party vendors would rely on specific versions and if Apple updated the languages, it would break existing scripts. So now, they’ve decided that they’d rather not ship any scripting language runtime rather than be forced to ship obsolete and potentially insecure versions.
Here is an added consequence of this choice the just occurred to me - /usr/bin is a SIP protected directory. Which means even if you manually install perl/python/ruby yourself, you cannot install them in, or link them from /usr/bin and thus every single script you have that has #!/usr/bin/perl at the front of it breaks and has to be updated - Peter N Lewis.
Using '/usr/bin/env perl' instead gets around that and eats the one argument an interpreter directive is allowed.
Yes, #!/usr/bin/env perl works, but a) that executes a random perl that could vary from place to place (which is actually the exact opposite of the problem Apple claims is a problem, namely that it is stuck with an old version that never changes, and hence never breaks scripts!); and b) still means I have to change every existing script, of which I have hundreds.
My guess is it's about security. By bundling a specific version, without an easy way to update it outside of OS updates, Apple is becoming responsible for the security of those runtimes. And if they did have to get updated due to some significant vulnerability, Apple would have to get a way to push those updates out ASAP. I can certainly see the appeal of "if you want it, install it yourself... any version you want" from their standpoint.
Remarkbox