$PATH.. Mantinance Required? [Solved]

[Rudge]

Hi all.

In a different thread located Here >http://www.pclinuxos.com/forum/index.php/topic,98600.0.html

The notion that a user's $PATH (specifically, mine) might not be optimum due to how software adds directories to it.

My question, (2 parts) - Should I perform some cleanup of my $PATH? and, How would I perform such cleanup?

(I think I can figure out what cleanup to perform, aka removing duplicates and ordering things in a logical way)

I am running an "old" 2011.1 (I think) install of LXDE but it has been kept current.  

My $PATH

Code: [Select]

[rudge12000@localhost ~]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin:/home/rudge12000/bin:/usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin
[rudge12000@localhost ~]$
Thanks in advance all.

[AS]

1) not a critical issue, mostly some duplicates, the latest duplicates in the sequence are already ignored.

2) The PATH variable is built in several step, starting from /home/<user>/.bashrc, in turn it will source in the scripts in /etc/profile.d/ directory. (I'm unsure about how and when is used /etc/profile).

Now, if you change some script, very probably you will lose the changes upon a possible next update.
If you don't have performance problems leave all as it is, possibly a fix will be provided upstream. 

Also, I think some duplicate exist because the PATH is initialized upon login session, and at least some of the duplicates are currently added when launching a terminal, because a terminal source in a second time the same /etc/profile.d/scripts, and the fix may not be as simple as it may look at first sight.

AS

[Rudge]

Thanks as. As I assumed.

Not a big deal but I remember "cleaning" up $PATH as part of my old UNIX days.

I wish I could remember half of what I once knew. 

[muungwana]

you can add your own PATH at the end of .bashrc file located in your home directory and whatever was there will be cleared and yours will be used.

something like below will give your PATH only the mentioned paths:

export PATH=/bin/:/sbin/:/usr/bin/:/usr/sbin/:/usr/local/bin/:/usr/local/sbin

if you want to append your entries infront of system entries,  add this line

export PATH=/bin/:/sbin/:/usr/bin/:/usr/sbin/:/usr/local/bin/:/usr/local/sbin/:$PATH

[Rudge]

you can add your own PATH at the end of .bashrc file located in your home directory and whatever was there will be cleared and yours will be used.

something like below will give your PATH only the mentioned paths:

export PATH=/bin/:/sbin/:/usr/bin/:/usr/sbin/:/usr/local/bin/:/usr/local/sbin

if you want to append your entries infront of system entries,  add this line

export PATH=/bin/:/sbin/:/usr/bin/:/usr/sbin/:/usr/local/bin/:/usr/local/sbin/:$PATH

Thanks muungwana. This is true but my question has more to do with the PATH that is already in place "the duplicate entries for instance".

I really don't think it is that big of a deal but at some point, it seems that this would start to slow down simple commands searching through all those needless directories just to find the "ls" command.

Perhaps the quest is not worth the effort.   

[Neal ManBear]

If it bothers you, remove the duplicates.     

[Rudge]

If it bothers you, remove the duplicates.     

Ahh the essences of my question.

Exactly how do I remove them?

[Neal ManBear]

Open the file, highlight the duplicate parts and type the backspace key - one at a time, save and exit.     

[Rudge]

Open the file, highlight the duplicate parts and type the backspace key - one at a time, save and exit.     

Were is the file? What is it's name?  I guess that should have been my question. 

[muungwana]

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.

[Rudge]

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.

I think I am just going to leave my "PATH" as is and mark this thread as "Solved, no Maintenance Required".

Thanks for all the help.

This forum Rocks because we Rock!   

[AS]

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.

For the sake of the discussion I want to add that the solution 3 may cause some problem:
/usr/lib/qt4/bin is a PATH component added when the package qt4-common-4.7.3-1pclos2011 is installed.
If this package is added after the PATH is already set as per solution 3, /usr/lib/qt4/bin would need to be manually added to the PATH. There could be other packages that behave the same way ...

Suggestion 2 probably is the best option if an upstream fix is not possible.

AS

[CY087]

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)
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)
/usr/local/bin
/bin
/usr/bin

# 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)
/usr/games

# /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
/usr/lib/qt4/bin

# Following added by /etc/profile.d/kde4env.sh
/usr/bin
/usr/sbin
/usr/lib/kde4/libexec
/bin
/sbin
/usr/X11R6/bin
/usr/games
/usr/local/bin
/usr/local/sbin

# 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
/home/<username>/bin
/sbin
/usr/sbin
/bin
/usr/bin
/usr/X11R6/bin
/usr/local/bin
/usr/local/sbin
/usr/lib/kde4/libexec

(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!

cheers

[AS]

CY087,

nice recap! 

Let me point out that the script /etc/profile.d/60qt4.sh is the most intelligent 
In fact, it add the path /usr/lib/qt4/bin only if it's not already present in the PATH variable.

The above is a good solution when, like sometimes occurs, the same script is called more then one time, in fact you don't find a duplicate of that path.

[Bald Brick]

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)
/usr/local/bin
/bin
/usr/bin

But where are they actually added to the PATH variable?

The file /etc/login.defs defines two paths,

PATH=/sbin:/bin:/usr/sbin:/usr/bin for root and
PATH=/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)
/usr/games

# /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
/usr/lib/qt4/bin

# Following added by /etc/profile.d/kde4env.sh
/usr/bin
/usr/sbin
/usr/lib/kde4/libexec
/bin
/sbin
/usr/X11R6/bin
/usr/games
/usr/local/bin
/usr/local/sbin

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
/home/<username>/bin
/sbin
/usr/sbin
/bin
/usr/bin
/usr/X11R6/bin
/usr/local/bin
/usr/local/sbin
/usr/lib/kde4/libexec

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!

cheers

So, good work, CY087. When you find out more, let us know.