You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Belmonte <jo...@neggie.net> on 2005/10/08 22:27:40 UTC
"svn info" good return code on bad URL
I expect "svn info <URL>" to have a non-zero rcode if the URL is not
valid. Seen in version 1.2.3. May I file a bug?
$ svn info http://svn.collab.net/repos/svn/bad_url
http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
$ echo $?
0
--John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Julian Foad <ju...@btopenworld.com>.
Ph. Marek wrote:
>
> Please note that the return code is normally correlated to the system error
> that caused the error, ie.
[...]
> 2 == ENOENT == File not found
No; that approach only works for very low-level tools that don't do much
besides make a few system calls. Most errors in higher-level programs like
Subversion are unrelated to particular system calls.
> I believe that as much information as possible should be returned - so the
> caller can decide what to do.
That approach doesn't scale. Subversion has too many different possible
individual errors to fit in an exit code byte, let alone trying to report
chains of errors. See, for example, the advice on exit codes in The GNU C
Library documentation: <http://www.delorie.com/gnu/docs/glibc/libc_559.html>.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Oct 11, 2005 at 02:54:29PM +0200, Ph. Marek wrote:
> > If warnings yield 1, should errors yield 2?
> Please note that the return code is normally correlated to the system error
> that caused the error, ie.
> > Greg Hudson wrote:
> > > egyptian-gods% tar cvf foo.tar foo blob
> > > tar: foo: Cannot stat: No such file or directory
> > > blob/
> > > tar: Error exit delayed from previous errors
> > > egyptian-gods% echo $status
> > > 2
> 2 == ENOENT == File not found
Sorry, but that's rubbish. I've _never_ seen a program whose exit codes
are just the value of errno. Most follow the convention that "An exit
status of zero indicates success, and a nonzero value indicates failure",
and leave the rest undefined.
For example, tar generally returns zero for success, 2 if "something went
wrong", or 128 for "something remote went wrong". patch returns "0 if
all hunks are applied successfully, 1 if some hunks cannot be applied,
and 2 if there is more serious trouble."
We could either follow the "1 for warning, 2 for error" route that patch
does, or just use 1 for everything. Either would be valid.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Tuesday 11 October 2005 14:36, Julian Foad wrote:
> If warnings yield 1, should errors yield 2? It is difficult enough already
> for us to decide whether a given circumstance should be treated as an error
> or a warning. We can't reliably and objectively make a distinction in many
> cases, and to produce arbitrary distinctions wouldn't help script writers:
> to know how to handle any failure, they need to know exactly what the
> problem was, not just whether we regarded it as "error" or "warning". So
> errors should also (still) produce exit code 1.
Please note that the return code is normally correlated to the system error
that caused the error, ie.
> Greg Hudson wrote:
> > egyptian-gods% tar cvf foo.tar foo blob
> > tar: foo: Cannot stat: No such file or directory
> > blob/
> > tar: Error exit delayed from previous errors
> > egyptian-gods% echo $status
> > 2
2 == ENOENT == File not found
It is merely convention that warnings produce the (lowest possible) return
code of 1 - as the thing which caused a warning might not be the result of a
system error (think XML-parser with invalid date *after* the xml - there's no
failed system call, but some internal condition that resulted in a warning).
BTW, 1 == EPERM ... that doesn't say much.
It's just returned so that the caller doesn't think *everything* went ok.
So, IMO warnings should *always* return non-0, and errors an as meaningful as
possible return code - it's better than simply returning the same code.
Eg. if some script finds an return code of 12 == ENOMEM it may just retry a
while later.
I believe that as much information as possible should be returned - so the
caller can decide what to do.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by kf...@collab.net.
Julian Foad <ju...@btopenworld.com> writes:
> I might try to write a concrete proposal for this. We should state it
> in our user documentation.
>
> Apologies for the times I said we should return zero if there are only
> warnings. I did think about it at the time, and was sure of it, but I
> am now convinced otherwise. Any other views?
I agree with your new proposal, but let's just document that we return
0 on success, and nonzero if there was any error or warning. That way
we won't force ourselves to distinguish between errors and warnings
even when it's difficult to do so.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by John Belmonte <jo...@neggie.net>.
I wrote:
> 1) Please let's not do the "different return codes for warnings and
> error" thing. I've had the experience trying to deal with the tool
> "tidy" which does this, and it's very hard to work with, at least from
> sh or bash. For example, if you want to capture the tool output with
> command substitution (e.g. FOO=`svn info $URL`), there is no way (that
> I've been able to find) to get the return code.
One more point here. In UNIX, non-zero return codes are really
considered errors. When running a shell script with "sh -e", which I
consider best practice, any non-zero return code is going stop your
program. The only sane solution, if you really need one in the first
place, is to give tools an option to promote warnings to errors (e.g.
gcc -Werror).
--John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Michael Sinz <Mi...@sinz.org>.
Julian Foad wrote:
> Michael Sinz wrote:
>
>> Julian Foad wrote:
>>
>>> Roughly; but "so you can use wildcards [that match more than just the
>>> intended files]" is only one example of a sloppy usage that is made
>>> "easier" by the decision. Similar cases do apply to URLs, e.g. "svn
>>> info $REPOS/branches/1.{0,1,2}.{0,1}" where you don't care if some of
>>> those combinations don't exist. So no, we shouldn't get rid of that
>>> behaviour just for URLs.
>>
>>
>> Now I am confused... I think.
>>
>> The command above is (in Unix shells) a glob expansion of file names that
>> only expand to those names that actually exist (the shell checks/looks
>> for
>> the files)
>
>
> No. Standard shells expand "{...}" in full without looking at what
> files exist (in contrast to "[...]").
Oops - that is what I get for reading too quickly...
Still, the question is how do I know if I gave a bad path to svn info
when run from a script?
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Julian Foad <ju...@btopenworld.com>.
Michael Sinz wrote:
> Julian Foad wrote:
>
>> Roughly; but "so you can use wildcards [that match more than just the
>> intended files]" is only one example of a sloppy usage that is made
>> "easier" by the decision. Similar cases do apply to URLs, e.g. "svn
>> info $REPOS/branches/1.{0,1,2}.{0,1}" where you don't care if some of
>> those combinations don't exist. So no, we shouldn't get rid of that
>> behaviour just for URLs.
>
> Now I am confused... I think.
>
> The command above is (in Unix shells) a glob expansion of file names that
> only expand to those names that actually exist (the shell checks/looks for
> the files)
No. Standard shells expand "{...}" in full without looking at what files exist
(in contrast to "[...]").
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Michael Sinz <Mi...@sinz.org>.
Julian Foad wrote:
> John Belmonte wrote:
>> Julian Foad wrote:
[...]
>> We (inconsistently) treat errors like "not under
>> version control" and "file does not exist" as non-fatal so you can use
>> wildcards. When thinking about this, it only seems to make sense for
>> working copy targets, though. So we could get rid of this for URLs if we
>> wanted to.
>
> Roughly; but "so you can use wildcards [that match more than just the
> intended files]" is only one example of a sloppy usage that is made
> "easier" by the decision. Similar cases do apply to URLs, e.g. "svn
> info $REPOS/branches/1.{0,1,2}.{0,1}" where you don't care if some of
> those combinations don't exist. So no, we shouldn't get rid of that
> behaviour just for URLs.
Now I am confused... I think.
The command above is (in Unix shells) a glob expansion of file names that
only expand to those names that actually exist (the shell checks/looks for
the files)
So, while there would be no error/warning for the combinations that don't
exist, that is because they were never actually passed to the svn info
command. This does not change the fact that if you actually use a file
name that does not exist that a warning (and 1 return code) should be sent,
does it?
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 12 Oct 2005, Julian Foad wrote:
>
> > 2) I disagree that an invalid URL "inside" a repository is only a
> > warning. As I've said, this is arbitrary from the point of view of the
> > client. If I'm scripting and all I have is the command line client and
> > a given URL, how do I determine if that URL is valid or not? In the
> > past I've used "svn ls", but "svn info" should be usable here to. If ls
> > returns an error for a URL, shouldn't info do the same? They both
> > return data about a file on directory node.
>
> Yes, I completely agree with you. I was going to reply to Peter about that:
>
> Peter N. Lundblad wrote:
> >> it's arbitrary (from the point of view of the client) that the case
> >> above succeeds while the following fails. Any bad URL should fail.
> >
> > It's not completely arbitrary, since giving an URL that doesn't point to a
> > repository is fatal, but giving an URL with a non-existent path *inside*
> > the repository is not.
>
> The only sense in which it is "fatal" is that the current implementation
> terminates the program in that case. Since we are debating whether the
> behaviour is right, that is no grounds for an argument. We arbitrarily
> decide to make some errors fatal and others not, based on our best guess
> of what will be most useful for users.
>
Of course, but by "arbitrary" I mean some choice you make without good
arguments for one or the other side. Referring to a non-existent path and
trying to talk to a non-existent repository are two different things to
me. One might well argue that one of the cases should be treated like
"more fatal" than the other. I don't say I nececarily agree, though.
> > We (inconsistently) treat errors like "not under
> > version control" and "file does not exist" as non-fatal so you can use
> > wildcards. When thinking about this, it only seems to make sense for
> > working copy targets, though. So we could get rid of this for URLs if we
> > wanted to.
>
> Roughly; but "so you can use wildcards [that match more than just the
> intended files]" is only one example of a sloppy usage that is made
> "easier" by the decision. Similar cases do apply to URLs, e.g. "svn
> info $REPOS/branches/1.{0,1,2}.{0,1}" where you don't care if some of
> those combinations don't exist. So no, we shouldn't get rid of that
> behaviour just for URLs.
I think using wildcards that generate existing filenames is different from
explicitly listing (albeit in a compact form) paths, so just because we
ignore non-existent and unversioned WC paths in some cases doesn't
neceecarily mean we should ignore non-existent URLs. Again, I have no
strong feelings, I'm just pointing out that the two cases aren't
completely the same. If we want to go this route,we have more commands
that should continue after a non-existent URL. I tried svn ls for example.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Julian Foad <ju...@btopenworld.com>.
John Belmonte wrote:
>
> Julian Foad wrote:
>
>>If warnings yield 1, should errors yield 2? It is difficult enough
>>already for us to decide whether a given circumstance should be treated
>>as an error or a warning. We can't reliably and objectively make a
>>distinction in many cases, and to produce arbitrary distinctions
>>wouldn't help script writers: to know how to handle any failure, they
>>need to know exactly what the problem was, not just whether we regarded
>>it as "error" or "warning". So errors should also (still) produce exit
>>code 1.
[...]
>>Some commands, such as those whose purpose is to compare or find or test
>>something, can have more than one success status, and thus 2 or a higher
>>number for the warning/error exit code. E.g. "svn diff" could have 0 if
>>no differences found, 1 if differences found, 2 for warnings and/or errors.
[...]
> 1) Please let's not do the "different return codes for warnings and
> error" thing.
We won't. (I said we shouldn't in the quote above, though perhaps it wasn't
very clear. "Us" referred to "svn", and "them" to the script writers.)
> I've had the experience trying to deal with the tool
> "tidy" which does this, and it's very hard to work with, at least from
> sh or bash. For example, if you want to capture the tool output with
> command substitution (e.g. FOO=`svn info $URL`), there is no way (that
> I've been able to find) to get the return code.
I don't see how that is relevant. If you're unable to get the return code from
a program that does distinguish, or if the program doesn't distinguish, then
the end result is the same: you can't distinguish. Why is that an argument one
way or the other?
(From your subsequent message:)
> One more point here. In UNIX, non-zero return codes are really
> considered errors. When running a shell script with "sh -e", which I
> consider best practice, any non-zero return code is going stop your
> program.
Generally, yes to all of that. I don't know whether you are happy or unhappy
with exceptions for special cases like "diff" returning 1 for "there are
differences".
> The only sane solution, if you really need one in the first
> place, is to give tools an option to promote warnings to errors (e.g.
> gcc -Werror).
The current proposal is that warnings, while not causing the program to abort,
should nevertheless result in a non-zero exit status.
Are you saying that you disagree and that warnings should result in a zero exit
status unless an error is also encountered or a "treat warnings as errors"
switch is given?
If so, what is the benefit of being able to run without the "warnings as
errors" switch, i.e. in a mode compatible with how "svn" currently behaves?
(Apart from "compatibility" itself, which is a valid concern but one that we
can address separately from the question of what would be best.)
> 2) I disagree that an invalid URL "inside" a repository is only a
> warning. As I've said, this is arbitrary from the point of view of the
> client. If I'm scripting and all I have is the command line client and
> a given URL, how do I determine if that URL is valid or not? In the
> past I've used "svn ls", but "svn info" should be usable here to. If ls
> returns an error for a URL, shouldn't info do the same? They both
> return data about a file on directory node.
Yes, I completely agree with you. I was going to reply to Peter about that:
Peter N. Lundblad wrote:
>> it's arbitrary (from the point of view of the client) that the case
>> above succeeds while the following fails. Any bad URL should fail.
>
> It's not completely arbitrary, since giving an URL that doesn't point to a
> repository is fatal, but giving an URL with a non-existent path *inside*
> the repository is not.
The only sense in which it is "fatal" is that the current implementation
terminates the program in that case. Since we are debating whether the
behaviour is right, that is no grounds for an argument. We arbitrarily decide
to make some errors fatal and others not, based on our best guess of what will
be most useful for users.
> We (inconsistently) treat errors like "not under
> version control" and "file does not exist" as non-fatal so you can use
> wildcards. When thinking about this, it only seems to make sense for
> working copy targets, though. So we could get rid of this for URLs if we
> wanted to.
Roughly; but "so you can use wildcards [that match more than just the intended
files]" is only one example of a sloppy usage that is made "easier" by the
decision. Similar cases do apply to URLs, e.g. "svn info
$REPOS/branches/1.{0,1,2}.{0,1}" where you don't care if some of those
combinations don't exist. So no, we shouldn't get rid of that behaviour just
for URLs.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-10-12 at 07:48 -0400, John Belmonte wrote:
> For example, if you want to capture the tool output with
> command substitution (e.g. FOO=`svn info $URL`), there is no way (that
> I've been able to find) to get the return code.
sh-3.00$ foo=`ls blah`
ls: blah: No such file or directory
sh-3.00$ echo $?
1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Cory Omand <co...@blastwave.org>.
John Belmonte wrote:
> 1) Please let's not do the "different return codes for warnings and
> error" thing. I've had the experience trying to deal with the tool
> "tidy" which does this, and it's very hard to work with, at least from
> sh or bash. For example, if you want to capture the tool output with
> command substitution (e.g. FOO=`svn info $URL`), there is no way (that
> I've been able to find) to get the return code.
Maybe someone has replied to you already on this, but:
FOO=`svn info $URL`
FOO_EXIT_CODE=$?
case $FOO_EXIT_CODE in
1) echo "diffs found" ;;
2) echo "warnings/errors" ;;
*) echo "something completely different"
esac
- C.
--
Cory Omand <co...@blastwave.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by John Belmonte <jo...@neggie.net>.
Julian Foad wrote:
> Therefore, subject to further views on the matter, I propose we change
> to that system.
>
> Here are a few further thoughts on doing so.
>
> If warnings yield 1, should errors yield 2? It is difficult enough
> already for us to decide whether a given circumstance should be treated
> as an error or a warning. We can't reliably and objectively make a
> distinction in many cases, and to produce arbitrary distinctions
> wouldn't help script writers: to know how to handle any failure, they
> need to know exactly what the problem was, not just whether we regarded
> it as "error" or "warning". So errors should also (still) produce exit
> code 1.
>
> Do we need to hold off for backward compatibility? I don't know.
>
> Implementation details: this won't be trivial because we'll need to keep
> track of warnings that are, I think, in some cases produced down in the
> libraries. It might not be difficult, though.
>
> Some commands, such as those whose purpose is to compare or find or test
> something, can have more than one success status, and thus 2 or a higher
> number for the warning/error exit code. E.g. "svn diff" could have 0 if
> no differences found, 1 if differences found, 2 for warnings and/or errors.
>
> I might try to write a concrete proposal for this. We should state it
> in our user documentation.
>
> Apologies for the times I said we should return zero if there are only
> warnings. I did think about it at the time, and was sure of it, but I
> am now convinced otherwise. Any other views?
Hi Julian,
1) Please let's not do the "different return codes for warnings and
error" thing. I've had the experience trying to deal with the tool
"tidy" which does this, and it's very hard to work with, at least from
sh or bash. For example, if you want to capture the tool output with
command substitution (e.g. FOO=`svn info $URL`), there is no way (that
I've been able to find) to get the return code.
2) I disagree that an invalid URL "inside" a repository is only a
warning. As I've said, this is arbitrary from the point of view of the
client. If I'm scripting and all I have is the command line client and
a given URL, how do I determine if that URL is valid or not? In the
past I've used "svn ls", but "svn info" should be usable here to. If ls
returns an error for a URL, shouldn't info do the same? They both
return data about a file on directory node.
--John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 11 Oct 2005, Julian Foad wrote:
> Greg Hudson wrote:
> >
> > That seems overly final. We could change our code to return exit status
> > 1 if there was a warning, or perhaps if no targets succeeded.
> >
...
> Therefore, subject to further views on the matter, I propose we change
> to that system.
>
+1. I think Karl's approach, only distinguishing between 0 and non-zero is
reasonable. The complaints I've seen about this is that warnings produce
zero exit. I haven't heard anyone who wants to make a difference between
error and warning.
> Implementation details: this won't be trivial because we'll need to keep
> track of warnings that are, I think, in some cases produced down in the
> libraries. It might not be difficult, though.
>
The only thing that prints things to stderr s the cmdline client, and it
should know when something is a warning. Some warnings are produced by the
notification system, but that's also under the cmdline client's control.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
>
> That seems overly final. We could change our code to return exit status
> 1 if there was a warning, or perhaps if no targets succeeded.
>
> Other programs have the same issue:
>
> egyptian-gods% ls -d foo blob
> ls: foo: No such file or directory
> blob
> egyptian-gods% echo $status
> 1
>
> egyptian-gods% tar cvf foo.tar foo blob
> tar: foo: Cannot stat: No such file or directory
> blob/
> tar: Error exit delayed from previous errors
> egyptian-gods% echo $status
> 2
> egyptian-gods% ls -l foo.tar
> -rw-r--r-- 1 ghudson mit 10240 Oct 10 12:46 foo.tar
>
> We appear to be unusual in returning exit status 0 on a mix of success
> and failure.
Yikes! Thanks for this revelation.
That system (1 if any warnings, 0 only for clean success) makes sense now that
I think about it. If there are warnings, an interactive user determines
whether the program "succeeded" in doing what he/she wanted by reading them and
making a judgement about whether they are acceptable, and doesn't look at the
exit code. The exit code is for automated use in scripts etc., where any
surprise or failure to do what was requested may well mean the script shouldn't
continue, and if certain warnings _are_ expected then the script writer can
explicitly provide for ignoring them.
Therefore, subject to further views on the matter, I propose we change to that
system.
Here are a few further thoughts on doing so.
If warnings yield 1, should errors yield 2? It is difficult enough already for
us to decide whether a given circumstance should be treated as an error or a
warning. We can't reliably and objectively make a distinction in many cases,
and to produce arbitrary distinctions wouldn't help script writers: to know how
to handle any failure, they need to know exactly what the problem was, not just
whether we regarded it as "error" or "warning". So errors should also (still)
produce exit code 1.
Do we need to hold off for backward compatibility? I don't know.
Implementation details: this won't be trivial because we'll need to keep track
of warnings that are, I think, in some cases produced down in the libraries.
It might not be difficult, though.
Some commands, such as those whose purpose is to compare or find or test
something, can have more than one success status, and thus 2 or a higher number
for the warning/error exit code. E.g. "svn diff" could have 0 if no
differences found, 1 if differences found, 2 for warnings and/or errors.
I might try to write a concrete proposal for this. We should state it in our
user documentation.
Apologies for the times I said we should return zero if there are only
warnings. I did think about it at the time, and was sure of it, but I am now
convinced otherwise. Any other views?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-10-10 at 14:57 +0200, Peter N. Lundblad wrote:
> It can be made a fatal error instead of a warning. My point was that if it
> is not fatal and the client continues with the next target, we can't
> return failure because the next target might succeed.
That seems overly final. We could change our code to return exit status
1 if there was a warning, or perhaps if no targets succeeded.
Other programs have the same issue:
egyptian-gods% ls -d foo blob
ls: foo: No such file or directory
blob
egyptian-gods% echo $status
1
egyptian-gods% tar cvf foo.tar foo blob
tar: foo: Cannot stat: No such file or directory
blob/
tar: Error exit delayed from previous errors
egyptian-gods% echo $status
2
egyptian-gods% ls -l foo.tar
-rw-r--r-- 1 ghudson mit 10240 Oct 10 12:46 foo.tar
We appear to be unusual in returning exit status 0 on a mix of success
and failure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 10 Oct 2005, John Belmonte wrote:
>
>
> Peter N. Lundblad wrote:
> > On Mon, 9 Oct 2005 kfogel@collab.net wrote:
> >
> >
> >>John Belmonte <jo...@neggie.net> writes:
> >>
> >>>>I expect "svn info <URL>" to have a non-zero rcode if the URL is not
> >>>>valid. Seen in version 1.2.3. May I file a bug?
> >>>>
> >>>> $ svn info http://svn.collab.net/repos/svn/bad_url
> >>>> http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
> >>>> $ echo $?
> >>>> 0
> >>>
> > The problem with the return code is that these are handled like warnings,
> > a message is printed and we continue with the next target (but the output
> > is not preceded by svn: warning: as it should). So we can't return a
> > failure status in this case.
>
> Are you saying that you can't correct the return code problem? Surely
It can be made a fatal error instead of a warning. My point was that if it
is not fatal and the client continues with the next target, we can't
return failure because the next target might succeed.
> it's arbitrary (from the point of view of the client) that the case
> above succeeds while the following fails. Any bad URL should fail.
>
> $ svn info http://svn.collab.net/repos/svn_bad
> svn: PROPFIND request failed on '/repos/svn_bad'
> svn: PROPFIND of '/repos/svn_bad': 405 Method Not Allowed
> (http://svn.collab.net)
> $ echo $?
> 1
>
It's not completely arbitrary, since giving an URL that doesn't point to a
repository is fatal, but giving an URL with a non-existent path *inside*
the repository is not. We (inconsistently) treat errors like "not under
version control" and "file does not exist" as non-fatal so you can use
wildcards. When thinking about this, it only seems to make sense for
working copy targets, though. So we could get rid of this for URLs if we
wanted to.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by John Belmonte <jo...@neggie.net>.
Peter N. Lundblad wrote:
> On Mon, 9 Oct 2005 kfogel@collab.net wrote:
>
>
>>John Belmonte <jo...@neggie.net> writes:
>>
>>>>I expect "svn info <URL>" to have a non-zero rcode if the URL is not
>>>>valid. Seen in version 1.2.3. May I file a bug?
>>>>
>>>> $ svn info http://svn.collab.net/repos/svn/bad_url
>>>> http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
>>>> $ echo $?
>>>> 0
>>>
>>>One more thing... the error message above should be on stderr, not stdout.
>>
>>I think this should be a bug, yes -- consider your bug buddied :-).
>>
>>And agree about stderr vs stdout.
>>
>
> In r15065, the warnings were moved from stdout to stderr, so the situation
> on trunk is a little better:-)
>
> The problem with the return code is that these are handled like warnings,
> a message is printed and we continue with the next target (but the output
> is not preceded by svn: warning: as it should). So we can't return a
> failure status in this case.
Hi Peter,
Are you saying that you can't correct the return code problem? Surely
it's arbitrary (from the point of view of the client) that the case
above succeeds while the following fails. Any bad URL should fail.
$ svn info http://svn.collab.net/repos/svn_bad
svn: PROPFIND request failed on '/repos/svn_bad'
svn: PROPFIND of '/repos/svn_bad': 405 Method Not Allowed
(http://svn.collab.net)
$ echo $?
1
--John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 9 Oct 2005 kfogel@collab.net wrote:
> John Belmonte <jo...@neggie.net> writes:
> > > I expect "svn info <URL>" to have a non-zero rcode if the URL is not
> > > valid. Seen in version 1.2.3. May I file a bug?
> > >
> > > $ svn info http://svn.collab.net/repos/svn/bad_url
> > > http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
> > > $ echo $?
> > > 0
> >
> > One more thing... the error message above should be on stderr, not stdout.
>
> I think this should be a bug, yes -- consider your bug buddied :-).
>
> And agree about stderr vs stdout.
>
In r15065, the warnings were moved from stdout to stderr, so the situation
on trunk is a little better:-)
The problem with the return code is that these are handled like warnings,
a message is printed and we continue with the next target (but the output
is not preceded by svn: warning: as it should). So we can't return a
failure status in this case.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by kf...@collab.net.
John Belmonte <jo...@neggie.net> writes:
> > I expect "svn info <URL>" to have a non-zero rcode if the URL is not
> > valid. Seen in version 1.2.3. May I file a bug?
> >
> > $ svn info http://svn.collab.net/repos/svn/bad_url
> > http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
> > $ echo $?
> > 0
>
> One more thing... the error message above should be on stderr, not stdout.
I think this should be a bug, yes -- consider your bug buddied :-).
And agree about stderr vs stdout.
Thanks for noticing,
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn info" good return code on bad URL
Posted by John Belmonte <jo...@neggie.net>.
I wrote:
> I expect "svn info <URL>" to have a non-zero rcode if the URL is not
> valid. Seen in version 1.2.3. May I file a bug?
>
> $ svn info http://svn.collab.net/repos/svn/bad_url
> http://svn.collab.net/repos/svn/bad_url: (Not a valid URL)
> $ echo $?
> 0
One more thing... the error message above should be on stderr, not stdout.
--John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org