|David Ferguson||Aug 7, 2003 5:10 pm|
|Cris Holdorph||Aug 7, 2003 5:23 pm|
|Jason Williams||Aug 7, 2003 5:31 pm|
|David Ferguson||Aug 7, 2003 5:35 pm|
|David Foglesong||Aug 7, 2003 9:39 pm|
|Grills, Jeff||Aug 7, 2003 10:26 pm|
|David Foglesong||Aug 7, 2003 11:00 pm|
|Robert Cowham||Aug 8, 2003 3:07 am|
|Robert Cowham||Aug 8, 2003 3:10 am|
|Chuck Karish||Aug 9, 2003 11:37 am|
|Subject:||[p4] Return codes|
|From:||Robert Cowham (rob...@vaccaperna.co.uk)|
|Date:||Aug 8, 2003 3:07:19 am|
This problem goes way back - see my presentation on the API at the 2001 User Conference.
However, there have been some advances. If you look at the Ruby/Perl APIs (by Tony Smith), and now the COM API I have implemented, there is the concept of warnings.
C:\bruno_ws\main\jam>irb irb(main):001:0> require "P4" => true irb(main):002:0> p4 = P4.new => #<P4:0x2841be8> irb(main):003:0> p4.connect => true irb(main):004:0> p p4.run("sync") P4Exception: [P4#run] Warnings during command execution( "p4 sync" ) from (irb):4:in `run' from (irb):4 irb(main):005:0> p p4.warnings ["File(s) up-to-date.\n"] => nil irb(main):006:0> p p4.run("integ", "jam...", "new...") ["//depot/main/jam/new.c - can't delete from //depot/main/jam/jam.c#45 without -d flag"] => nil irb(main):007:0>
Thus you can see that synching with no files to sync generates a warning, but the situation you are talking about doesn't - it is considered informational only. In my scripts I typically ignore warnings (though not always), and rely on exceptions for errors.
This occurs in other places as well, so warnings are only useful in some cases. You might disagree with Perforce on the definition of what is a warning and what isn't - this should be taken up with support on a case by case basis I think (and in this instance I think I would support you!). Basically I think Perforce is heading in this direction, and also looking at returning specific error codes to be checked rather than having to parse (especially with the possibility of translated texts coming back). However, it's difficult technically, and there is a way to go yet.
Basically, you need to work out by trial and error, and parse output in some instances, trap warnings or errors in others.
As a tip, for some commands, it is useful to execute an fstat afterwards to detect if the required change has happened (rather than parsing myriad potential alternatives).
Good luck! Robert
-----Original Message----- From: perforce-user-admin at perforce.com [mailto:perforce-user-admin at perforce.com] On Behalf Of David Foglesong Sent: 08 August 2003 07:01 To: perforce-user at perforce.com; David Ferguson; Grills, Jeff Subject: Re: [p4] Return codes
Once upon a time, I discussed this with support and they provided the "return code 1 = malformed command" explanation. I played with it some, and it seemed correct, since valid (but wrong) commands would return 0.
But you're right -- attempting to submit a non-existent file gives a return code of 1. (Never tried that one before!) Which means there are doubtless other examples where it does the same thing.
Why? Who knows... yet another example of why the return code is (basically) useless for determining if the command actually succeeded or not.
----- Original Message ----- From: "Grills, Jeff" <jgrills at soe.sony.com> To: "'David Foglesong'" <defoglesong at msn.com>; <perforce-user at perforce.com>; "David Ferguson" <daf at vmware.com> Sent: Thursday, August 07, 2003 10:26 PM Subject: RE: [p4] Return codes
I've certainly seen commands fail and return an error code. For instance, if a p4 submit fails, I know I get a non-zero return value.
-----Original Message----- From: David Foglesong [mailto:defoglesong at msn.com] Sent: Thursday, August 07, 2003 11:39 PM To: perforce-user at perforce.com; David Ferguson Subject: Re: [p4] Return codes
The return code from p4 indicates whether you've issued a *valid* command, not whether the command was successful. That is:
C:\>p4 -s foo error: Unknown command. Try 'p4 help' for info. exit: 1
C:\>p4 -s print foo.txt error: foo.txt - no such file(s). exit: 0
You might consider the second example to be an error (and the -s flag does include an error message) but it is a valid command, hence the exit of 0.
----- Original Message ----- From: "David Ferguson" <daf at vmware.com> To: <perforce-user at perforce.com> Sent: Thursday, August 07, 2003 5:10 PM Subject: [p4] Return codes
Does anybody else want P4 commands to return errors if something bad happens?
Specifically, I have a script that tries to interpret the results of an 'integrate' for completeness. I'm really hoping that the return code indicates whether the command was successful or not. It doesn't. Assume Branch A with files Moe, Larry, Curly Assume Branch B was created from A and has the same files. Remove A's version of Moe. Modify B's version of Moe and Larry. in A, run p4 integrate -b B -r ...
The output will include a successful string for Larry, but a variation of .../Moe - can't branch from ...B/Moe without -d flag which is fine and dandy if you're reading the output BUT
the actual command returns '0'.
I want it to return 1 indicating the integration encountered a problem. This way, my scripts don't have to trap for every possible error message, many of which I can't know the format of until they occur.
In my case, I have a merge script that 'successfully' merged changesets even though files in the changeset didn't exist in the merge-to branch. I've trapped for this particular case now, but am wondering what else is out there...
_______________________________________________ perforce-user mailing list - perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user