This one is unforgivable. In at least FreeBSD 10.1-RELEASE, since at least 2015-05-13, whenever lang/perl was upgraded to 5.20, perl has been badly broken.
From /usr/ports/UPDATING:
That is bad enough, since everyone expects perl to be in /usr/bin, so everybody's shebang in perl scripts references /usr/bin/perl - but to make matters worse, the old symlink that used to be there is STILL THERE, left dangling, pointing to a binary that no longer exists. Mine was left pointing to /usr/local/bin/perl-5.18.4. As a result, you get bizarre behavior. In CGI scripts, you get completely bogus errors indicating that the script itself is missing.
I ran into this after "
I submit that:
1) It was a bad, pointless, and unnecessary mistake to suddenly remove the symlink. Everyone expects it to be there; everyone's portable scripts are written assuming it is there; and it has always been there. Leaving it there hurts nothing, but suddenly removing it has caused a lot of heartache and wasted time.
2) Even if the symlink was no longer to be maintained, for no reason that anyone could possibly support as rational, the least that could have been done would have been to remove the existing link, not leave it dangling, broken.
Before somebody tells me that portable scripts should say "/usr/bin/env perl", I've just been wound around the axle tracking down why that won't work in CGI scripts. The reason turns out to be that $PATH in the context of Apache's execution is only set to /sbin:/bin:/usr/sbin:/usr/bin - /usr/local/bin is not in there. And "/usr/bin/env PATH=/usr/bin:/usr/local/bin perl" absolutely will not work in a shebang line.
By the way, there is a similar problem with Python portable scripts, because there is no symlink for Python in /usr/bin.
From /usr/ports/UPDATING:
That is bad enough, since everyone expects perl to be in /usr/bin, so everybody's shebang in perl scripts references /usr/bin/perl - but to make matters worse, the old symlink that used to be there is STILL THERE, left dangling, pointing to a binary that no longer exists. Mine was left pointing to /usr/local/bin/perl-5.18.4. As a result, you get bizarre behavior. In CGI scripts, you get completely bogus errors indicating that the script itself is missing.
I ran into this after "
pkg update", but I'm sure it happens the same after a port upgrade.I submit that:
1) It was a bad, pointless, and unnecessary mistake to suddenly remove the symlink. Everyone expects it to be there; everyone's portable scripts are written assuming it is there; and it has always been there. Leaving it there hurts nothing, but suddenly removing it has caused a lot of heartache and wasted time.
2) Even if the symlink was no longer to be maintained, for no reason that anyone could possibly support as rational, the least that could have been done would have been to remove the existing link, not leave it dangling, broken.
Before somebody tells me that portable scripts should say "/usr/bin/env perl", I've just been wound around the axle tracking down why that won't work in CGI scripts. The reason turns out to be that $PATH in the context of Apache's execution is only set to /sbin:/bin:/usr/sbin:/usr/bin - /usr/local/bin is not in there. And "/usr/bin/env PATH=/usr/bin:/usr/local/bin perl" absolutely will not work in a shebang line.
By the way, there is a similar problem with Python portable scripts, because there is no symlink for Python in /usr/bin.
