[PATCH] RE: New standalone Windows release

Matt Mackall mpm at selenic.com
Mon Sep 26 21:36:10 CDT 2005

On Mon, Sep 26, 2005 at 06:19:33PM -0700, Maquelin, Olivier wrote:
> > 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.

Sure about that? I've never seen such behavior. OpenSSH detects if
it's running on a tty and if not, opens /dev/tty to prompt through.
Traditional rlogin has done the same for 20+, precisely because it's
crucial for using it in scripts with normal I/O redirection.

Incidentally, lots of UNIX programs rely on this behavior, including
things like CVS and rsync, which expect ssh (or rlogin) to present it
with transparent pipes containing nothing but the remote process'

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial mailing list