okay, you have sbin in your path
Why is it in some paths and not in everyone's path?
I have already seen this: different PCLinuxOS flavors have different PATH setup. From one side it's understandable, because something like
/usr/lib/kde4/libexec is meaningful to KDE only, from another side the lack of
/sbin as appear to be the case in this thread, is questionable.
When I started using Linux many years ago the
sbin directories were missing from ordinary users' paths in most distros I tried. This made sense as the executables in
/sbin and
/usr/sbin are there for administrative tasks and mainly intended to be run by root.
On the other hand I don't remember seeing a KDE version of PCLinuxOS where they wouldn't be found in my ordinary user's default path. This also makes sense as some of the programs in the
sbin directories actually can be run by ordinary users. I don't think either solution is wrong.
That was exactly my point, I have used the terms "is questionable" meaning that "can be discussed" ... (non native English here),
I can add that several other distros are currently using /sbin and /usr/sbin in user's PATH.
[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 ~]$
Also, the duplicates entries like in Rudge's $PATH, IMHO aren't entirely correct ...
AS
Any program can add to the existing path and most scripts don't check for existing entries before they add their own. Creating a new default path won't help unless you can also find and edit all the scrips that are messing with your old one.
But a few duplicate entries won't matter.
... a few duplicate can affect a process performance when you run a script like:
for i in *
do
[example executable in /home/rudge1200/bin]
done
when you run a script like the above, every time the
example executable is called, the shell
will search the command in each directory listed on the PATH until will find the right directory,
every time the command is executed.
I see you point. The shell will stop searching once it's found the right executable but if there are duplicates of
other directories it may repeatedly search for it several times in /bin and /usr/bin until it possibly finds it in /usr/sbin.
For instance the last part of Rudge's path (the final /usr/bin:/usr/sbin:/usr/lib/kde4/libexec:/bin:/sbin:/usr/X11R6/bin:/usr/games:/usr/local/bin:/usr/local/sbin) might have been added by /etc/profile.d/kde4env.sh.
Beside the performance issue, which may be ignored, PATH define also a precedence between commands, the first example that come to my mind is
shutdown that is present in /sbin and in /usr/bin and are different executables.
AS
I suppose that is why some scripts
append their entries to the PATH variable while other scripts prepend them. If you wish to change the search order of the most important directories your additions should come
before the old path; if you wish to minimize the disturbance caused by your additions, add them to the end of the path.
Nevertheless the strangest thing about Rudges PATH variable is that it seems to contain the path from
/etc/profile.d/kde4env.sh -- not once, but twice.
And this in spite of the fact that he doesn't run KDE but LXDE.It's also interesting that
/etc/profile.d/kde4env.sh appears to have been run first
before ~/.bash_profile was read, and then once more afterwards. (How do I know this? It's normally
~/.bash_profile that adds the
bin in the user's home directory to the PATH variable.)
Dilber MC Theme by HarzeM