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

  107417
October 8, 2019 12:24 claude.pache@gmail.com (Claude Pache)
> Le 8 oct. 2019 à 12:24, Reindl Harald (privat) <harry@rhsoft.net> a écrit : > > > > Am 08.10.19 um 11:00 schrieb Claude Pache: >> * 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) > > would you at least mind to back your claims by a simple test? > > Warning: shell_exec() has been disabled for security reasons in > /mnt/data/www/www.rhsoft.net/test.php on line 1 > > [harry@srv-rhsoft:/www/www.rhsoft.net]$ cat test.php >
Hi, I think you missed my point. I wasn’t claiming that there is any technical difficulty in disabling the backtick operator. I am claiming that people take time wondering how to do that, searching for the solution, and discovering that they just need to disable `shell_exec`. More generally, people take time in understanding the peculiarities of that uncommon feature which is the backtick operator. This is a real cost. Another example that is popping in my mind is: Does the operator supports variable interpolation (like double-quoted strings) or not (like single-quoted strings). (Please, don’t lose time in answering that question. The simple answer is: Just use `shell_exec()` with the type of quotes you mean, and: Tell everybody to just use `shell_exec()` with the type of quotes they mean.) —Claude
  107418
October 8, 2019 13:59 mo.mu.wss@gmail.com ("M. W. Moe")
Hello,

would say intellectually speaking I could accept the argument of
time\investment\code however
in reality figuring out for someone having a minimum of shell experience in
that case, would figure
out in 5 minutes if he is very slow minded;  none the less,  learning new
features, new apis, that's
the life of a software developer; once again there is a discussion about a
mosquito with very strong
arguments made about hypothetical difficulties.

There are far more complex  and mind challenging  topics which are
disregard; which would ask thoughts
on the long term; in profit of minor issues thrown into the arena with no
more than a 5 minutes thinking.

Regards.

On Tue, Oct 8, 2019 at 5:24 AM Claude Pache pache@gmail.com> wrote:

> > > > Le 8 oct. 2019 à 12:24, Reindl Harald (privat) <harry@rhsoft.net> a > écrit : > > > > > > > > Am 08.10.19 um 11:00 schrieb Claude Pache: > >> * 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) > > > > would you at least mind to back your claims by a simple test? > > > > Warning: shell_exec() has been disabled for security reasons in > > /mnt/data/www/www.rhsoft.net/test.php on line 1 > > > > [harry@srv-rhsoft:/www/www.rhsoft.net]$ cat test.php > > > > Hi, > > I think you missed my point. I wasn’t claiming that there is any technical > difficulty in disabling the backtick operator. I am claiming that people > take time wondering how to do that, searching for the solution, and > discovering that they just need to disable `shell_exec`. > > More generally, people take time in understanding the peculiarities of > that uncommon feature which is the backtick operator. This is a real cost.. > Another example that is popping in my mind is: Does the operator supports > variable interpolation (like double-quoted strings) or not (like > single-quoted strings). (Please, don’t lose time in answering that > question. The simple answer is: Just use `shell_exec()` with the type of > quotes you mean, and: Tell everybody to just use `shell_exec()` with the > type of quotes they mean.) > > —Claude > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107434
October 8, 2019 20:23 mike@newclarity.net (Mike Schinkel)
> More generally, people take time in understanding the peculiarities of that uncommon feature which is the backtick operator. This is a real cost.
Is this a generally agreed-principle that the PHP community believes is important? If so, shouldn't we quantify what the cost is and who would bear that cost, and then compare it with a quantified cost to be born by the people whose working scripts would break? Also if so, should we then not also consider other peculiarities that cause people to take time understanding/dealing with? A really good example would be the difference in needle and haystack order for parameters passed to array-related functions. Certainly far more time is spent dealing with those peculiarities than time is lost related to the backtick operator? So if we as a community agree that time spent understanding peculiarities is a solid justification for an RFC to be accepted, then it seems to me the PHP can support a large number of RFCs given all of its different peculiarities, no? -Mike P.S. I can go either way given the above on both topics. But having an agreed-upon principle — or not — would really streamline debate.