>The order above is important, local must come before existing PATHs for lower precedence so that it cannot override higher privilege bins

You've got the order reversed there - the first item found in your PATH will be used, and therefore earlier directories in your PATH have higher precedence:

  jfred@lambdacrypt ~$ cat dir1/pathtest 
  #!/run/current-system/profile/bin/bash
  echo "script in dir1"
  jfred@lambdacrypt ~$ cat dir2/pathtest 
  #!/run/current-system/profile/bin/bash
  echo "script in dir2"
  jfred@lambdacrypt ~$ PATH=$HOME/dir1:$HOME/dir2 pathtest
  script in dir1

You are correct my mistake.

I don't understand the point in using ~/.local/bin and then putting it in your PATH. The point of treating /usr/local/bin and the other root-owned binary directories specially is that they are in your path, which means that if you type "ls" you want to run "ls" and not something untrusted. For that reason, anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. The only difference might be that you don't affect other users on the same system, in a multi-user environment (which is increasingly rare). It might be convenient if you wanted to be able to clean up an entire installation by deleting one directory, but it's not a security feature.

Don't install binaries anywhere in your path if you don't trust them or know where they came from. (Also, sibling is correct that first location found wins when searching PATH for a command name.)

Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package. This was, in fact, the norm when npm was new and the community was small and most people knew each other. The only problem is with treating npm like a vetted distro like Debian, and assuming that anything on npm is safe to install without any connection to the author (or 1001 dependencies). That's where everything started to go sideways.

> anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. [...] it's not a security feature.

The parent was highlighting how the article points out you can overwrite root files:

> "bin": { "/usr/bin/date": "./fake-date" }

This is not possible with ~/.local

I wouldn't call this a "security feature", but I would call it prudent to not hand over root access to npm packages.

> Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package.

This is not the problem with npm, the problem is dependencies, and their dependencies and so on. I certainly will never be able to personally vet the 1000 deep nest of dependencies in an npm package I may have to use.

It seems another reason to prefer `npx` over `npm install -g`.