IMO PATH-prepending is the right (unix-y) way to override certain commands, as OP does. but sadly, many projects, programms which I came across (mostly but not

IMO PATH-prepending is the right (unix-y) way to override certain commands, as OP does. but sadly, many projects, programms which I came across (mostly but not exclusively daemons), defines PATH for themself, not respecting inheritence: saying "what if someone set it up maliciously" or "default PATH is not enough / too wide / in wrong order / etc" ... man, sorry, process! what you inherit is what there is, it's your environment where you need to do your job. you can't? just fail and let the caller know the error case. will you (as an app author) change the CWD because it's unfamiliar (breaking relative path parameters along the way)? or redirect STDERR from a file to tty because "user MUST SEE this error" (making it NOT shown in the error log where the user did want to put the error output)? no. that's why you should not touch PATH. except if you are a logon process, a wrapper whose responsibility is to prepare the env for descendents, or crossing privilege boundary. due to this defiance of many programms, I started to switch from PATH-prepending to "over-mount executables in separate mount namespace" strategy. I hope it won't be voided by they invent "let's switch to the default namespace because it's my will" type of overreach.