Interesting, CY087. Your post explains a lot about how a default PATH variable is created. Not everything though.
there are three ways to make the PATH not have duplicates.
I. follow the boot up process and check all scripts that run at startup and see which ones add to the PATH variable and remove entries in them if they already exist. This through will most likely break everytime texstar update the scripts during normal updates.
2. have a script running as the last thing that run after you log in and have the script remove all duplicates.
3. have your own clean PATH set after the last script with the potential to add to PATH run and you will always have you own clean variable.
which one of these 3 do you want to attempt? The third one is the most easiest, just add your path in .bashrc file and you are set.
This thread sparked by interest, so I did go though idea 1. (It's the login process, though, not the boot process)
Of the system services in /etc/rc.d/init.d
at least /etc/rc.d/init.d/bootlogd
appears to create a PATH variable before login.
So the first thing to do is start a new clean session (easiest on a console) and get your raw PATH.
Mine is quite similar to Rudge's.
This is what I find
# The first three path components are set by login (see man login)
But where are they actually added to the PATH variable?
The file /etc/login.defs defines
for root andPATH=/bin:/usr/bin
for ordinary users,
but these two definitions don't seem to be used.
How do I know? I added two dummy directories to the definitions and they did not turn up in $PATH after login.
# Once account authorisation is completed, login then starts the shell
# specified in /etc/passwd for the user (or /bin/sh if no shell is specified)
# from man bash
# When bash is invoked as an interactive login shell, or as a non-inter‐
# active shell with the --login option, it first reads and executes com‐
# mands from the file /etc/profile, if that file exists. After reading
# that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
# in that order, and reads and executes commands from the first one that
# exists and is readable.
# Following added by /etc/profile (for any UID >= 500)
# /etc/profile also runs all ".sh" files in /etc/profile.d so we get
# the next two chunks
#following added by /etc/profile.d/60qt4.sh
# Following added by /etc/profile.d/kde4env.sh
And they are appended
to the variable. The strange thing about Rudges original $PATH in the other thread is that they seemed to be added twice: once before ~/.bash_profile
was read and once after.
Why would /etc/profile.d/kde4env.sh
be run twice, particularly as Rudge doesn't even run KDE?
Then some of the startup scripts for the desktop environments add entries to the $PATH. For instance /usr/bin/startkde prepends /bin
(or whatever echo "$0" | sed -n 's,^\(/.*\)/[^/][^/]*$,\1,p'
resolves into) to the path.
# Now we are back to the second part of the "man bash" excerpt above.
# Where it executes the first of the listed scripts in the users home dir.
# Following added by ~/.bash_profile
Did you add that yourself? On my default setups ~/.bash_profile
only appends $HOME/bin
to the PATH (where $HOME, of course stands for /home/<username>).
And if you redefine the whole PATH in ~/.bash_profile
I think it would make sense to let the bin
directories precede the sbin
ones, except of course in root's .bash_profile
(That is the end of my clean PATH)
So, some suggestions follow, with the caveat only if you know what you're doing!
1) ~/.bash_profile is entirely changeable for your own purposes. You can delete any duplicates there and/or add anything else you like. System updates will not affect this file.
2) ~/.bash_profile (and .bashrc and some others) are initially complied for a user when the account is created from the appropriate file in /etc/skel/. I'll go out on a thin and shakey limb here and state that the likelihood of the .bash_profile skeleton changing via a system update is very small. So if you create lots of user accounts it could be advantageous to check and investigate whether it would be appropriate to change the skeleton, otherwise leave it alone.
3) Both login and bash have some options that let you set how the various profile scripts are handled for a specific invocation. So you can "play" with these options in a virtual terminal and see how they work without breaking stuff. Hours of fun will ensue!
So, good work, CY087. When you find out more, let us know.