Skip to content

Fix environment variable handling when running executables #10827

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 21, 2025

Conversation

mpickering
Copy link
Collaborator

@mpickering mpickering commented Mar 10, 2025

This fixes a bug where environment variables were duplicated when running executables.

overrideEnv <- fromMaybe [] <$> getEffectiveEnvironment ([("PATH", Just newPath)] ++ envOverrides)
let shellEnv = overrideEnv ++ existingEnv

Since getEffectiveEnvironment already calls getEnvironment internally, if any overrides
are passed then the result is a complete environment. Appending it to
the already existing environment results in duplicated environment variables.

The fix:

  • Added getFullEnvironment function to handle the common pattern correctly
  • Updated code in Bench, Test/ExeV10, Test/LibV09, and Client/Run to use this function

In the future it would be good to generalise getFullEnvironment
further so it can also handle the addLibraryPath case, which modifies
an environment variable, rather than merely setting or unsetting it.

Fixes #10718.


Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:


Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

  • Patches conform to the coding conventions.
  • Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

@mpickering mpickering force-pushed the wip/duplicate-env-vars branch from b9f0466 to 5a21af6 Compare March 10, 2025 15:27
@mpickering mpickering requested a review from sheaf March 10, 2025 15:27
Copy link
Collaborator

@sheaf sheaf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks for doing this.

@mpickering mpickering force-pushed the wip/duplicate-env-vars branch 3 times, most recently from 30abd04 to 31a5c4d Compare March 14, 2025 14:58
@Mikolaj
Copy link
Member

Mikolaj commented Mar 17, 2025

Let me take the liberty of assuming this is ready for review and marking it so.

@ulysses4ever
Copy link
Collaborator

We badly need the second review for this one.

Copy link
Collaborator

@ulysses4ever ulysses4ever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, and a special thank you for the test.

@mpickering mpickering force-pushed the wip/duplicate-env-vars branch from 31a5c4d to aec71cc Compare March 19, 2025 14:04
@mpickering mpickering added the merge me Tell Mergify Bot to merge label Mar 19, 2025
@mergify mergify bot added ready and waiting Mergify is waiting out the cooldown period merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days labels Mar 19, 2025
This fixes a bug where environment variables were duplicated when running executables.

```
overrideEnv <- fromMaybe [] <$> getEffectiveEnvironment ([("PATH", Just newPath)] ++ envOverrides)
let shellEnv = overrideEnv ++ existingEnv
```

Since getEffectiveEnvironment already calls getEnvironment internally, if any overrides
are passed then the result is a complete environment. Appending it to
the already existing environment results in duplicated environment variables.

The fix:
* Added getFullEnvironment function to handle the common pattern correctly
* Updated code in Bench, Test/ExeV10, Test/LibV09, and Client/Run to use this function

In the future it would be good to generalise `getFullEnvironment`
further so it can also handle the `addLibraryPath` case, which modifies
an environment variable, rather than merely setting or unsetting it.

Fixes #10718
Adds a simple test case that identifies and reports duplicate
environment variables in the Cabal environment.

For issue (#10718)
@Mikolaj Mikolaj force-pushed the wip/duplicate-env-vars branch from aec71cc to 6e54b23 Compare March 21, 2025 14:16
@mergify mergify bot merged commit 705eaab into master Mar 21, 2025
47 checks passed
@mergify mergify bot deleted the wip/duplicate-env-vars branch March 21, 2025 14:26
@Mikolaj
Copy link
Member

Mikolaj commented Mar 25, 2025

Am I right this should be backported to 3.14? Let me set the label tentatively.

@Mikolaj
Copy link
Member

Mikolaj commented Mar 31, 2025

@mergify backport 3.14

Copy link
Contributor

mergify bot commented Mar 31, 2025

backport 3.14

✅ Backports have been created

mergify bot added a commit that referenced this pull request Mar 31, 2025
…tables (#10887)

* Fix environment variable handling when running executables

This fixes a bug where environment variables were duplicated when running executables.

```
overrideEnv <- fromMaybe [] <$> getEffectiveEnvironment ([("PATH", Just newPath)] ++ envOverrides)
let shellEnv = overrideEnv ++ existingEnv
```

Since getEffectiveEnvironment already calls getEnvironment internally, if any overrides
are passed then the result is a complete environment. Appending it to
the already existing environment results in duplicated environment variables.

The fix:
* Added getFullEnvironment function to handle the common pattern correctly
* Updated code in Bench, Test/ExeV10, Test/LibV09, and Client/Run to use this function

In the future it would be good to generalise `getFullEnvironment`
further so it can also handle the `addLibraryPath` case, which modifies
an environment variable, rather than merely setting or unsetting it.

Fixes #10718

(cherry picked from commit 4375dd5)

* Add test for duplicate environment variables when invoking testsuite

Adds a simple test case that identifies and reports duplicate
environment variables in the Cabal environment.

For issue (#10718)

(cherry picked from commit 6e54b23)

---------

Co-authored-by: Matthew Pickering <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
attention: needs-review merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days merge me Tell Mergify Bot to merge ready and waiting Mergify is waiting out the cooldown period regression in 3.14
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cabal 3.14.1.0 invokes test binaries with a corrupt (duplicated) environment variable list
4 participants