php manual: function putenv()

The environment variable will only exist for the duration of the current request.

    public function setEnvironmentVariable($name, $value = null)
    {
        list($name, $value) = $this->normaliseEnvironmentVariable($name, $value);

        // Don't overwrite existing environment variables if we're immutable
        // Ruby's dotenv does this with `ENV[key] ||= value`.
        if ($this->immutable && $this->getEnvironmentVariable($name) !== null) {
            return;
        }

        // If PHP is running as an Apache module and an existing
        // Apache environment variable exists, overwrite it
        if (function_exists('apache_getenv') && function_exists('apache_setenv') && apache_getenv($name)) {
            apache_setenv($name, $value);
        }

        if (function_exists('putenv')) {
            putenv("$name=$value");
        }

        $_ENV[$name] = $value;
        $_SERVER[$name] = $value;
    }

    public function getEnvironmentVariable($name)
    {
        switch (true) {
            case array_key_exists($name, $_ENV):
                return $_ENV[$name];
            case array_key_exists($name, $_SERVER):
                return $_SERVER[$name];
            default:
                $value = getenv($name);//****notice line****
                return $value === false ? null : $value; 
        }
    }

When one request was running, the other request would get this one's env(getenv);

we can use overload() instead of load() to circumvent this problem;

This is just a suggestion;

I think it would be a good idea to change the Dotenv::load method so that it wouldn't throw an exception. The motivation for this is that not all environments use a .env file, for example when we deploy to Amazon we configure the environmental variables through OpsWorks. What this means in practice is that I need an additional check in application to see if the file actually exists before calling Dotenv::load. What do you think?

In my .env file I have values like:

APP_DEBUG=true
APP_DEV=false

But the type of these values is always string:

var_dump(getenv('APP_DEBUG')); // string(4) "true"
var_dump(getenv('APP_DEV')); // string(5) "false"

I think the values like true, false, null (or even numbers), without quotes, should be converted to the correct type (boolean, integers, etc), because in cases like this, APP_DEV returns "false" so it's evaluated as true:

if (getenv('APP_DEV')) {
    // do something
}

As mentioned in #43 I've tried a few different things:

1. PSR-4 and PSR-2
2. namespaced to Dotenv with main public API in Dotenv\Dotenv
3. Broken functionality into smaller distinct classes with single responsibility
4. Changed immutability, making it a little less clunky, so now we have load = immutable and overload = mutable. I know you didn't want to copy the ruby dotenv @vlucas but I felt this was pretty elegant.
5. Parsing of variables now done with a series of filters. To extend parsing as in #40 the Dotenv\Dotenv class can be extended and a new filter added to the parser. Or indeed a different parser.
6. I also added a help dotenv() function in order to simplify instantiation, e.g. dotenv()->load(…) as an experiement.
7. haven't yet implemented a static factory as requested by @bcremer in #43

Comments please.

Added ability to handle multiple files in the situations where there's need for more than one file to be loaded and variables to be merged / overwritten in the order of the loaded paths.

Also added Dotenv::read() method, which reads variables without setting them up - useful in the situations where you have to overwrite certain configuration at runtime without changing the environment.

One use case for these changes is the multi tenancy application where .env files for each tenant are stored in separate directory and only contain variables that should overwrite the ones set up in the main .env file.

Hello! Thanks for your library - it's very helpful.

I recently came across a confusing situation, where I had inadvertently set the same variable twice in a .env file with different values (as part of a Laravel deployment).

Example:

APP_DEBUG=false
....
APP_DEBUG=true

Results in APP_DEBUG=false after loading.

I totally realize that it's my responsibility to ensure that I'm not setting these twice, however I was surprised that there wasn't something that would either warn me about a duplicate, or use the last-set value, since it was set later?

Is this something that should be handled in the library? I couldn't find an associated test that expresses this concept.

Hi to all!

Before the last updating the next variable was working correctly: VARIABLE="Text with\nsome end of lines\n" and in the php when i wrote the next code: echo env('VARIABLE'); returns: Text with\nsome end of lines\n

After the last update the variable returns: `` <- empty string

…brary is loaded

I have a WordPress application where I am going to need to specifically install this library in a separate directory and include it earlier than it would if it were in my default vendor directory. I'm already using the vendor directory in a separate location (mu-plugins with the composer autoloader) which runs much later than I need the dotenv code to run.

This shouldn't impact anything in your app.

First off -

Thanks everyone (especially @kelvinj) for all the hard work on v2 so far. I just updated the README file for it, as well as made some naming changes to the assertion methods to make them read better. Check the code and/or the README file to see what I mean.

My concerns before the release: Now that we have alternate PHP and JSON loaders, I would like to change the variable nesting to match the bash-style syntax instead of the current PHP-style syntax. I would also like to remove support for spaced values that are not quoted.

The primary motivation for these changes is that I think if you use the bash-style syntax, there shouldn't be any features of phpdotenv that will break bash evaluation of the .env file.

For instance, pull down the latest v2 branch and run:

source tests/fixtures/env/nested.env && echo $NVAR4

Then run:

source tests/fixtures/env/nested.env && echo $NVAR3

And:

source tests/fixtures/env/commented.env

I also had to switch the example to double quotes instead of single quotes for the bash variable interpolation to work - the same thing that happens in PHP too. Perhaps we should also require double quotes? Is that going too far?

I use {"vlucas/phpdotenv": "^4.0.1"}

Now:

public static function Dotenv::create(Repository\RepositoryInterface $repository, $paths, $file = null) Dotenv

not compatible with old call:

Dotenv::create(__DIR__, '_env')

Dotenv::createImmutable( dirname(__DIR__, 1) . '/configs/' ,
        [
            'global', 'credentials', 'options'
        ])->load();

reports:

Unable to read any of the environment file(s) at [/var/www/project/configs/Array]

I'm forced now to revert depencecy to phpdotenv 3.3 and can't use new functionality.

Please, don't break compatibility!

Fatal error: Uncaught Dotenv\Exception\InvalidPathException: Unable to read any of the environment file(s) at [C:\xampp\htdocs\homework\public.env]. in C:\xampp\htdocs\homework\vendor\vlucas\phpdotenv\src\Loader.php:133 Stack trace: #0 C:\xampp\htdocs\homework\vendor\vlucas\phpdotenv\src\Loader.php(91): Dotenv\Loader::findAndRead(Array) #1 C:\xampp\htdocs\homework\vendor\vlucas\phpdotenv\src\Dotenv.php(123): Dotenv\Loader->load() #2 C:\xampp\htdocs\homework\vendor\vlucas\phpdotenv\src\Dotenv.php(80): Dotenv\Dotenv->loadData() #3 C:\xampp\htdocs\homework\public\index.php(8): Dotenv\Dotenv->load() #4 {main} thrown in C:\xampp\htdocs\homework\vendor\vlucas\phpdotenv\src\Loader.php on line 133

Summary

If .env references a variable (e.g. ${FOO}) which is not already set (either via the external environment, or in the .env file, it is left unexpanded.

This is in contrast to the following other languages / implementations which will expand the variable to an empty string:

• Bash (source)
• Python: python-dotenv

Demo

Consider this .env file:

# A simple, constant env var
CONST='A constant env var'

# Derived from another variable
DERIV="I came from ${CONST} with some more"

# An environment variable we expect to be set on the outside
EXT_SET=${ENV_EXT_SET}

# An environment variable we expect *not* to be set on the outside
EXT_UNSET=${ENV_EXT_UNSET}

When loaded by bash, EXT_UNSET will get the value "" (that is, the empty string).

When loaded by phpdotenv v5.2.0, EXT_UNSET will get the value "${ENV_EXT_UNSET}" (literally).

See this gist for a full reproducible example:

$ pip3 install scuba
$ ./prepare.sh
$ ./run_test.sh
------------------------------------------------------
Bash:
CONST=A constant env var
DERIV=I came from A constant env var with some more
EXT_SET=set externally
EXT_UNSET=

------------------------------------------------------
phpdotenv:
$_ENV = Array
(
    [CONST] => A constant env var
    [DERIV] => I came from A constant env var with some more
    [EXT_SET] => set externally
    [EXT_UNSET] => ${ENV_EXT_UNSET}
)

------------------------------------------------------
python-dotenv:
CONST=A constant env var
DERIV=I came from A constant env var with some more
EXT_SET=set externally
EXT_UNSET=

References

• Upstream issue: https://github.com/snipe/snipe-it/issues/6578