[Pkg-mc-devel] Bug#581175: Bug#581175: redirect stderr of helpers

[martin f krafft]

also sprach Yury V. Zaytsev <yury at shurup.com> [2010.05.11.1405 +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.
> 
> 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.

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.

> 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.

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.

> > 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.
> 
> 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.

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.

> 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.

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.

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"a woman begins by resisting a man's advances and ends by blocking
 his retreat."
                                                        -- oscar wilde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.alioth.debian.org/pipermail/pkg-mc-devel/attachments/20100511/2add00bb/attachment.pgp>