On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote:
>
> Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > OTOH, if this kind of behaviour is too far-fetched for a single
> > subcommand, I might be able to do it by invoking two commands, if I
> > could succesfully (and invisibly) detect that a cached password is no
> > longer correct. As in:
> >
> > svn ls --non-interactive $URL >/dev/null
> > # if exit-code != 0, parse error code to see if it indicates "auth
> > failed"
> > if ("auth failed"):
> > svn auth add $URL
> >
>
> What happens if a valid username/password are cached that have read-
> only access and one wants to preseed a username/password that have read-
> write access?
I don't know. We don't have that use case at $company, trying to keep
things simple :-).
Ah but shouldn't 'svn auth' carry an optional --username parameter? In
that case, I don't see the problem, I guess.
> > But then the burden is on me detecting the "auth failed" correctly,
> > and making sure it's the "password refused" kind of auth failure (I
> > guess there's an error code for that).
>
> There's an error code for that, but it's the E000042 value in stderr,
> not the exit code. The exit code is generally 1 (unless segfault or
> something).
Yup, parsing the error code from stderr was what I was thinking of.
Not great, but it'd work.
--
Johan
