Add Linux FAQ: bash_profile vs bashrc

[weinand]

Testing microsoft/vscode#111422

I've added the sleep 4/11 to the .bashrc and I've verified that newly created Terminals (outside of VS Code) show the 4 or 11 second delay before the shell prompt shows up.

But when launching VS Code from the dock, I neither get a warning nor an error notification.

Opening a new Terminal within VS Code clearly shows the delay.

[bpasero]

@weinand I cannot reproduce. Can you confirm that launching VSCode from the dock is 4 or 11 seconds slower? If not, this would hint that we don't resolve the shell environment and thus no notification is shown. If that is the case, I wonder: are you running from a Snap installation or Deb package? And what distribution?

[weinand]

@bpasero

• Launching VS Code from the dock is not 4 or 11 seconds slower.
• I'm not using snap and I'm updating VS Code to the latest via the standard SW update mechanism.
• I'm using Ubuntu 20.04.

[bpasero]

I cannot understand this, we do have a --force-disable-user-env variable to forcefully disable this, but this is probably not being set when starting from the dock.

@joaomoreno need your advice here. Any clues why we would not resolve shell env when started from the dock?

Proof of what I see:

@weinand can you also try to see if VSCode stable shows the same behaviour of not being blocked for seconds even when you configure `.bashrc' like you do?

[weinand]

@bpasero the problem is the following:

I have ".bash_profile" in my home directory. Probably that got created by some ASP.NET installer (because it contains mono/.net related stuff).

It seems that applications started from the dock run "bash" in a way that first tries to load ".bash_profile" and only if that fails loads ".bashrc".

If I remove ".bash_profile" the shell run by VS Code uses ".bashrc" and VS Code's "slow shell resolve" errors and warnings work fine.

Since ".bash_profile" is an official mechanism, VS Code should probably handle it correctly.
An end-user workaround is to "source .bashrc" at the end of a ".bash_profile" (if there is one).

Related:
https://askubuntu.com/questions/161249/bashrc-not-executed-when-opening-new-terminal

Having a "~/.bash_login" might have a similar effect.

[joaomoreno]

We don't actually choose what to source, but simply follow bash's rules by spawning $SHELL -ilc. It's up to bash to do what it chooses.

By default ~/.bashrc is executed as part of ~/.bash_profile to load the alias function

In https://www.golinuxcloud.com/bashrc-vs-bash-profile/

It's strange that your .bash_profile misses that .bashrc invocation. Nothing to do here for us, I think.

[bpasero]

As I am not the author of resolveUnixShellEnv, leaving it up to Joao to decide to close or leave open.

[weinand]

IMO this is more a doc/FAQ item:

if a user has the problem that programs are not found on the PATH when launching from the dock (or in general: from the UI), but everything works fine when running from the command line, then the existence of a ".bash_profile" could be the reason.

The nasty thing about this problem is that it does not seem to surface in a lot of other places (other than VS Code). In terminals launched from the dock the ".bash_profile" is ignored and ".bashrc" is loaded correctly.

[joaomoreno]

if a user has the problem that programs are not found on the PATH when launching from the dock (or in general: from the UI), but everything works fine when running from the command line, then the existence of a ".bash_profile" could be the reason.

To be fair, I don't recall users having such an issue. And this is more a bash documentation rather than VS Code documentation... But yeah let's add it to the docs.

[gregvanl]

Closing old issue with out community upvotes.
I also tend to agree this is more for bash documentation. Not sure users would find it in the VS Code documentation.