darcs

Issue 1648 darcs apply -i tries to read user input from stdin (breaks redirection)

Title darcs apply -i tries to read user input from stdin (breaks redirection)
Priority bug Status waiting-for
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, judah, kowey, twb
Assigned To
Topics UI

Created on 2009-10-11.08:02:33 by twb, last changed 2011-04-01.13:51:09 by ganesh.

Messages
msg8954 (view) Author: twb Date: 2009-10-11.08:02:31
When "apply interactive" is in ~/.darcs/defaults, patches cannot be
read from standard input.  This breaks workflows in e.g. mutt.

It might seem counterintuitive to have "two" input streams, but
clearly something like this can be implemented, because less(1) does
it.  For example, "dmesg | less" will let you scroll up and down,
which presumably is reading the arrow keypresses from stdin.
msg8966 (view) Author: kowey Date: 2009-10-19.13:09:16
Hi Judah,

If I understand our email thread correctly, we came to the conclusion that this
would be a neat thing to be able to do with Haskeline (read from /dev/tty if
stdin is not a terminal).  So I'd like to assign this to you as a darcs UI bug
to fix (using potentially a new Haskeline feature :-D).

Thanks!
msg8967 (view) Author: kowey Date: 2009-10-19.13:09:56
Email thread is here:
http://lists.osuosl.org/pipermail/darcs-users/2009-October/021861.html
msg10409 (view) Author: kowey Date: 2010-03-22.12:45:24
Just noting that we revisited this during the 2010-03 sprint in Zurich.

Our conclusion was that before we need to research the problem more, and
determine if there was a portable way to reliably detect if we were on a
terminal or not.  Windows may be an issue here.

If there is one, we can re-open the discussion about how apply -i should
behave.

Judah: any chance you'd be able to look into this?
msg10411 (view) Author: twb Date: 2010-03-22.13:14:14
Eric Kow wrote:
> Our conclusion was that before we need to research the problem more,
> and determine if there was a portable way to reliably detect if we
> were on a terminal or not.  Windows may be an issue here.

Is it allowed to improve behavour on Unix and not Windows, as long as
it doesn't make behaviour on Windows *worse* than it currently is?
msg10412 (view) Author: kowey Date: 2010-03-22.13:23:51
On Mon, Mar 22, 2010 at 13:14:20 +0000, Trent W. Buck wrote:
> Is it allowed to improve behavour on Unix and not Windows, as long as
> it doesn't make behaviour on Windows *worse* than it currently is?

My 0.20 CHF: only if it does not lead to great divergence in the UI
(which this may not).

Example divergence: in Windows, users have to hit enter after
interactive selection...

I'd like things to be as consistent/predictable across platforms as
possible

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
msg10442 (view) Author: judah Date: 2010-03-23.07:14:47
On Mon, Mar 22, 2010 at 5:45 AM, Eric Kow <bugs@darcs.net> wrote:
>
> Our conclusion was that before we need to research the problem more, and
> determine if there was a portable way to reliably detect if we were on a
> terminal or not.  Windows may be an issue here.
>
> If there is one, we can re-open the discussion about how apply -i should
> behave.
>
> Judah: any chance you'd be able to look into this?

Sure.  There's a Windows equivalent to /dev/tty ("CONIN$" and
"CONOUT$"); Haskeline already uses the latter but not yet the former.
I did some tests, and trying to open CONIN looks like a reliable way
to check whether we're in a console session.*

So I believe there's no technical barriers to a robust
terminal-checking in the backend of Haskeline.  The best approach
seems to me to add a function to Haskeline's API.  For example:

runInputTInTerm :: Settings m -> InputT m a -> m (Maybe a)

which tries to run the given action(s) using the terminal, even if
it's not stdin; and returns Nothing if it couldn't connect to
[/dev/tty,CONIN$].  This should give Darcs some flexibility in
deciding the exact semantics of apply -i.


*The one caveat: in a Cygwin X shell, we can't connect to CONIN.  But
Haskeline doesn't provide any interactive editing in that setting
anyway, so this seems OK to me.  (There's little I can do about that
unless GHC improves its Cygwin support.)
msg10445 (view) Author: kowey Date: 2010-03-23.10:07:42
Thanks! It looks like the right thing to do for this bug is to wait for
a new version of Haskeline to come out with terminal detection.
msg12585 (view) Author: judah Date: 2010-09-19.06:18:50
Haskeline 0.6.3 has been released to Hackage and should have the necessary 
functionality:
http://hackage.haskell.org/packages/archive/haskeline/0.6.3/doc/html/System-
Console-Haskeline.html

Specifically, "runInputTBehavior preferTerm" will attempt to connect to the 
user's terminal for input instead of using stdin.  (The action "haveTerminalUI" 
can be used to check whether that was successful.)  

Hopefully the haddock docs are helpful enough for someone to implement this 
ticket, but let me know if there's any questions.
msg13850 (view) Author: ganesh Date: 2011-04-01.13:51:09
There's a patch in development for this: patch567
History
Date User Action Args
2009-10-11 08:02:33twbcreate
2009-10-11 15:18:05koweylinkissue1633 superseder
2009-10-19 13:09:22koweysetstatus: unknown -> needs-implementation
topic: + UI
title: darcs apply -i <foo.dpatch is wrong -> darcs apply -i <foo.dpatch tries to read user input from stdin
nosy: + kowey, judah
messages: + msg8966
priority: bug
assignedto: judah
2009-10-19 13:09:58koweysetnosy: kowey, darcs-devel, twb, dmitry.kurochkin, judah
messages: + msg8967
2010-03-22 12:45:28koweysetstatus: needs-implementation -> needs-reproduction
messages: + msg10409
title: darcs apply -i <foo.dpatch tries to read user input from stdin -> darcs apply -i tries to read user input from stdin (breaks redirection)
2010-03-22 13:14:19twbsetmessages: + msg10411
2010-03-22 13:23:56koweysetmessages: + msg10412
2010-03-23 07:14:55judahsetmessages: + msg10442
2010-03-23 10:07:48koweysetstatus: needs-reproduction -> waiting-for
messages: + msg10445
2010-09-19 06:18:52judahsetmessages: + msg12585
2011-04-01 13:51:09ganeshsetassignedto: judah ->
messages: + msg13850