Not sure I understand this problem. I just put my bin directory at the front of $PATH rather than the end. To browse my commands, I simply `ls ~/bin`.
Pick your poison
The danger is also mitigated because I only modify my own user's shell rc file. Any daemons running as root or their own user are unaffected.
POTENTIALLY. This (for me, anyway), is a solution in search of a problem. Been using some sort of *nix since the early 90's, writing scripts and commands and aliases and functions the whole time - this has never once happened to me.
It obviously _can_, and PROBABLY has, to some. But it's more a "can" than "will". Maybe I just name my homebrew stuff in a way that's unlikely to collide, dunno.
I'm not on the comma train here because it makes the name ugly and confusing, and doesn't solve any problem that I have. But it is a clever hack for those who do have this problem.
if a tool looks up a command name "x" given to it, it just takes $PATH and goes through it. the same $PATH as in your shell when you call "x" directly.
thinking more about it, you must thought something like putting "@daily mycommand ..." in crontab, then being annoyed by it not finding your command. then the problem is not that some tools expecting a "system path", but that some tools being defiant and overrides inherited path on their own accord. which is totally unneccessary: environment is called environment because it is prepared for you (the given program) to run in.
I forget names all the time. I even forget I wrote entire projects sometimes. That's why I try to organise my systems in a way I can easily stumble upon things I haven't thought about in months, or years.
I find this article's approach actually solves a problem for me. I do find myself going back to the ~/bin folder once I a while to look for some script I use less often. So at least for N=2, it's a cool hack.
~/bin<tab><tab>
</s> :)