subosito / gotenv Goto Github PK

When using override functions like OverLoad local variables do not override environment variables anymore, since #12.

Example 1

$ export A="fromEnv"
$ cat .env
A="fromFile"
B="$A"

Expected Behaviour

After using OverLoad, variable B should have value fromFile.

Actual Behaviour

Variable B has value fromEnv.

Example 2: Recursive variable expansion

$ export B="fromEnv"
$ cat .env
A="$B$C"
B="fromFile"
C="fnord"

What is the expected behaviour, when a reference is resolved before its definition? I would argue it should be fromEnv,
since gotenv evaluates environment files line by line.

Getting live environment variables that contain a $1 or $2 in a legitimate string is dropped from the variable

This combination can happen in a legitimate environment variable (like a password)

The line that causes the drop is here

Trying to understand why this would be getting dropped in this way.

I found the Usage section in instructions to be a bit unclear:

Store your configuration to .env file on your root directory of your project

This may not always be the case. As many go projects are made up of multiple executables.
In my specific scenario:
I have a rootdir and the subsequent directories rootdir/cmd/someWebService and rootdir/cmd/clock, where clock is a simple ticker for the web-service.

As I've come to understand after messing around with gotenv for a while, what it actually does is reading files in directories relative to the file taking use of gotenv.Load()

Coming back to my scenario, I have to specify a relative path in gotenv.Load(...) for each of my executables. This is honestly not actually a bad thing, as it allows for more flexibility in my go code and file/folder structure. The point I'm trying to make is rather this: The Usage instructions doesn't specify in a good manner where it reads from.

• Thank you

Hello,
it's compatible with workspace ?

Do you have any plans to support multiline ENV variables?
linePattern regex already supports it, but bufio.NewScanner(r) produces variable splitted by new line separator and makes it invalid before linePattern applied.

Just updated dependencies in one of our projects and noticed that builds are now failing on gotenv 1.5.0. This may be a problem with upstream packages but thought I would start here. The package throwing the error is spf13/viper

The following error appears during builds. The viper version did not change.

/go/pkg/mod/github.com/spf13/[email protected]/internal/encoding/dotenv/codec.go:51:33: cannot use &buf (value of type *bytes.Buffer) as gotenv.Reader value in argument to gotenv.StrictParse: *bytes.Buffer does not implement gotenv.Reader (missing method ReadAt)
failed to build, error: exit status 1

I'm trying to add a cert to .env file like this:
CERT: "-----BEGIN CERTIFICATE-----\nMIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLh==........”

but it doesn't works if there is equal sign = character in the value

Any suggestion?

The documentation for the StrictParse method is done incorrectly. The return values are swapped between the actual error and the map returned. It is currently documented as

err, pairs = gotenv.StrictParse(strings.NewReader(`FOO="bar"`))

which should have been below as per the function definition

pairs, err = gotenv.StrictParse(strings.NewReader(`FOO="bar"`))

The swapped order could be potentially confusing, but not a major one.

I have written a .env file via PowerShell, using echo "X=Z" >> file.env. This produces a UTF16 file with a little endian BOM byte encoded in UTF-16.

I will try to fix this with a PR.

Firstly, thank you for the library. It works beautifully!

The one thing I find missing is a reset option with this library. In testing I've found once the environment is set during testing it is impossible to reset the environment with the tool that modified it. I can write my own code for the testing but it would be nice to just call gotenv.Reset(). 👼

I wanted to be able to ignore missing .env file, because I sometimes directly load environment variable without using the .env file (docker, or else ...).

So I wonder whether this package is open to add such options or if you want to keep it simple stupid ? Meaning that I will have to check if the files exists myself before loading.

Therefore I'd like to propose a extra LoadWithOptions function that allows on to define options such as IgnoreMissingFiles.

When resolving variable references definitions in environment file take precedence over environment variables.

Example

$ export A="fromEnv"
$ cat .env
A="fromFile"
B="$A"

Expected behavior

After loading environment file, variable B should have value fromEnv.

Current behavior

After loading environment file, variable B has value fromFile

When reading the input buffer to parse the env, the returning method is ignoring any errors that might have occurred on the scanning process, if no line is read. We stumbled upon this while trying to read huge files that hit the scanner token limit, which was causing the scanner error ErrTooLong to be returned, thus failing to read the buffer.

https://github.com/subosito/gotenv/blob/master/gotenv.go#L211

Should check for the scanner result with scanner.Err() method before returning here