[PATCH] RE: New standalone Windows release

[Maquelin, Olivier]

> From: Matt Mackall
> Sent: Monday, September 26, 2005 4:49 PM
> To: Maquelin, Olivier
> Cc: Zbynek Winkler; mercurial at selenic.com
> Subject: Re: [PATCH] RE: New standalone Windows release
[...]
> > I tried to create a separate thread to handle the error stream, but
> > sadly was unable to get that code to work properly. After a 
> while I got
> > frustrated with all this and decided that the easiest way 
> to solve the
> > problem was to get rid of the "offending code" entirely. 
> After all, the
> > only job of the readerr() function is to add the text 
> "remote: " before
> > each line coming from the error stream. Maybe we can live 
> without that
> > functionality.
> 
> I'd rather not. It generates extremely useful output. Can we come up
> with a way to isolate the problem code int util.py and then only
> Windows folks will be adversely affected?

Let me try to state this differently. As far as I am concerned,
Mercurial is currently broken on ALL platforms. Accessing a remote
repository through ssh will cause Mercurial to hang (even under Linux)
if a password is needed or if ssh wants to get confirmation for a new
public key.

The solution I was proposing eliminated the 'remote: ' string at the
beginning of each line. This makes it harder to figure out what output
comes from the local process and what output comes from the remote
command. This is sad, but hardly a showstopper as far as I am concerned.
The standard error from the remote command is still visible to the user,
and that is the most important thing.

Anyway, I tried again to get a thread-based solution to work and got
pretty close this time. I managed to get ssh to successfully ask for a
password. However, that implementation still failed to deal with ssh
asking for confirmation for a new public key:

requesting all changes
adding changesets
remote: Host key not found from database.
remote: Key fingerprint:
remote:
xubok-hovem-gydav-mivyt-sysov-poton-zihez-mobyl-zaled-kitis-tyxax
remote: You can get a public key's fingerprint by running
remote: % ssh-keygen -F publickey.pub
remote: on the keyfile.
remote: warning: tcgetattr failed in ssh_rl_set_tty_modes_for_fd: fd 5:
Invalid argument

It looks like ssh is not happy with the pipe descriptor. Any idea how to
fix that? I am running F-Secure SSH 3.3.1.

-- Olivier