filemerge regression in 1.9

[Idan Kamara]

On Wed, Jul 6, 2011 at 6:43 AM, Steve Borho <steve at borho.org> wrote:
>
> Since Mercurial 1.9, TortoiseHg is no longer able launch external
> merge tools from the resolve tool when our app is launched from the
> shell extension.  All we get is a meaningless error:
>
> % hg resolve --traceback -a
> merging foo.c
> abort: The handle is invalid

I'm guessing you are now hitting the else here:

http://selenic.com/repo/hg/file/11b5a5d2ca8b/mercurial/util.py#l357

So if I'm getting this right, in your case sys.stdout != sys.__stdout__
(which seems a bit strange),
and sys.stdout is an invalid handle, which write() fails on.

Can you print sys.stdout/__stdout__ so we can see if they are indeed
different,
and also get that traceback to show just to be sure?

>
> Looking at the diffs, I'm fairly certain this was caused by
> e3be7dc9a5e1, which passes sys.stdout to util.system as an output file

util.system uses ui.fout now so the process output always goes through the
ui descriptors, so it doesn't end up
writing to sys.stdout if sys.stdout != ui.fout (this is the case when the
cmdserver is running).

> handle.  When TortoiseHg is not launched from a command shell,
> sys.stdout and sys.stderr are *not* valid file handles.
>
> I think to resolve this cleanly, ui.fout needs to be a
> cStringIO.StringIO() or something similar when sys.stdout is not a
> valid handle (ditto for sys.stderr).  I'm curious how others feel
> about this.

Not sure that's ideal.

It sounds like you need to set your ui descriptors to something meaningful.
Depending on what your ui subclasses do,
it might save you from overriding ui.write() (or subclassing it all together
since you can set the descriptors in dispatch.request too).

I'm trying to figure out how this previously worked for you. You would not
hit the else clause
in util.system, and stdout would not get piped. Which leads to this code
path in subprocess:

http://hg.python.org/cpython/file/919ee0c6f323/Lib/subprocess.py#l726

Since there's no handle for the process, it would fall back to a pipe.

Btw this only happens in the 'w' version? Google found this:

http://www.gossamer-threads.com/lists/python/python/561143

Not sure if it's related.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110706/50de4172/attachment.htm>