Ban env functions

[gmponos]

Break down #200 and started by the env functions.. also sort the functions to the ones that are alias and the ones that are bad practice to use.

[simPod]

Why is it a bad practice?

[gmponos]

Inside the xml I have a linked issue..

In short words these function are not thread safe and one thread can affect the other

[ostrolucky]

getenv() is the only way to access parent envs from within children process. It's not always possible to avoid using it.

[gmponos]

Hm.. interesting scenario..

Shouldn't environmental variables be set on the machine? Once they are set on the machine aren't they set for both processes?

So.. why parent/child processes should use env parameters to communicate with each other?

[ostrolucky]

It's not always set "on machine". FOO=bar php baz.php

[gmponos]

Hi.. I also have a code where I spawn children processes from a parent and I do this too

FOO=bar php baz.php

But I am passing FOO from the parent to the children during the spawn. The only reason I see that a child will want to read the FOO with getenv is because FOO might have changed.. which for me is a bad practice.

Still I think that this will cover 99% of the case.

Is your concern only for getenv and not about putenv? If so I will leave it here for a while.. maybe someone else has more feedback to provide.. and depending will remove it later.

[simPod]

Do we have an example where usage of getenv or putenv is actually required then? I'm confused by the discussion a little bit.

[Ocramius]

See doctrine/automatic-releases: only putenv() used there, but I agree that setenv() should be banned.

[gmponos]

I agree that setenv() should be banned.

@Ocramius you mean getenv ?

[Ocramius]

I edited the previous message 😅

The base branch was changed.

[greg0ire]

ping @gmponos do you plan on iterating on this? I'm trying to see what could ship in 9.0.0