Re: [RFC] Deprecate Backtick Operator (V2)
| From: | Claude Pache | Date: | Tue, 08 Oct 2019 10:21:35 +0000 |
| Subject: | Re: [RFC] Deprecate Backtick Operator (V2) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-107412@lists.php.net to get a copy of this message | ||
> Le 8 oct. 2019 à 11:44, Björn Larsson <bjorn.x.larsson@telia.com> a écrit :
>
> Den 2019-10-08 kl. 11:00, skrev Claude Pache:
>>> Le 8 oct. 2019 à 10:26, Björn Larsson <bjorn.x.larsson@telia.com> a écrit :
>>>
>>> Den 2019-10-06 kl. 15:41, skrev Mark Randall:
>>>> On 06/10/2019 14:18, Reinis Rozitis wrote:
>>>>> Since `` are used for literal strings (for poorly chosen reserved words as
>>>>> field, table names (which happens from time to time)) in MySQL (multiline) queries I doubt there is
>>>>> a simple way to distinguish and replace everything to exec().
>>>> Hi,
>>>>
>>>> As the RFC states, there are already widely used tools available which can do this
>>>> reliably:
>>>>
>>>> https://github.com/FriendsOfPHP/PHP-CS-Fixer
>>>> backtick_to_shell_exec
>>>>
>>>> --
>>>> Mark Randall
>>>>
>>> Even if there are good tools, there is a cost in doing the upgrade
>>> not just for doing the coding work, but also testing. Assume we
>>> have legacy code that works perfectly, so what is then the benefit
>>> to upgrade unless it goes in together with other features?
>>>
>>> Motivating to get a small budget to fix this in small company is
>>> not obvious. The purity of PHP won't fly I think ;-)
>>>
>>> r//Björn L
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>> When evaluating the _unique_ cost of migrating legacy code, it should be balanced with the
>> _continual_ cost of keeping the feature. That includes:
>>
>> * People wondering what that strange syntax does, or, worse, mistaking it with a variation
>> of string literal.
>> * Difficulty to search occurrences of
shell_exec.
>> * People trying to deactivate functions executing external programs (such as
>> shell_exec) using the "disable_function" ini directive,
>> wondering how to deactivate the backtick operator (since there is no
>> disable_operator directive).
>>
>> —Claude
>>
> That's a fair point. When it comes to the first two ones one
> might wonder how much pain these has caused historically,
> given that the feature has been around for a long time? Not
> sure how to get hard facts on it though.
>
> For the third one, one idea could be to extend the current
> directive also working for backticks or create a new one.
> Would that be an improvement?
>
> r//Björn L
The improvement for the third point is to have a proper directive that disables every functionality
relating to executing external programs on the machine, instead of letting people figuring out by
themselves the list of functions to be disabled. But we’re deviating from the subject. I was just
intending to give possible examples (not a comprehensive list), illustrating that there are also
costs for doing nothing.
—Claude