home-manager icon indicating copy to clipboard operation
home-manager copied to clipboard

bug: `home.sessionVariables` and `bash.sessionVariables` end up serving the same purpose: `.profile`

Open giggio opened this issue 1 year ago • 2 comments

Are you following the right branch?

  • [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

  • [X] I have searched the existing issues

Issue description

When you set home.sessionVariables the variables go into hm-session-vars.sh, which is loaded by .profile. When you set bash.sessionVariables the variables go directly into .profile, serving the same purpose as home.sessionVariables.

With that, we're left missing a way to set variables in .bashrc, or bash session variables. One would have to script them directly.

bash.sessionVariables should not go directly into .profile, but into .bashrc.

This line should be moved a few lines bellow (into home.file.".bashrc".source ):

https://github.com/nix-community/home-manager/blob/0eb314b4f0ba337e88123e0b1e57ef58346aafd9/modules/programs/bash.nix#L215

Maintainer CC

@rycee

System information

this path will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/y11cs26gb9b1irv5hk776mra7hgy80bl-nix-info
copying path '/nix/store/y11cs26gb9b1irv5hk776mra7hgy80bl-nix-info' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 6.8.0-31-generic, Ubuntu, 24.04 LTS (Noble Numbat), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.22.0`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/home/giggio/.nix-defexpr/channels/nixpkgs`

giggio avatar Jun 01 '24 06:06 giggio

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

  • If this is resolved, please consider closing it so that the maintainers know not to focus on this.
  • If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
If you are not the original author of the issue

  • If you are also experiencing this issue, please add details of your situation to help with the debugging process.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

stale[bot] avatar Sep 28 '24 05:09 stale[bot]

Not stale, still relevant.

giggio avatar Oct 02 '24 15:10 giggio

I've just commented here https://github.com/nix-community/home-manager/issues/1011#issuecomment-3158249507

The relevant part of the comment for this issue is:

programs.bash.sessionVariables are written to ~/.profile. They should be written to ~/.bash_profile, to only be set for bash.

In the same way that home.sessionVariables aren't set for Wayland shells, programs.bash.sessionVariables aren't either, since ~/.bash_profile is only loaded in login shells.

This is a fix for loading programs.bash.sessionVariables for bash interactive shells:

let
  bashSessionVars = "${config.home.homeDirectory}/.bash_profile";
in
{
    programs.bash.initExtra = ''
        [[ -f "${bashSessionVars}" ]] && source "${bashSessionVars}"
    '';
}

Replace initExtra by bashrcExtra to load home.sessionVariables in all (interactive and non-interactive) shells.

landure avatar Aug 06 '25 08:08 landure

This is a fix for loading programs.bash.sessionVariables for bash interactive shells:

let
  bashSessionVars = "${config.home.homeDirectory}/.bash_profile";
in
{
    programs.bash.initExtra = ''
        [[ -f "${bashSessionVars}" ]] && source "${bashSessionVars}"
    '';
}

there is one caveat to this solution. What this snippet does is to source .bash_profile in a interactive shell by writing it into .bashrc, but it's suggested by Bash's manual and very common to see .bash_profile to source .bashrc.

see https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html#Invoked-as-an-interactive-non_002dlogin-shell

lebensterben avatar Aug 07 '25 21:08 lebensterben

Thank you, so, the answer would be to:

  1. write programs.bash.sessionVariables to .bashrc, using the same logic as programs.bash.initExtra.
  2. add if [ -f ~/.bashrc ]; then . ~/.bashrc; fi to .bash_profile.

landure avatar Aug 08 '25 03:08 landure

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

  • If this is resolved, please consider closing it so that the maintainers know not to focus on this.
  • If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
If you are not the original author of the issue

  • If you are also experiencing this issue, please add details of your situation to help with the debugging process.
  • If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

stale[bot] avatar Nov 07 '25 05:11 stale[bot]