Setting up your shell startup files correctly

[jangid]

You should also set your environment variables so that they are available to both interactive and non-interactive shells. In practical terms, for most people this means setting them in ~/.profile, ~/.bash_profile, ~/.zshenv instead of ~/.bashrc and ~/.zshrc.

As per the bash documentation, ~/.bash_profile is for setting variables when you login (login-shell) and ~/.bashrc is for interactive use-cases (interactive-shell). Relevant bash info node.

Settings which are related to interactive use-cases like, auto-completion etc. should go into ~/.bashrc. Normally when you start a terminal it is an interactive non-login shell. MacOS is different. On MacOS every terminal-tab is treated as login shell. Some graphics terminals make arrangements to load login-shell variables. So when you start a cli terminal, it loads only ~/.bashrc becaue ~/.bash_profile vars are already available.

Similarly when you start programs like screen, they execute only ~/.bashrc because ~/.bash_profile vars are already available. I think emacs should also do it. It is an interactive shell and not a login shell.

In the above Bash Info node, it is documented that people typically write this in ~/.bash_profile,

if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

On macOS it is still a problem, everything is executed on each terminal tab. Which is kind of brute force. But this still saves some time for the non-login interactive programs like screen. This executes only ~/.bashrc. I set PS1, auto-completion etc. vars in this only. These are for interactive use cases. PATH etc. are inherited from the environment.

My recommendation is to remove that warning if people use both the files.

[purcell]

My recommendation is to remove that warning if people use both the files.

How would this be achieved? I don't want to get into actually inspecting the user's filesystem to guess what their shell might do.

[jangid]

My recommendation is to remove that warning if people use both the files. How would this be achieved? I don't want to get into actually inspecting the user's filesystem to guess what their shell might do.

I also don't want the package to inspect deeply. But I actually want to not put a warning for those who are doing it right - separating login and interactive-shell settings.

From the README:

In practical terms, for most people this means setting them in ~/.profile, ~/.bash_profile, ~/.zshenv instead of ~/.bashrc and ~/.zshrc. By default, exec-path-from-shell checks for this mistake

Actually, this is not a mistake. So let us just not check what the user has done and instead use the following approach:

(if (eq system-type 'darwin) (load-bash-profile) (load-bashrc))

MacOS users are used to this approach... the brute force approach. On other platforms load ~/.bashrc.

And may be put a link to that bash info page in README.

[purcell]

Why do you think we can load .bash_profile and .bashrc individually like that from the elisp code? We just invoke the shell.

[jangid]

Oh! I didn't read the code. Sorry about that.

Because you are warning about ~/.bashrc and asking to put everything in ~/.bash_profile, I thought you are loading individually. Hmm... back to square 0 then.

[purcell]

👍 The backstory to this is that people complained that exec-path-from-shell can be slow, and this is because interactive shells often do a lot of extra work that should be unnecessary in terms of setting environment variables. But equally, it's common for people to just set env vars in their shell's interactive startup files. So the purpose of the message is to warn people, and hopefully encourage them to set up their shell such that they can drop the -i from exec-path-from-shell-arguments.

Of course, it's not all as simple as that, and I'm not sure how well this has worked out over time, so I'm quite tempted to just scrap the above warning and instead detect when shell startup takes > 0.5 seconds (for example) and print a warning with a link to some suggestions...

[jangid]

👍 The backstory to this is that people complained that exec-path-from-shell can be slow, and this is because interactive shells often do a lot of extra work that should be unnecessary in terms of setting environment variables.

Exactly. That is the purpose of separating the concerns.

But equally, it's common for people to just set env vars in their shell's interactive startup files. So the purpose of the message is to warn people, and hopefully encourage them to set up their shell such that they can drop the -i from exec-path-from-shell-arguments.

Yes I referred to the code after your previous message.

Of course, it's not all as simple as that, and I'm not sure how well this has worked out over time, so I'm quite tempted to just scrap the above warning and instead detect when shell startup takes > 0.5 seconds (for example) and print a warning with a link to some suggestions...

This is intelligent. Looks like no other way without reading files. And that would be intrusive.

For now, may be we can just update the README and perhaps the warning message and put some kind of guidance on why there are separate startup files for login and interactivity.

[purcell]

I made the changes I proposed in master, and clarified the README there.

[jangid]

I made the changes I proposed in master, and clarified the README there.

Thanks a lot for your work. This is nice.

[ghost]

i wonder if this is why i can wait anywhere between 2-12 minutes waiting for a prompt to enter my gpg password upon starting emacs. something I haven't investigated yet and have just lived with for the time being due to workload, and the fact that usually my emacs is just up all the time.

[purcell]

i wonder if this is why i can wait anywhere between 2-12 minutes waiting for a prompt to enter my gpg password upon starting emacs. something I haven't investigated yet and have just lived with for the time being due to workload, and the fact that usually my emacs is just up all the time.

Maybe... perhaps remove -i and/or -l from exec-path-from-shell-arguments. Ideally any code in your startup files which prompts for a password would skip if there is no TTY.

[purcell]

Anyway, closing, since I implemented the changes discussed in the original issue.