[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

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?

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.

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.

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.

It was pretty clear. Guess I was just grandstanding... sorry. :)

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.

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.

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

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

Then it can be easily found and disabled/enabled without modification to the master "/etc/profile" script.

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

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.

+1 to move '.' in profile.d

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! ;)

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.

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.

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.

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.