On Tue, Dec 18, 2012 at 11:48:02AM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Dec 18, 2012 at 09:54:08 +0100:
> > On Tue, Dec 18, 2012 at 01:55:55AM +0200, Daniel Shahaf wrote:
> > > Not sure. For unattended scripts, the only difference between passing
> > > --non-interactive or not passing it is the error message they get, right?
> > >
> > > I mean, if they pass it they will get "Cannot prompt because we aren't
> > > interactive" (or is it "libsvn_auth has run out of username
> > > providers"?), and if they don't pass it they will on stderr an "Should
> > > I accept this SSL certificate?" prompt followed by an "End of file found on
> > > stdin" error.
> >
> > Depends. Sometimes the command just hangs and gives no output.
> > It may not always get an EOF from whatever file descriptor it is
> > blocking on. stderr might show the prompt but stderr might not
>
> Why? Shouldn't the automated test have either answered the prompt or
> closed stdin?
If it did, the problem wouldn't happen.
You can certainly blame the controlling process for misbehaving, no doubt.
The point is for 'svn' to try to by default keep working properly even if a
controlling process misbehaves like this, so that people don't have to worry
about it (adding a --non-interactive option isn't the first thing people
have in mind when they're writing a script that uses 'svn').
As it is now, 'svn' leaves it up to the user to work around this problem,
while it could be easily done automatically for them without harm.
Why would you *not* want to do this? Don't say "because the bug isn't
in svn" since that is clear. We're not fixing a bug in 'svn'. We're
making it work properly by default in more environments.
Or can you name a serious problem with this behaviour change?
I cannot think of one but perhaps I'm overlooking something.
Received on 2012-12-18 11:04:43 CET