Do not update user's dotfiles

[felipecrs]

In the scripts from script's library, often we see the function updaterc updating the user's dotfiles such as ~/.bashrc. I think we should never do that since those files will be later replaced in case the user has a dotfiles repository configured.

So I have two suggestions:

First

Instead, perform these changes to the global bashrc and zshrc files, which are respectively /etc/bash.bashrc and /etc/zsh/zshrc. Those files gets sourced by bash and zsh automatically, for all the users.

This means that for free, we would earn synchronization between root and non-root user without having to update both user's dotfiles.

Second

Update /etc/bash.bashrc and /etc/zsh/zshrc to include something like . /etc/profile, because unfortunately, in Docker, /etc/profile does not get read automatically.

Then, if you take a look at /etc/profile you'll see something like:

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

This means that any .sh under /etc/profile.d/ will get sourced by /etc/profile, and this is the recommended way to customize the system-wide Linux environment.

Then, we could convert lines such as:

echo "export SDKMAN_DIR=${SDKMAN_DIR}\nsource \${SDKMAN_DIR}/bin/sdkman-init.sh" >> /home/vscode/.bashrc
echo "export SDKMAN_DIR=${SDKMAN_DIR}\nsource \${SDKMAN_DIR}/bin/sdkman-init.sh" >> /home/vscode/.zshrc
# for root
echo "export SDKMAN_DIR=${SDKMAN_DIR}\nsource \${SDKMAN_DIR}/bin/sdkman-init.sh" >> /root/.bashrc
echo "export SDKMAN_DIR=${SDKMAN_DIR}\nsource \${SDKMAN_DIR}/bin/sdkman-init.sh" >> /root/.zshrc

with:

echo "export SDKMAN_DIR=${SDKMAN_DIR}\nsource \${SDKMAN_DIR}/bin/sdkman-init.sh" >> /etc/profile.d/sdkman.sh

Which has the benefits:

1. Works for all users (root and non-root)
2. Works for bash and zsh
3. Much safer than editing the rc directly

[felipecrs]

Latest news about this:

This indeed solves the dotfiles overlapping (which means it already worths it) but does not make the container have such variables globally, which causes the VS Code to not find python's binaries in PATH.

There are two ways to solve this:

1. Add the env variables in the Dockerfile using ENV.

   • Downsides:
     • The scripts under script-library would not work just by calling it. All the users must remember to add the right ENVs in their Dockerfiles.
     • Limited to the Dockerfile syntax for defining env variables
   • Advantages:
     • Whoever tries to execute a command in the dev container by using docker exec (without sh -l would get those variables set as well. But who would do such a thing?

2. Make VS Code Remote - Containers extension ALWAYS use sh -l -c and not only sh -c when executing commands inside of the container.

   • Downsides:
     • People using the container outside of VSCode would need to remember to execute the commands using sh -l -c, or they won't have the environment in sync. Again, who would do such a thing?
   • Advantages:
     • We make the scripts under script-library 100% reusable, without people having to inject other code in their Dockerfiles;
     • We get more control of the ENV by taking care of the environment by ourselves and not asking someone else to do.
     • We have the freedom to use .sh files to customize the environment, so not limited to the Dockerfile syntax.
     • We will be using standard Linux customization techniques (/etc/profile.d) rather than any hacky method.
     • We don't need to inject . /etc/profile in /etc/bash.bashrc or /etc/zsh/zshrc.

I believe number 2 is the way forward to solve this at once.

[felipecrs]

Opened an Issue for bullet number 2 above in the right repository: microsoft/vscode-remote-release#3593.

[Chuxel]

Unfortunatley profile.d is only used in login shells, so rc files are a better option. Even if the host process is a login, there's no garuntee sub-processes forked by extensions are. PR #529 uses /etc/bash.bashrc and /etc/zsh/zshrc

Many of these things need to be "sourced" (rvm, nvm, SDKMAN!) so they cannot always be added using ENV. When they can, they are, but the script itself can't do that, so it focuses on RC files instead.

I'd say with this update this problem is as resolved as we'll be able to get it.

[felipecrs]

Awesome @Chuxel, I believe the issue with the user's dotfiles is sorted out. Tested here, and it works as expected. 👍🏻

But about:

Even if the host process is a login, there's no garuntee sub-processes forked by extensions are.

That's why I opened microsoft/vscode-remote-release#3593.