Notices

That would be great!

I actually have to advocate against this change. First, this is a problem in the environment, not in mc, and thus I think it is way more appropriate to deal with this problem in the environment, not in the mc package.

The default behavior is very flexible: It accepts whatever PATH the environment contains, which allows both users and tools to adjust their environment as needed/desired before invoking mc.

Yes, Maemo 5 by default has some brokenness to it (like a lack of 'diff'), but it is trivial for users to work around this on their own, e.g. with shell functions/aliases sourced from their ~/.bashrc or ~/.profile to do exactly what joerg's suggested wrapper script does, or to just add the gnu folder to their PATH for all their shells, etc.

The new behavior forces executables in /usr/bin/gnu to take precedence over whatever else the environment may have put in the path, possibly breaking various custom configurations.

What if I have a specific usecases that triggers an obscure bug in /usb/bin/gnu/$FOO but for which busybox's implementation of $FOO works fine? Or if I have a new and improved version of $FOO that I compiled sitting at /usr/local/bin/$FOO? Suddenly with this version I'm in mc, I run $FOO, and things don't work as I expect.

Now, if I want to get my preferred behavior back, I have to change a file controlled by a package as root user, which involves one of several ways of fighting against the package manager (with a dpkg diversion and replacing /usr/bin/mc, or manually editing the file after every update), whereas in the default behavior those who needed /usr/bin/gnu in their path could just edit a file that their shell sources at every run/login, to either modify the PATH variable globally, or to specifically modify it before only for invoking mc.

A better way would be to add /usr/bin/gnu to the end of the PATH, instead of the front, which would keep it from overriding anything. But that may still introduce tools into people's PATH that they wanted not in their PATH at all, for example - it's still taking a very flexible, de-facto-standard mechanism that empowers users to have their PATH be whatever they want, and adds rigidity without a real strong need.

In short, I don't think the loss of flexibility (and thus convenience/usability for some usecases) is worth the convenience gain, since those benefited by this could make their N900s behave how they want with very minimal effort.

P.S. Now, that all said, regardless of what you decide, keep up the good work, and thanks for maintaining this package for our phones.

The problem is that MC is hard-coded to use GNU-specific options of diff, which busybox does not support (see http://talk.maemo.org/showpost.php?p...5&postcount=99).

So it's either GNU diff or it won't work.

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.

That wouldn't work, busybox's diff symlink will still get preference.
If you don't want the tools in /usr/bin/gnu, don't install the diffutils-gnu package (or other *-gnu packages, see list here).

This was the first solution I considered, but it forces one to have have the diffutils-gnu package installed.
What if the user has installed their own diff and removed busybox's symlink?
What if the user doesn't even want diff functionality?

Then joerg_rw posted his suggestion to use a wrapper to modify the PATH, and I realized this is the behaviour I want:

If the user has diffutils-gnu installed, prefer the diff from there. Otherwise, use whichever diff is found in the PATH.

Remember the relationship with diffutils-gnu is only a Suggests, not a Recommends or a Depends.

Done, along with libslang2 (from Harmattan SDK) and diffutils-gnu:
https://openrepos.net/user/414/programs

And installed!

It did not start, as there was still a terminal open (as always ).
Cloesd the term and mc popped up.

BUT
what I did miss was the missing keyboard. So on each click the vkb pops up over half the screen and makes your action result unreadable. You always have to dismiss the vkb.
Makes it hard to use.

Nevetheless muchos gracias.

--edit
Now used it in portrait mode (not my preferred position ) and I have to say that way it is much more usable (screen is only half-overlaid by vkb, actions are seen immediately but I cannot type on that small vkb )

But then if *my* (and your) GNU diff (or compatible) is in /usr/local/bin your outta luck.

Adding a wrapper to MC so that by default /usr/bin/gnu is in front of everything else is OK because people like you or me who may have a better diff somewhere else can work around the issue in no time.

It's bad enough that MC hardcodes GNUisms but asking the maintainer to hardcode a PATH is IMHO a bad move. Shell wrappers are easy to tweak/patch/remove. Hardcoded paths is not my idea of fun

I have tried various terminals on the N9; Terminal, MTermite, FingerTerm, etc. but haven't found one that works well with mc.
I think one really needs a hardware keyboard for mc to be usable on the device.

This is one of the reasons I haven't included a launcher for Harmattan. Also, I don't want to hardcode the launcher to open mc with a particular terminal, and Maemo and Harmattan don't have 'x-terminal-emulator' alternatives. I'd rather users start their favourite terminal and then type 'mc' to launch it.

It does work well over ssh though.