Thursday, May 2, 2024
 Popular · Latest · Hot · Upcoming
16
rated 0 times [  16] [ 0]  / answers: 1 / hits: 13902  / 1 Year ago, thu, march 30, 2023, 10:35:42

These are the contents of the stock ~/.profile that came with my 13.10 (commented lines removed):



if [ -n "$BASH_VERSION" ]; then
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi

if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi


This is inherited from Debian but why did Canonical decide to keep it? As far as I know, it's not the standard *nix way and I have seen various systems where this did not happen, so I assume they must have had a good reason to. This can cause unexpected behavior when running login shells (such as when sshing into the machine for example) where the user would not expect to have ~/.bashrc sourced.



The only benefit I can think of is to not confuse the user with many startup files and allow them to edit .bashrc alone and have that read irrespective of shell type. That, however, is a dubious benefit since it is often useful to have different settings for login and for interactive shells and this blocks you from doing so. Also, login shells are very often not run in a graphical environment and that can cause errors and warnings and problems (oh my!) depending on what you've set in those files.



So why does Ubuntu do this, what am I missing?


More From » bash

 Answers
3

This is an upstream decision coming from Debian. The rationale for it is explained in this very nice wiki post, of which the following is an excerpt. The executive summary is "to ensure that GUI and non GUI logins work in the same way":




Let's take xdm as an example. pierre comes back from vacation one day and discovers that his system administrator has installed xdm on the Debian system. He logs in just fine, and xdm reads his .xsession file and runs fluxbox. Everything seems to be OK until he gets an error message in the wrong locale! Since he overrides the LANG variable in his .bash_profile, and since xdm never reads .bash_profile, his LANG variable is now set to en_US instead of fr_CA.



Now, the naive solution to this problem is that instead of launching "xterm", he could configure his window manager to launch "xterm -ls". This flag tells xterm that instead of launching a normal shell, it should launch a login shell. Under this setup, xterm spawns /bin/bash but it puts "-/bin/bash" (or maybe "-bash") in the argument vector, so bash acts like a login shell. This means that every time he opens up a new xterm, it will read /etc/profile and .bash_profile (built-in bash behavior), and then .bashrc (because .bash_profile says to do that). This may seem to work fine at first -- his dot files aren't heavy, so he doesn't even notice the delay -- but there's a more subtle problem. He also launches a web browser directly from his fluxbox menu, and the web browser inherits the LANG variable from fluxbox, which is now set to the wrong locale. So while his xterms may be fine, and anything launched from his xterms may be fine, his web browser is still giving him pages in the wrong locale.



So, what's the best solution to this problem? There really isn't a universal one. A better approach is to modify the .xsession file to look something like this:



[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox


This causes the shell that's interpreting the .xsession script to read in /etc/profile and .bash_profile if they exist and are readable, before running xmodmap or xterm or "execing" the window manager. However, there's one potential drawback to this approach: under xdm, the shell that reads .xsession runs without a controlling terminal. If either /etc/profile or .bash_profile uses any commands that assume the presence of a terminal (such as "fortune" or "stty"), those commands may fail. This is the primary reason why xdm doesn't read those files by default. If you're going to use this approach, you must make sure that all of the commands in your "dot files" are safe to run when there's no terminal.



[#26583] Friday, March 31, 2023, 1 Year  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
chilgirlguid

Total Points: 123
Total Questions: 114
Total Answers: 121

Location: Macau
Member since Mon, Nov 16, 2020
4 Years ago
;