Jeff King <> writes:

> Erik has looked into doing a Windows alternative in compat/terminal.c,
> and I think an integer would be insufficient there. In particular, I
> think Windows needs two descriptors to accomplish the same thing (one
> for CONIN$ and one for CONOUT$).  So you'd need to turn term_t into a
> struct (and you'd probably not want to return it by value then).
> Maybe it would be better to keep the abstraction as non-leaky as
> possible, and just provide "terminal_can_prompt()" or similar?

OK.  As we won't be giving separate instances of terminals to
different callers anyway, compat/terminal.c can keep a static
variable of whatever type that is necessary for the implementation
around.  That sounds like a reasonable way to go.

> Returning the open descriptor (as Tay's patch does) avoids a race
> condition where /dev/tty can be opened when terminal_can_prompt runs,
> but not when we try to actually read from it. But we can either:
>   1. Not care. Even if the tty is opened, if a user has closed the
>      terminal we are going to get a read error anyway. So you can never
>      avoid that race condition in some form.
>   2. Open the terminal descriptor when either function is called, and
>      never close it. I don't think there is any reason we can't just
>      leak the descriptor.
> -Peff
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to