Many GUI programmes, such as G* and K* tools, spam stderr with crap
that noone cares about. If mc spawns these helpers, the output
messes up the ncurses UI and requires me to punch ctrl-l to
restore.

I think it would make sense if mc categorically intercepted stderr
of processes it spawns. One could consider accumulating such output
in a buffer that can be viewed separately, or to display the output
with e.g. less, and restore the UI on exit. Ideally it would be
configurable, of course. I don't really want to have to hit any keys
to return to the mc UI.

Thanks for your consideration.

Hi!

You can do it yourself by placing an appropriate entry in mc.ext in your
~/.mc configuration folder. This is the anticipated way by upstream to
change the default behavior and we as the packagers should not interfere
with it.

If you need more information please follow up, otherwise I will close
this bug.

also sprach Yury V. Zaytsev <yury@shurup.com> [2010.05.11.1331 +0200]:

You mean I should duplicate/overwrite /etc/mc/mc.ext (I don't have
a specific ~/.mc/mc.ext file, since I configure everything via
mailcap)? I don't think this is a good idea.

Is there any reason why a spawned process' stderr output should be
printed to the pty where mc runs? I can't see any, and then it
really just makes more sense to block it altogether.

Thanks,

You can cp /etc/mc/mc.ext ~/.mc and edit it accordingly, but I guess
that just adding a relevant section to ~/.mc/mc.ext would work and it
should take precedence on /etc/mc/mc.ext.

Your mailcap configuration will not work anyway because mc does not use
mailcap by default. Therefore if you want to use mailcap you have to
create your own mc.ext either way.

I run different stuff in the background and if it fails I'd like to see
the error messages immediately because I can Ctrl+L later to reset the
terminal anyway, but if I don't take action quickly I might run into
problems.

These are not changes we are supposed to do as packagers especially when
upstream already provides a way for the user to configure it. If you
want to make it a global default for everybody I think this should be
discussed with upstream.

also sprach Yury V. Zaytsev <yury@shurup.com> [2010.05.11.1405 +0200]:

Yes, and suddenly I am forced to maintain Yet Another
Extension-To-Viewer Mapping. I'd really rather not have to override
the default config for this trivial but far-reaching change.

Fair enough, except /etc/mc/mc.ext uses /usr/bin/see in places,
which *is* mailcap. Anyway, I am happy with the default. I just
don't want stderr.

The stuff printed to stderr gets spewed somewhere on the screen,
most likely down where the command line is. It is not properly
formatted, has no line breaks, and interferes badly with the
shortcut bar printed at the very bottom of mc. Yes, it shows that
there was something on stderr, but it's not very useful at all.

Can you give me an example of when you don't expect stderr and need
to react immediately to error messages?

Shouldn't mc really provide a pane with stderr output instead, which
is integrated with the interface, rather than to mess it up.

I don't think upstream provides a way for the user to configure this
aspect. Upstream provides a way to specify extension handlers, but
that's a core component of the software and cannot really be
overridden.

For instance, I tried to put the following into ~/.mc/mc.ext, but
there was no effect whatsoever:

  type/^PDF
    Open=(okular %f 2>/dev/null &)
    #Open=(acroread %f &)
    #Open=(ghostview %f &)
    View=%view{ascii} pdftotext %f -

Please advise what I should do to "configure" this.

But even if this worked, I'd really rather not have to copy text for
all affected types to my own configuration file.

Oh, I'm so sorry for dashing your hopes for salvation...

Extension handling system thou would allow you to override individual
sections of mc.ext will come in later releases, right now there's no
other way around it, other than overriding the whole file.

In places != in every place.

The fact that there's something on stderr is already useful to know for
me. Moreover, most of the times, although the output it garbled, it's
readable.

I already gave you an example (numerical simulations of mine).

Another one would be a script that creates an archive and spits out an
"out of space" error message. I'd rather like to see that something went
wrong here rather than just get a truncated archive after the source is
already deleted in the end.

If you think so, feel free to open a ticket upstream.

Why wouldn't you read the man page yourself instead of asking me to do
it for you and summarize what I learned from it here? I think I already
gave you the pointer what to look for.

FYI I was wrong in the previous post about ~/.mc/mc.ext, in fact this
file should be called ~/.mc/bindings and you are supposed to go to Menu
-> Command -> Edit extension file to create your own copy of the global
configuration and open it in the mcedit to make your changes.