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
Received on Wed Oct 12 17:54:07 2005