Re: [RFC] Deprecate Backtick Operator (V2)

From: Date: Thu, 31 Oct 2019 14:59:46 +0000
Subject: Re: [RFC] Deprecate Backtick Operator (V2)
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-107742@lists.php.net to get a copy of this message
On Tue, Oct 8, 2019 at 6:02 AM Reinis Rozitis <r@roze.lv> wrote: > Not directly related to this RFC but out of curiosity - where does > this "doing the same thing in multiple ways is confusing" comes from? > (I mean this as serious question) > > I had the impression that programming in essence is all about that - > achieving/accomplishing something/the same different ways? Of course there will always be an infinite number of logical ways to structure a program, but this is quite different from having two different syntaxes in a language that do exactly the same thing. The latter is confusing since it's no longer clear which syntax should be used. The same situation existed with the curly brace array/string access syntax, which was deprecated in PHP 7.4. To share my own experience, when I first started needing to run shell commands in PHP and came across the backtick operator, I struggled to understand the difference between it and shell_exec, and which should be used in different circumstances. E.g. does the backtick operator automatically escape variables? Is it faster than shell_exec? It also caused me to assume that shell_exec must be preferred for some reason over exec and proc_open since there is a dedicated syntax for it. Ultimately it made the whole process of learning how to correctly run commands from PHP a lot more confusing than it should have been. I know I'm not the only one that has been confused by it. If you look at the PHP manual page for Execution Operators [1], the top voted comment (by far) is from someone who accidentally typed a backtick into their code and had a very difficult time debugging why their script didn't work as expected. As I see it, this syntax is not only confusing, but also dangerous. A programmer coming from JavaScript might think the backticks are simply storing a string, when in fact it will be executed as a command. Furthermore, the (undocumented) ability to include variables in the command can encourage terse but insecure scripts which fail to properly escape user-supplied arguments. Theodore [1]: https://www.php.net/manual/en/language.operators.execution.php

« previous php.internals (#107742) next »