Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-07 Thread Julian Foad
Just a reminder about putting this functionality in APR, in case some people in this thread aren't aware: When we discover some functionality that would ideally be provided by APR but isn't, such as this, then we should write it in such a way that it is suitable for inclusion in APR (except for

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-06 Thread Peter Samuelson
[Daniel Klíma] I tested it and same result. However I found something relevant in MSDN library: http://msdn.microsoft.com/en-us/library/7x2hy4cx.aspx (Console and Port I/O) Thanks! I still believe we should do our prompting on the console, instead of stdin/stderr - especially stdin should

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-06 Thread Mark Phippard
On Sun, Jun 5, 2011 at 8:07 AM, Peter Samuelson pe...@p12n.org wrote: [Mark Phippard] Would this cause issues for apps that drive the command line programmatically without a console?  For example, a Java web app that does some SVN commands from within the app server? I can't imagine we'd

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-06 Thread Daniel Shahaf
Peter Samuelson wrote on Mon, Jun 06, 2011 at 16:25:01 -0500: [Daniel Klíma] I tested it and same result. However I found something relevant in MSDN library: http://msdn.microsoft.com/en-us/library/7x2hy4cx.aspx (Console and Port I/O) Thanks! I still believe we should do our

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-05 Thread Peter Samuelson
[Mark Phippard] Would this cause issues for apps that drive the command line programmatically without a console? For example, a Java web app that does some SVN commands from within the app server? I can't imagine we'd want to officially support that sort of usage. We've broken screen

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-05 Thread Peter Samuelson
[Peter Samuelson] I'd say, if you don't have an actual console at hand, you really really should be using --non-interactive. Alternatively, I considered doing this same thing, but falling back to stdin / stderr if the console cannot be opened. apr_password_get() seems to use them if there is

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-05 Thread Peter Samuelson
[Peter Samuelson] I _am_ rather curious whether, on Windows, using CON: for prompting actually allows stdin to be usable for other things. Like, when piping or redirecting to it. I suppose I can try to test this feature using MingW32 + Wine Hmmm, fopen(CON:, r+) in mingw32 + Wine just

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-04 Thread vijay
On Saturday 04 June 2011 05:27 AM, Peter Samuelson wrote: Concept patch - not tested. Does this seem reasonable? I'd really prefer to do all our prompting on the terminal. The fact that this frees up stdin for things like 'svn patch' and 'svnrdump load' is only one reason. I tested your

Re: [RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-04 Thread Mark Phippard
On Fri, Jun 3, 2011 at 7:57 PM, Peter Samuelson pe...@p12n.org wrote: [Peter Samuelson] Hrrrmph.  I think libsvn_subr/prompt.c could use a large dose of /dev/tty.  Right now it mostly uses stderr and stdin, but for password prompts it uses /dev/tty on modern Unix ... indirectly, by calling

[RFC] [PATCH] Use console, not stdin/stderr, for prompting

2011-06-03 Thread Peter Samuelson
[Peter Samuelson] Hrrrmph. I think libsvn_subr/prompt.c could use a large dose of /dev/tty. Right now it mostly uses stderr and stdin, but for password prompts it uses /dev/tty on modern Unix ... indirectly, by calling apr_password_get() which calls getpass(), an OS library function.