Live data from Hacker News

Bash Configurations Demystified

dghubble.com

21–22 of 22 posts

Re: Bash Configurations Demystified

#21
post #15

> the scary console login after you've messed up your GUI settings That's where I stopped reading... BASH isn't that mysterious. man bash

I think many Linux users have hacked around and messed up settings. This line was meant for those who have been in that situation, to say "hey btw, that screen was a login shell" (even took a picture of it). Just adds a little context, it doesn't resonate with everyone.

I think booting to a console when you expect a desktop can be scary, especially if you don't know how to undo whatever you did.

Re: Bash Configurations Demystified

#22

> As the name implies, .bashrc is for bash configs. Environment variables or other configuration settings should typically be written to .profile on Ubuntu and .bash_profile on OS X. I don't understand this. If I set PATH in .profile or .bash_profile, then on Ubuntu I won't see that setting when I log in via a non-login shell. This is common for non-interactive SSH sessions. So consider the following example: * I ins…

~/.profile is executed only at login on Ubuntu so changing your PATH there will be applied the next time you login. You can source the ~/.profile in your current non-login shell if you need the PATH change right now. I've tried to tweak the second paragraph in the "When not to modify .bashrc?" section to make this more clear. Thanks for bringing this up.

The problem is that running an MPI program on a remote node starts a new non-interactive SSH session. That SSH session has no parent login session, so it won't inherit environment variables from any session that read the .profile file. And because the SSH login is non-interactive, the only file that the shell inside the SSH session reads is .bashrc.

Sure, you could source .profile manually, but this is awkward to code inside an MPI application. In addition, this will cause .bashrc to get sourced twice, because your shell already read .bashrc when it started the SSH session. Hopefully your .bashrc is idempotent, but even so, it feels wrong to have to read .bashrc twice.

Try this on a remote server:

    remote:~$ cat .profile
    echo "read .profile"

    echo "sourcing .bashrc from .profile"
    source ~/.bashrc
    remote:~$ cat .bashrc
    echo "read .bashrc"
And then from your local machine:

    local:~$ ssh remote
    read .profile
    sourcing .bashrc from .profile
    read .bashrc
    local:~$ ssh remote -k true
    read .bashrc
Post reply on HN