On Mon, 4 Aug 2008, James Carlson wrote:
> Date: Mon, 04 Aug 2008 13:43:45 -0400 > From: James Carlson <James.D.Carlson at Sun.COM> > To: Mark J. Nelson <Mark.J.Nelson at Sun.COM> > Cc: David Marker <David.Marker at Sun.COM>, > SCM Migration DEV <scm-migration-dev at opensolaris.org> > Subject: Re: [scm-migration-dev] the CTRL-C dilemma > > Mark J. Nelson writes: >> "working" != "elegant" >> "working" == "ugly" > > ;-} > >> + settings = termios.tcgetattr(sys.stdin.fileno()) >> + settings[3] = settings[3] & (~termios.ISIG) # c_lflag >> + termios.tcsetattr(sys.stdin.fileno(), termios.TCSANOW, settings) > > Perhaps a dumb question, but what brings the c_lflag settings back > afterwards? If it's your shell setting ISIG when prompting, can we > trust all shells to do the same? The fix as pushed registers an atexit cleanup to restore isig for just this reason; tcsh restores it, bash doesn't. >> ...which I have tested, including that I'm able to use ^C in my terminal >> after the push completes. (Tested in gnome-terminal and xterm.) > > I guess this is part of the "!= 'elegant'" factor, but what happens if > the client doesn't take ^C at the tty, but instead burns to the ground > after starting but not completing a push? If "burns to the ground" does not include "returns," then we won't hit the aforementioned restoration. That will leave little option beyond killing either the hg process or the shell in which it's running. Indeed, it is << elegant. --Mark
