$PATH.. Mantinance Required? [Solved]

[CY087]

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.

I'm talking about the user session PATH here, so until we get to that point in login where the session is created i.e. after authorisation checks, nothing can actually refer to the user's session variables. I am unaware of login adopting any system path, so I believe that what init and its friends do is immaterial here.  (Also I'm on LXDE here and there is no /etc/rc.d/init.d/bootlogd script?)

But where are they actually added to the PATH variable?

I don't know, I just accepted what man login said, but
a)

Code: [Select]

[root@thenudiebar me]# strings /bin/login|grep /usr/local/bin: yields

Code: [Select]

/usr/local/bin:/bin:/usr/bin
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/binSo the login executable definitely has these paths as constants.

The file /etc/login.defs defines two paths, ... but these two definitions don't seem to be used.

I have waded through the shadow package source and found this:

Code: [Select]

/*
* Create the PATH environmental variable and export it.
*/

cp = getdef_str ((info->pw_uid == 0) ? "ENV_SUPATH" : "ENV_PATH");

if (NULL == cp) {
/* not specified, use a minimal default */
addenv ("PATH=/bin:/usr/bin", NULL);
} else if (strchr (cp, '=')) {
/* specified as name=value (PATH=...) */
addenv (cp, NULL);
} else {
/* only value specified without "PATH=" */
addenv ("PATH", cp);
}which is in a function "setup_env" called by login (and su).  Which would indicate that the /etc/login.defs path should be used, via the first "else if" part.  But like you, I changed the ENV_PATH to include a dummy dir and it doesn't appear in my path in a new login.  Reading the ChangeLog for the shadow package the only clue I can find is ...
AHA!!
from the man login.defs page waaaaaaaaaaaaaaaaaayyy down at the bottom:

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Please refer to the corresponding PAM configuration files instead.   

But I have not found out HOW the use of /etc/login.defs is excluded so far.

(Enough source code searching for today!)

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 ...

Yes, the same happens to me when I start an LXDE session.  In fact several duplicates of varying source get added to the LXDE session. I am still trying to track that down, is it gdm?, openbox?, LXDE?, something else?   That is why I used the raw console login path in my previous post to at least find a starting point.

Did you add that yourself?

(Re the funny ~/bash.profile path entries)
No, mine is exactly what is in /etc/skel.  Which I definitely have not changed since last full install.  (So it must'a been Neal that must'a done it  )

cheers

[Bald Brick]

Interesting, CY087.

It seems that some of the things that I couldn't understand about Rudge's path are there because he (like you) runs LXDE while I normally log in to KDE.

[Neal ManBear]

(So it must'a been Neal that must'a done it  )

cheers

     
Nope! Wasn't me.     

[CY087]

@BaldBrick
Yep that's why I started out talking only the console login path.  If I can some to an understanding of that then I'll start looking at the displaymanager/windowmanager/etc level.

It would be interesting to hear from some of the minimal distro folks though in terms of whether the console login path setting is consistent with my first model.

Also, I have a theory (Yet to be tested, but I do have a little experiment in mind.) that this idea that the user session PATH variable sets the order in which the shell searches for an executable is a "furphy".  But I'm not going to start to read the bash source until the fridge is emptied of car keys and filled with bacon.

(@ Neal - Just jokin mate!)

[Neal ManBear]