Josselin Mouette wrote: > * /usr/games not being in the PATH It's in the default system PATH. If I take it out of my PATH I presumably don't want to play games.
> * /usr/games/$exec and /usr/local/bin/$exec both exist If I create a program in /usr/local/bin, it's because I want it to be in the PATH, and be used for the whole system. Hardcoding the path thus diminishes my ability as the admin of the system. > * $HOME/bin/$exec has the same name but does something else This line of argument was already invalidated in the thread AFAICS. To reiterate: If I am smart enough to create a ~/bin/evince, I am smart enough to realize that my evince and the system evince are not the same, and fix it. > * another version is installed in /usr/local/bin, and the desktop > file starts referencing the executable in /usr/local/bin, > duplicating the one shipped in /usr/local/share/applications. Do you mean duplicating it such that there are two menu items for the same program? If so, wouldn't it be *more* confusing if there were two menu items that claimed to be for the same program, but ran different versions? Again, this is something that the local admin is free to screw up (by allowing a duplicate item in /usr/local/share/applications. But local admins screwing up is not a good rationalle for avoiding use of PATH. > These are all examples of how not hardcoding the path can cause > problems. I do not deny this is a minor problem, but it can be fixed by > a minor change (and despite your climbing on your high horse, this is a > minor change). Sorry, you lost me with "climbing onto your high horse" (followed by "WTF are you smoking", followed by unfounded statistics). Just in case I've somehow not made it clear before: When people start being personally insulting, rude, and making bad arguments, I begin progressivly ignoring them and discounting things they say in the future. -- see shy jo
signature.asc
Description: Digital signature
