Fixes #2065: Do not use pcntl_exec.

[greg-1-anderson]

@febbraro stopped by today and brought a system that evidenced #2065. We determined:

• The error messages appear after the call to pcntl_exec, but before the first line of the bash script they are executing.
• There is no performance difference between the two launch methods.

I was never happy with the workaround of forcing pcntl_exec to be unused by adding it to disabled_functions. Since this is a needless optimization, I figured the best solution is to just remove it.

This alteration is not applicable to the master branch, which has already removed the launcher.

[weitzman]

I'm a bit hesitant to do this in a stable branch. Am wary of breaking systems that are happily going through the pcntl code branch.

Can you say more about the affected system? Do we think its typical of many drush users? We have not seen much of this in the queue, though thats not always a great indicator.

[greg-1-anderson]

I don't think it will ever hurt anyone to go through the proc_open branch -- but of course I can't prove that in advance. ;) Because the operations that are happening are fairly simple, common and equivalent, it's my claim that this is a b/c-preserving change. All Windows users are already going through the proc_open branch.

Today, this problem is very rare because it does not happen on Mac or any of the older / Ubuntu systems that many people are using. Its cause, though, is security hardening in bash that is present in all newer versions of bash. This bug is therefore very commonly encountered by folks using Docker, as they are more inclined to be using a recent version O.S. It's hard to say exactly when this version of bash will make its way into some MacOS or Ubuntu, but when that happens, then everyone is going to want the proc_open branch, and no one is going to want pcntl_exec. (If my base assumption that proc_open is going to work well for everyone is wrong, then Drush 8 will have some serious problems when this happens. :> )

I don't know of a good way to detect that this change is necessary. A bad way would be to exec('bash --version') and check to see if the version is >= 4.4.5. I think it's simpler and cleaner to just get rid of it.

[greg-1-anderson]

Wow, this change breaks Unish\completeCase::testComplete. Not sure why that is. So much for the proc_open code path being equivalent to the pctl_exec code path. 👅

[greg-1-anderson]

I don't think I'm going to try to fix this. Maybe we should just leave this open in case someone who is really passionate about fixing #2065 can fix the failing unit test.

[weitzman]

Hah, OK. I'll admit you had me convinced in your explanation before the test fail.