LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-19-2013, 10:34 PM   #1
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Rep: Reputation: 146Reputation: 146
[Request] Move "." in PATH to /etc/profile.d


Dear Slackware Maintainers,

I've long been feeling uncomfortable to have the CWD (".") in PATH by default. It has since been my first thing to do after installation to edit "/etc/profile" to remove it.

Is there any strong reason to have this, not only confusing, surprising, convention breaking, but also insecure thing not easily configurable in "/etc/profile"? If there is such a strong reason to have it, I apologize for my ignorance.

Would it be better to do this, if really necessary, in somewhere like "/etc/profile.d/~.{c,}sh" (\tilde.{c,}sh)?

Regards,
Guan
 
Old 07-19-2013, 10:52 PM   #2
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 875

Rep: Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814
There's a strong reason not to have it appear in $PATH before the usual directories for binaries.
There's a decent reason not to have it appear in $PATH at all for root (we don't).
What's the strong reason not to have it appear at all?
 
Old 07-19-2013, 11:16 PM   #3
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 146Reputation: 146
Quote:
Originally Posted by volkerdi View Post
...
What's the strong reason not to have it appear at all?
None. Therefore I did not ask for removing it altogether, but wanted it to be easily configurable under "/etc/profile.d". (Sorry if I did not make it clear in my last post.)

As in many (if not most) cases the OS is much less valuable than user data, the same reason for not having it in root's PATH may apply to normal users.
 
Old 07-19-2013, 11:26 PM   #4
Z038
Member
 
Registered: Jan 2006
Distribution: Slackware
Posts: 804

Rep: Reputation: 157Reputation: 157
I can't think of a strong reason not to have it appear at all, but it is questionable whether it is necessary or especially beneficial, and it is sometimes inconvenient to have the current directory in the path.

For example, when using find with execdir, one must edit out the '.' from the path for execdir to work.

Code:
PATH=${PATH/.:/} PATH=${PATH%:.} find . -type f -execdir chmod go-rwx {} \;
The above PATH edits take care of the case where the CWD occurs embedded in the path or as the last path directory. It's not a big deal, but it's a bit of a bother when I don't have a need to have the current directory included in my path.
 
Old 07-19-2013, 11:32 PM   #5
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 875

Rep: Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814Reputation: 1814
Quote:
Originally Posted by guanx View Post
None. Therefore I did not ask for removing it altogether, but wanted it to be easily configurable under "/etc/profile.d". (Sorry if I did not make it clear in my last post.)
It was pretty clear. Guess I was just grandstanding... sorry.

Quote:
As in many (if not most) cases the OS is much less valuable than user data, the same reason for not having it in root's PATH may apply to normal users.
Well, the main reason to not have it in root's path is that something executed by mistake could take over the entire system. In the case of a normal user, the potential for damage is much less. You might say that having '.' in the $PATH is confusing, surprising, and convention breaking, but you have to consider that when Slackware began, everyone had it in $PATH. Removing it was all of those things when it occurred. Not only that, but it usually appeared first in the $PATH! You might be testing your own version of ls that you just compiled, and ./ls is a lot of work, right?

Mostly I was playing devil's advocate. I tend to agree with your point at this juncture where it's become uncommon to have '.' in the $PATH and most people don't expect it, but having it way down towards the end it's not too hazardous since you'd have to be in the same directory as an evil script/binary and also manage to make a typo that matches it while trying to run some other command. I'll consider your advice, though I think the hazard of having it near the end of the $PATH is very slight.
 
1 members found this post helpful.
Old 07-20-2013, 03:30 AM   #6
GazL
Senior Member
 
Registered: May 2008
Posts: 3,439

Rep: Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956
Whether one prefers "." in ones PATH or not (I prefer not) I don't see what moving that section of code to a member of /etc/profile.d/ would achieve.

BTW, What is this "~.sh" you proposed? It's not a convention I've come across before.
 
Old 07-20-2013, 07:05 AM   #7
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 146Reputation: 146
Quote:
Originally Posted by volkerdi View Post
In the case of a normal user, the potential for damage is much less.
Yes. The potential damage to the operating system is much less for an unprivileged user. This makes little difference in the risk taken, however, because as I mentioned --

Quote:
Originally Posted by guanx View Post
As in many (if not most) cases the OS is much less valuable than user data, the same reason for not having it in root's PATH may apply to normal users.
Suppose I publish a tar ball containing an "sl" command which essentially does "rm -fr $HOME" (to the police -- I will not actually do that), then those who put all their data in $HOME may have a bad time looking into my tar ball. Of course they can restore everything from their backup, if they have a backup at all ...

Quote:
Originally Posted by GazL View Post
Whether one prefers "." in ones PATH or not (I prefer not) I don't see what moving that section of code to a member of /etc/profile.d/ would achieve.
Then it can be easily found and disabled/enabled without modification to the master "/etc/profile" script.

Quote:
Originally Posted by GazL View Post
BTW, What is this "~.sh" you proposed? It's not a convention I've come across before.
It's not a convention. "~" will come alphabetically in the last, and keep the same behavior as when it's at the end of "/etc/profile", unaffecting other scripts under "/etc/profile.d".
 
Old 07-20-2013, 07:29 AM   #8
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
How many non-root users actually execute stuff from their cwd?

In my case I occasionally need to execute stuff from the current directory as root (SlackBuilds, nVidia installers etc.), but under a regular user account I usually never run stuff, which isn't in $PATH (including ~/bin). So if something gets executed from '.', it's almost always by accident.

Nevertheless thanks for the heads-up, I modified my profile scripts, too.
 
Old 07-20-2013, 07:52 AM   #9
WhiteWolf1776
Member
 
Registered: Oct 2010
Location: Pittsburgh, PA
Distribution: Slackware
Posts: 226

Rep: Reputation: 54
Quote:
Originally Posted by jtsn View Post
How many non-root users actually execute stuff from their cwd?

In my case I occasionally need to execute stuff from the current directory as root (SlackBuilds, nVidia installers etc.), but under a regular user account I usually never run stuff, which isn't in $PATH (including ~/bin). So if something gets executed from '.', it's almost always by accident.

Nevertheless thanks for the heads-up, I modified my profile scripts, too.

If you are a developer... you execute things as a normal user all the time. Build.... Test... Fix... Repeat

That said, I generally find myself doing ./<whateverIwantTOrun> anyway.
 
Old 07-20-2013, 07:53 AM   #10
zerouno
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 269

Rep: Reputation: 82
+1 to move '.' in profile.d
 
Old 07-20-2013, 08:01 AM   #11
guanx
Senior Member
 
Registered: Dec 2008
Posts: 1,014

Original Poster
Rep: Reputation: 146Reputation: 146
EDIT: Removed

Last edited by guanx; 07-20-2013 at 08:03 AM.
 
Old 07-20-2013, 08:06 AM   #12
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by WhiteWolf1776 View Post
If you are a developer... you execute things as a normal user all the time. Build.... Test... Fix... Repeat
Let's say you develop dostuff. You build it and then type "dostuff" at the shell...

It executes the stable (previous) version, which is already installed as /usr/local/bin/dostuff. Oops!

Quote:
That said, I generally find myself doing ./<whateverIwantTOrun> anyway.
And that's why I'm doing all the time, too. After compilation I specifically want to execute the binary in the current directory and not the version already installed on the system. So from a developer's standpoint it doesn't make sense either.
 
Old 07-20-2013, 08:20 AM   #13
GazL
Senior Member
 
Registered: May 2008
Posts: 3,439

Rep: Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956
Quote:
Originally Posted by guanx View Post
Then it can be easily found and disabled/enabled without modification to the master "/etc/profile" script.
Not sure I agree with that. I'd expect to find it at the end of /etc/profile rather than in some obscurely named member of profile.d and I really don't see the difference between having to edit /etc/profile, and having to edit or delete a file in /etc/profile.d.

IMO the stock /etc/profile and by extension /etc/profile.d already do far more than I would ideally prefer, and if it were up to me I'd just remove '.' from the PATH and leave individual users to set it in their ~/.profile or equivalent if desired. But if Pat wants to leave it as is for the sake of historical continuity, then I understand that choice also.


I've always viewed /etc/profile as something that belongs to the system administrator and the contents of profile.d as belonging to the distro maintainer for stuff that shouldn't need changing. Clearly this isn't the case in slackware as we have things like lang.{c,}sh in profile.d, but
IMO that is something that could be improved on.

Last edited by GazL; 07-20-2013 at 08:27 AM.
 
Old 07-20-2013, 08:26 AM   #14
GazL
Senior Member
 
Registered: May 2008
Posts: 3,439

Rep: Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956Reputation: 956
Quote:
Originally Posted by jtsn View Post
Let's say you develop dostuff. You build it and then type "dostuff" at the shell...

It executes the stable (previous) version, which is already installed as /usr/local/bin/dostuff. Oops!
Not to mention the absolutely classic gcc -o test test.c && test

prefixing the executable with ./ also avoids any unexpected collisions with a shell built-ins or aliases (and bash hash-tables for that matter).
IMO relying on "." in your PATH is just too unpredictable.

Last edited by GazL; 07-20-2013 at 08:30 AM.
 
Old 07-20-2013, 08:50 AM   #15
chemfire
Member
 
Registered: Sep 2012
Posts: 73

Rep: Reputation: Disabled
Quote:
Originally Posted by GazL View Post
I've always viewed /etc/profile as something that belongs to the system administrator and the contents of profile.d as belonging to the distro maintainer for stuff that shouldn't need changing. Clearly this isn't the case in slackware as we have things like lang.{c,}sh in profile.d, but
IMO that is something that could be improved on.
That's interesting I would have said the exact opposite. Given that /etc/profile is responsible for executing the scrips in profile.d, and that /etc/profile is likely to get overwritten or at least have a .new created with subsequent package installations while the administrator can expect any script s?he has placed in profile.d to be unmolested as packages get added and removed.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] I added a PATH to /etc/profile but "echo $PATH" says it's not there? cravengemetzel Linux - Newbie 6 12-30-2012 06:52 PM
unpredictable "delete" "move to trash" or "cut" file menu option dorianrenato Linux - General 3 11-28-2011 06:41 PM
can't locate object method "path" via package "Autom4te::Request" at/usr/bin/autom4te wjh513 Linux - Software 1 08-13-2010 02:31 PM
Where can I read about the difference between "..profile" and ".profile"? zorrokan Linux - Newbie 4 09-05-2007 01:26 AM
"Broken" envirnment variable (MANPATH) and "/etc/profile.d" question. ErV Slackware 3 03-20-2007 09:42 AM


All times are GMT -5. The time now is 07:37 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration