4 ms·

Magic quotes were removed from PHP entirely back in v5.4… and we’re now on v8. It’s just as valid a language for shell scripts as any other.

• ironmagma 5y ago
  As indicated by “e.g.”, that was given as an example. There are countless other parameters that change the behavior of the language. If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.
  • donatj 5y ago
    > There are countless other parameters that change the behavior of the language. I call bologna. If you stick to built-in methods and avoid extensions, really the most breaking thing someone is going to do is turn off `allow_url_fopen` off, and you can either work around that or just complain to the user that you need it and `exit(1)`. > If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages. This is the most frustrating comment in this thread, imho. The _ideal_ is all code being distributed as readable source. Binaries are at best a sad compromise in the name of performance. Why would you _desire_ the code you run to be an impenitible black box? I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.
    • ironmagma 5y ago
      > the most breaking thing someone is going to do is turn `allow_url_fopen` off See [1]. "If PHP was compiled with --disable-url-fopen-wrapper, it won’t work." ... "But it will be printed if scream.enabled is set in php.ini." ... "exactly where it goes depends on display_errors, again in php.ini." There's so much variability in what an arbitrary PHP interpreter might or might not have support for, especially from 10 years ago. > I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary. Then why not ship the source, along with an interpreter binary to run it in isolation? This is one of Lua's main use cases. > Binaries are at best a sad compromise in the name of performance. I disagree with this at a fundamental level because of the fact that binaries are what can be used by a computer. Anything that runs, is ultimately a binary, even if parts of that binary are generated dynamically. By adding a dependency of the environment (system PHP), it adds a layer of magic and unknowns. [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
  • alerighi 5y ago
    > If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages. Why? It's more complicated, you need to compile different version for different operating systems and different architectures, if you have to update something you have to recompile it and typically to recompile it you have to install a development environment, versus opening the script and editing it.
    • ironmagma 5y ago
      Fair enough, good points. Really what I should have said is that if you're running on an untrusted system, it should be in an isolated environment (sandbox, container, etc.) which would preclude using a shared system binary. Statically linking your own executable would be another way to satisfy that constraint.
  • fomine3 5y ago
    Yes. "php.ini" is a pain to have for script language.
• phplovesong 5y ago
  > php.ini has entered the chat