. in PATH, why not?

[Abmvk]

ChatGPT tells me it is possible to add . to the PATH, to avoid the ./prog to start prog. For me, used to MS/DOS, the ./ prefix feels strange.

But it also said this could be dangerous, without really explaining why. So my question is: why?

[ame]

ChatGPT tells me it is possible to add . to the PATH, to avoid the ./prog to start prog. For me, used to MS/DOS, the ./ prefix feels strange.

But it also said this could be dangerous, without really explaining why. So my question is: why?

ChatGPT doesn't tell you anything. It simply regurgitates words in the statistically most likely order.

A modicum of searching will answer your question:
https://unix.stackexchange.com/question ... h-variable

[BigRedMailbox]

To clarify, the basic answer is this:

1) I (evil person) do:
a) cd /tmp
b) Create evil program here and name it "ls".

2) Naive user does:
a) cd /tmp
b) ls

Now, I've got him!

The idea is that you should only be running things from trusted directories (unless you explicitly call them with a path (e.g., ./foo)).

It can be argued that since Unix has always been multi-user, this was a consideration. But DOS/Windows has always been single user.

[hippy]

Windows has always been single user.

That may have been true for some Windows versions but not for others. Opening a remote RDP session to a Windows PC may have kicked the local 'in front of screen' user off by default but there were hacks to allow multi-user use, and it was enabled by default in other versions of Windows. I ran XP as a multi-user system for a while.

[dickon]

There's also the problem that scripts may do different things depending on where you've invoked them from. This can be engineered to happen of course, but usually you'd only do that by design, rather than accident. If you've got '.' early enough in your PATH, you might accidentally shadow a system binary simply by being somewhere unfortunate when executing something, which is very frustrating to debug.

Note that the empty string is a synonym (ie, '/bin::/usr/bin' will actually parse as '/bin:.:/usr/bin') and is easy to overlook when adding things to an empty variable. LD_LIBRARY_PATH and friends also behave in the same way, with even more potential for fun.

[BigRedMailbox]

There's also the problem that scripts may do different things depending on where you've invoked them from. This can be engineered to happen of course, but usually you'd only do that by design...

Indeed. A truly well written, intended to be bulletproof, shell script will explicitly set PATH at the top of the script, to make sure that no trojan executables are brought in.

[dickon]

There's also the problem that scripts may do different things depending on where you've invoked them from. This can be engineered to happen of course, but usually you'd only do that by design...

Indeed. A truly well written, intended to be bulletproof, shell script will explicitly set PATH at the top of the script, to make sure that no trojan executables are brought in.

That has other issues, TBH. If you're relying on PATH elements to select for different versions of notionally the same executable -- think 'python' needing to be python2 or python3 depending on the script being run -- then that approach will break things. It's very sensible in system startup scripts, where the exact state of the machine is known, but less good for general-purpose use.

[bjtheone]

adding ~/bin for personal "ease of use" access to your additional shell scripts and binaries, that of course you put in a sensible place, makes sense. Adding "." is a nightmare waiting to happen.

Having said that I echo BigRedMailbox's statement that you should always control the environmental variables in your scripts. Either via explicitly setting the appropriate variables or using full paths for everything. Defined is deterministic. It also makes them behave much better when you try and run them using cron and makes them portable to other users who may have a different environmental setup.

[dickon]

Having said that I echo BigRedMailbox's statement that you should always control the environmental variables in your scripts. Either via explicitly setting the appropriate variables or using full paths for everything. Defined is deterministic. It also makes them behave much better when you try and run them using cron and makes them portable to other users who may have a different environmental setup.

Editing PATH and LD_* in scripts is almost guaranteed to fail on a lot of systems -- see, eg., Nix and NixOS, anything which sandboxes things (eg. pyenv) and whatnot -- and is a very bad idea.

Users set these things for a reason. Don't try to second-guess them.

[cleverca22]

and for the same reason, i would say you should never use absolute paths like /usr/bin/python in your cron scripts

fix $PATH, you can set it in the crontab!!
let $PATH do its job!

[BigRedMailbox]

whatnot -- and is a very bad idea.

Heh heh. Not "in my opinion"...
Or even just a bad idea. But a VERY bad idea.


That said, this sub-thread seems to have degenerated, as most threads do, into a bunch of old-timers stating their opinions as if they were facts. Standard on these boards.

FWIW, I phrased the post that launched the sub-thread very carefully, using a specific choice of words, to indicate that I see both sides, but some people claim that you should do X and some people claim that you should do not X and so on and so forth. Cases have to evaluated on their individual merits.

I should add that setting PATH inside the script is a clear statement that I (the script writer) know better than you (the script runner). Sometimes this assertion is justified, sometimes not. Cases have to evaluated on their individual merits.

[dickon]

whatnot -- and is a very bad idea.

Heh heh. Not "in my opinion"...
Or even just a bad idea. But a VERY bad idea.


That said, this sub-thread seems to have degenerated, as most threads do, into a bunch of old-timers stating their opinions as if they were facts. Standard on these boards.

Oddly enough, in this specific case, the reasons I've cited are actually fairly new. We didn't have Python or Nix when I was a baby sysadmin. We did have weird and funky, mostly NFS-riddled environments with various different binaries in different places and selected by PATH (which would break system scripts, so they fixed their PATHs, but not user scripts, which didn't and usually relied on the GNU equivalents that wouldn't have been in /usr/bin and friends) which would suffer from the same fate, however. I didn't bother mentioning those, as I've not seen one in about twenty years.

FWIW, I phrased the post that launched the sub-thread very carefully, using a specific choice of words, to indicate that I see both sides, but some people claim that you should do X and some people claim that you should do not X and so on and so forth. Cases have to evaluated on their individual merits.

I should add that setting PATH inside the script is a clear statement that I (the script writer) know better than you (the script runner). Sometimes this assertion is justified, sometimes not. Cases have to evaluated on their individual merits.

As I said: it's the right thing to do for system scripts, but nine times plus out of ten you're not writing one of those. Should you do this, you're relying on someone else's system being exactly as you expect it to be, which is very frequently not the case.

[bjtheone]

My frame of reference is building multi site, multi OS deployable CAD tool trees and run time environments that would guarantee the the user would get the required versions of the tools for a particular project, where the same user might be accessing different projects (with different environments) in the same session. We ended up creating a tool that built environments that managed all the required env variables so that the use would get the right stuff. It would also error out gracefully on impossible tool sets, that had conflicting requirements. The nice thing was you just needed to define the tools env requirements once, and the users could create environments that just worked. Many of the tools had binaries with the same names (since we had multiple versions of the same tools).

This is just a super set of building a bunch of project scripts.

The whole genesis of the project was to provide an easy to maintain solution that "just worked" and was manageable across many hundreds of users at approximately 13 sites. Basically more functionality and repeatability, while reducing support overhead.

It obviously depends on the level of control and understanding you have on the end user requirements and OS configurations. It also depends on the sophistication of your target users. If you supply them the tools and control the configurations it is much more likely "it will just work" than if you allow them to do whatever.

There are other use cases in that expecting the user to completely manage their own environment may be the most appropriate thing to do. I expect that side of the coin to generate more support traffic. In either end of the spectrum, I fail to see where putting "." in your path, especially near the beginning is not going to come back to bite you.

[GTR2Fan]

ChatGPT tells me...

Isn't it safest to just assume that it's constantly lying about everything?

[dickon]

ChatGPT tells me...

Isn't it safest to just assume that it's constantly lying about everything?

Lying implies intent, which assumes that the 'I' part of the 'AI' hype is a thing. 'AI' is not (yet) a thing: it's artificial, all right, but not in any way intelligent. MMLs, and their graphics and audio brethren, are nothing more than predictive text engines on steroids. Impressive work, but not intelligent.

Assume anything it returns is wrong, however, and you're covered. I've taken to reporting MML-generated posts on sight, without bothering to do more than skim them, because every one I've seen thus far has had glaring errors.

[GTR2Fan]

Lying implies intent, which assumes that the 'I' part of the 'AI' hype is a thing. 'AI' is not (yet) a thing: it's artificial, all right, but not in any way intelligent.

Agreed. I phrased that poorly.

At present, it seems no better than Chinese whispers as it gleans information from a combination of correct and incorrect sources and currently seems to have little or no "intelligence" when it comes to distinguishing between the two.

I'd be happier taking the word of the guy who runs my local chip shop on technical matters than taking any notice of what ChatCRP has to say.

[dickon]

At present, it seems no better than Chinese whispers as it gleans information from a combination of correct and incorrect sources and currently seems to have little or no "intelligence" when it comes to distinguishing between the two.

It's even more basic than that, I'm afraid. It's been fed more or less the entire Internet, split into tokens (which are -- more or less -- portions of words), and from that it's been able to work out that with any given prompt, what should come next based on the probabilities of the tokens that have already come before.

There are no facts in it. There is no understanding of anything. It works by looking at the tokens in the prompt, including the stuff you can't see that OpenAI have pre-loaded, what's the likely next token, chosen with some weighting from a list so you don't get the same answer each time, and repeat that selection process until it's done.

It's autocomplete. Nothing more, nothing less. Just exceptionally comprehensive autocomplete. Google's Bard and Microsoft's not-Sydney-honest both work in the same way.

We're way off-topic at this point. I'll leave this subthread here.

[Abmvk]

ChatGPT tells me...

Isn't it safest to just assume that it's constantly lying about everything?

There is a Greek story about a mother who makes offerings to Apollo, and asks the deity to save her two children pain in their lives. At that moment a big piece of stone falls from the temple of Apollo, and kills the two children.

There is some wisdom in this ancient Greeks. Looking for safety will not get you very far.