Share your knowledge at the LQ Wiki.
 Home Forums HCL Reviews Tutorials Articles Register Search Today's Posts Mark Forums Read
 LinuxQuestions.org [SOLVED] [Request] Move "." in PATH to /etc/profile.d
 User Name Remember Me? Password
 Slackware This Forum is for the discussion of Slackware Linux.

Notices

 07-19-2013, 10:34 PM #1 guanx Senior Member   Registered: Dec 2008 Posts: 1,044 Rep: [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
 07-19-2013, 10:52 PM #2 volkerdi Slackware Maintainer   Registered: Dec 2002 Location: Minnesota Distribution: Slackware! :-) Posts: 1,244 Rep: 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?
07-19-2013, 11:16 PM   #3
guanx
Senior Member

Registered: Dec 2008
Posts: 1,044

Original Poster
Rep:
Quote:
 Originally Posted by volkerdi ... 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.

 07-19-2013, 11:26 PM #4 Z038 Member   Registered: Jan 2006 Distribution: Slackware Posts: 841 Rep: 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.
07-19-2013, 11:32 PM   #5
volkerdi
Slackware Maintainer

Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,244

Rep:
Quote:
 Originally Posted by guanx 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.  07-20-2013, 03:30 AM #6 GazL Senior Member Registered: May 2008 Posts: 4,408 Blog Entries: 7 Rep: 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. 07-20-2013, 07:05 AM #7 guanx Senior Member Registered: Dec 2008 Posts: 1,044 Original Poster Rep: Quote:  Originally Posted by volkerdi 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 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 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 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".  07-20-2013, 07:29 AM #8 jtsn Member Registered: Sep 2011 Posts: 922 Rep: 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.
07-20-2013, 07:52 AM   #9
WhiteWolf1776
Member

Registered: Oct 2010
Location: Pittsburgh, PA
Distribution: Slackware
Posts: 270

Rep:
Quote:
 Originally Posted by jtsn 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.

 07-20-2013, 07:53 AM #10 zerouno Member   Registered: Oct 2009 Location: Italy Distribution: Slackware Posts: 496 Rep: +1 to move '.' in profile.d
 07-20-2013, 08:01 AM #11 guanx Senior Member   Registered: Dec 2008 Posts: 1,044 Original Poster Rep: EDIT: Removed Last edited by guanx; 07-20-2013 at 08:03 AM.
07-20-2013, 08:06 AM   #12
jtsn
Member

Registered: Sep 2011
Posts: 922

Rep:
Quote:
 Originally Posted by WhiteWolf1776 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 ./ 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.

07-20-2013, 08:20 AM   #13
GazL
Senior Member

Registered: May 2008
Posts: 4,408
Blog Entries: 7

Rep:
Quote:
 Originally Posted by guanx 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.

07-20-2013, 08:26 AM   #14
GazL
Senior Member

Registered: May 2008
Posts: 4,408
Blog Entries: 7

Rep:
Quote:
 Originally Posted by jtsn 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.

07-20-2013, 08:50 AM   #15
chemfire
Member

Registered: Sep 2012
Posts: 169

Rep:
Quote:
 Originally Posted by GazL 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.

 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 Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post cravengemetzel Linux - Newbie 6 12-30-2012 06:52 PM dorianrenato Linux - General 3 11-28-2011 06:41 PM wjh513 Linux - Software 1 08-13-2010 02:31 PM zorrokan Linux - Newbie 4 09-05-2007 01:26 AM ErV Slackware 3 03-20-2007 09:42 AM

LinuxQuestions.org

All times are GMT -5. The time now is 03:31 PM.

 Contact Us - Advertising Info - Rules - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
 Advertisement
 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.
 Syndicate Latest Threads   LQ News Twitter: @linuxquestions Facebook: linuxquestions Google+: linuxquestions