Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

  107406
October 8, 2019 08:26 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
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
  107409
October 8, 2019 09:00 claude.pache@gmail.com (Claude Pache)
> Le 8 oct. 2019 à 10:26, Björn Larsson 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
  107411
October 8, 2019 09:44 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-10-08 kl. 11:00, skrev Claude Pache:
>> Le 8 oct. 2019 à 10:26, Björn Larsson 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
  107412
October 8, 2019 10:21 claude.pache@gmail.com (Claude Pache)
> Le 8 oct. 2019 à 11:44, Björn Larsson larsson@telia.com> a écrit : > > Den 2019-10-08 kl. 11:00, skrev Claude Pache: >>> Le 8 oct. 2019 à 10:26, Björn Larsson 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
  107413
October 8, 2019 10:24 cmbecker69@gmx.de ("Christoph M. Becker")
On 08.10.2019 at 11:44, Björn Larsson wrote:

> Den 2019-10-08 kl. 11:00, skrev Claude Pache: > >> 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). > > 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?
<https://www.php.net/manual/en/language.operators.execution.php>: | The backtick operator is disabled when safe mode is enabled or | shell_exec() is disabled. -- Christoph M. Becker
  107414
October 8, 2019 10:36 bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)
Den 2019-10-08 kl. 12:24, skrev Christoph M. Becker:
> On 08.10.2019 at 11:44, Björn Larsson wrote: > >> Den 2019-10-08 kl. 11:00, skrev Claude Pache: >> >>> 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). >> 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? > <https://www.php.net/manual/en/language.operators.execution.php>: > > | The backtick operator is disabled when safe mode is enabled or > | shell_exec() is disabled. > Thanks, then the third point above is not valid I presume.
Cheers //Björn L
  107423
October 8, 2019 18:10 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> 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).
These are not costs, since "people wondering" does not cost anybody anything. People are free to wonder about anything, it's not a cost on existing users on PHP. If those people are interested in learning something, they'd read the manual and know. If they don't, they can keep wondering, it's not an argument for anything. -- Stas Malyshev smalyshev@gmail.com
  107427
October 8, 2019 18:25 chasepeeler@gmail.com (Chase Peeler)
On Tue, Oct 8, 2019 at 2:11 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi! > > > 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). > > These are not costs, since "people wondering" does not cost anybody > anything. People are free to wonder about anything, it's not a cost on > existing users on PHP. If those people are interested in learning > something, they'd read the manual and know. If they don't, they can keep > wondering, it's not an argument for anything. > > I was going to learn c++, but then I came across these weird operators >>
and <<. At first I thought they were heredoc, but, that obviously wasn't the case. My next guess is that they were some sort of strict comparison === is more strict than ==, so I figured >> is more strict than >. That wasn't the case either. After wondering for a while what it could be, I decided to look it up. It ends up that you use it to output text. cout << "Hello World"; It was SO confusing, because they also have printf which can be used to output text. I decided that c++ is obviously a garbage language and gave up. Not sure why anyone would ever use it!
> -- > Stas Malyshev > smalyshev@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  107429
October 8, 2019 18:48 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I was going to learn c++, but then I came across these weird operators >>> and <<. At first I thought they were heredoc, but, that obviously > wasn't the case. My next guess is that they were some sort of strict > comparison === is more strict than ==, so I figured >> is more strict > than >. That wasn't the case either. After wondering for a while what it > could be, I decided to look it up. It ends up that you use it to output > text. cout << "Hello World"; It was SO confusing, because they also have > printf which can be used to output text. I decided that c++ is obviously > a garbage language and gave up. Not sure why anyone would ever use it!
Actually since you can use fopen(stdout)+fwrite for outputting text, all other ways of outputting text should be deprecated too. Including printf, which is super-confusing with all its formats - why would I need any of that, and string interpolation too, when I could just compose a string out of bytes and fwrite it to the stdout? Very confusing. I am preparing an RFC right now to deprecate all functions that produce any output except fwrite. My next RFC will be about deprecating all database extensions because obviously fsockopen+fread+fwrite already covers them all. -- Stas Malyshev smalyshev@gmail.com
  107431
October 8, 2019 18:59 ocramius@gmail.com (Marco Pivetta)
On Tue, Oct 8, 2019, 20:48 Stanislav Malyshev <smalyshev@gmail.com> wrote:

> Hi! > > > I was going to learn c++, but then I came across these weird operators > >>> and <<. At first I thought they were heredoc, but, that obviously > > wasn't the case. My next guess is that they were some sort of strict > > comparison === is more strict than ==, so I figured >> is more strict > > than >. That wasn't the case either. After wondering for a while what it > > could be, I decided to look it up. It ends up that you use it to output > > text. cout << "Hello World"; It was SO confusing, because they also have > > printf which can be used to output text. I decided that c++ is obviously > > a garbage language and gave up. Not sure why anyone would ever use it! > > Actually since you can use fopen(stdout)+fwrite for outputting text, all > other ways of outputting text should be deprecated too. Including > printf, which is super-confusing with all its formats - why would I need > any of that, and string interpolation too, when I could just compose a > string out of bytes and fwrite it to the stdout? Very confusing. I am > preparing an RFC right now to deprecate all functions that produce any > output except fwrite. My next RFC will be about deprecating all database > extensions because obviously fsockopen+fread+fwrite already covers them > all. >
One is function (arguably routine) composition, the other is a custom syntax (operator?) that very much breaks the principle of least possible astonishment. It is normal that people get confused by different ways of doing the same thing, where those ways require non-homogeneous syntax and obscure features. The best results in code quality in the PHP OSS ecosystem over the past few years have been around limiting what the language can do (types, code styles that reduce the language feature-set), not widening it. Also, I would miss a backtick during a code review, and there would most certainly be trouble, and I do dozens of code review a day. I'd be astonished: funny.
>