That's fine, and good to know, but the core of my point is uneffected.

We're talking about breaking an extremely flexible and wide-spread convention to work around one specific executable not being available on stock N900s.

The issue you're trying to solve is 'if mc must use "diff", use the gnu-compatible one', but the solution you've picked is 'prefer anything and everything in /usr/bin/gnu/ to whatever else the user may have set their PATH up to be.'

Again, maybe I have a more recent version of GNU's , or some other drop-in-compatible-replacement-which-accepts-the-relevant-options, in, for example, /usr/local/bin, and my path is /usr/local/bin:/usr/bin/gnu:/usr/bin:/bin . Or maybe someone finds a security vulnerability in the mktemp currently packaged with the gnu utils package, so I compile it myself, and again, place it in /usr/local/bin, as is conventional.

If that's my situation, and I use mc through the example wrapper, you've just broken my PATH setup, and I shouldn't have to fight my file-manager-with-shell-prompt package about what my PATH is supposed to be while I use it.

Anyway, I am assuming that a shell function/alias won't work (because mc is its own binary that happens to run a shell on the side, not a shell itself, so it likely won't inherit/source those in any way).... But if we must expect a GNU-compatible diff, I'd recommend we rather have mc patched to invoke /usr/bin/gnu/diff directly, and not screw with people's PATHs. Functionally you still break for those who don't have it, so that's no different, but now you're not forcing the PATH to be something the user may not want.