[p4] Perforce Return Codes and other headaches

[Weintraub, David]

Do other people hate the fact that the "p4" command returns a zero even
if the command doesn't work?

Yes, I understand that the P4Perl API has P4::Errors() and
P4::Warnings() that allows me to test for errors and warnings, but that
doesn't work in instances where I can't use the P4::Perl API, or if I am
writing a shell script.

This is becoming a big headache in debugging scripts because I'm
constantly coming up with various tests to see if a Perforce command
fails. Triggers are a big problem.


And, while I'm venting:

* When a trigger fails, why does it display STDOUT, and not STDERR like
Subversion does? When a trigger script fails, the output from the error
isn't being displayed because of this.

* It would also be nice if the various sub-commands of "p4" had a few
more parameters. For example, most version control systems I've worked
with have short, long, and verbose output for most of their commands. In
ClearCase, many of the commands had a "-fmt" option that allowed me to
specify the format (and fields) I wanted to output. I'd also like to be
able to specify a few more parameters, like limit the listing of the "p4
clients" command to clients owned by a specific owner, or labels created
after a particular date, or by a particular user.

* I would also like a way to submit changes and other functions without
having to bring up a form. For example:

$ p4 submit -description "This is my description" -force

The "-force" parameter means to submit the changeset without presenting
a form. The "-description" parameter allows me to specify the
description on my changeset. This would make it a lot easier to write
quick little shell scripts since I wouldn't have to be processing forms.

Enough venting for now.

--
David Weintraub
***@bankofamerica.com
***@bofasecurities.com

[Melissa Kacher]

Post by Weintraub, David
Do other people hate the fact that the "p4" command returns a zero

even
if the command doesn't work?

It all depends on how you define "the command doesn't work". Should
"File(s) not opened on this client." be an error, or should it be
considered a successful result, just with a null list of opened files?
Perforce chose the later definition. I can live with it.

Post by Weintraub, David
* When a trigger fails, why does it display STDOUT, and not STDERR

like
Subversion does? When a trigger script fails, the output from the error
isn't being displayed because of this.

I can't say why Perforce chose this method. But when I write a trigger
(for my Windows servers) I always put a 2>&1 after any Perforce command
so that the error will show up in stdout.

Post by Weintraub, David
* I would also like a way to submit changes and other functions

without
having to bring up a form. For example:

See the -i option to submit below. This is how you do an automated
submit in a shell script without invoking a form editor.

C:\>p4 help submit

submit -- Submit open files to the depot

p4 submit [ -r -s ]
p4 submit [ -r -s ] files
p4 submit [ -r ] -c changelist#
p4 submit -i [ -r -s ]

'p4 submit' commits a pending changelist and its files to the
depot.

With no argument 'p4 submit' attempts to submit all files in the
'default' changelist. Submit provides the user with a dialog
similar to 'p4 change' so the user can compose a changelist
description. In this dialog the user is presented with the list
of files open in changelist 'default'. Files may be deleted
from
this list but they cannot be added. (Use an open command (edit,
add, delete) to add additional files to a changelist.)

If a (single) file pattern is given, only those files in
the 'default' changelist that match the pattern will be
submitted.

The -c flag submits the numbered pending changelist that has
been
previously created with 'p4 change' or a failed 'p4 submit'.

The -i flag causes a changelist specification (including files
to be
submitted) to be read from the standard input. The user's
editor
is not invoked.

The -r flag allows submitted files to remain open (on the
client's
default changelist) after the submit has completed.

The -s flag extends the list of jobs to include the fix status
for each job, which becomes the job's status when the changelist
is committed. See 'p4 help change' for more notes on this
option.

Before committing a changelist submit locks all associated files
not
already locked. If any file cannot be locked, or if the submit
fails for any other reason the files are left open in a newly
created pending changelist.

Submit is guaranteed to be atomic. Either all files will be
updated in the depot as a unit or none will be.



Thanks,
Melissa


-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Weintraub,
David
Sent: Thursday, June 08, 2006 1:30 PM
To: perforce-***@perforce.com
Subject: [p4] Perforce Return Codes and other headaches

Do other people hate the fact that the "p4" command returns a zero even
if the command doesn't work?

Yes, I understand that the P4Perl API has P4::Errors() and
P4::Warnings() that allows me to test for errors and warnings, but that
doesn't work in instances where I can't use the P4::Perl API, or if I am
writing a shell script.

This is becoming a big headache in debugging scripts because I'm
constantly coming up with various tests to see if a Perforce command
fails. Triggers are a big problem.


And, while I'm venting:

* When a trigger fails, why does it display STDOUT, and not STDERR like
Subversion does? When a trigger script fails, the output from the error
isn't being displayed because of this.

* It would also be nice if the various sub-commands of "p4" had a few
more parameters. For example, most version control systems I've worked
with have short, long, and verbose output for most of their commands. In
ClearCase, many of the commands had a "-fmt" option that allowed me to
specify the format (and fields) I wanted to output. I'd also like to be
able to specify a few more parameters, like limit the listing of the "p4
clients" command to clients owned by a specific owner, or labels created
after a particular date, or by a particular user.

* I would also like a way to submit changes and other functions without
having to bring up a form. For example:

$ p4 submit -description "This is my description" -force

The "-force" parameter means to submit the changeset without presenting
a form. The "-description" parameter allows me to specify the
description on my changeset. This would make it a lot easier to write
quick little shell scripts since I wouldn't have to be processing forms.

Enough venting for now.

--
David Weintraub
***@bankofamerica.com
***@bofasecurities.com
_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Jeff Grills]

Yes, the lack of useful return codes has annoyed many on this list.

Many p4 commands will format their output differently (and much more
friendly to automated processing) if you specify -ztag as a command line
option. This is particularly useful for output that may have embedded
spaces which is otherwise extremely difficult to parse. Some commands even
give you additional information (well, that information was provided by the
server, but the p4 client has just chosen to not display it).

Every p4 command that I can think of that presents a form can instead take
that data directly from stdin using the -i command line parameter - that's
basically how the GUI tools work. It would be nice if perforce could
somehow build the form data for you to simplify some scripting tasks,
perhaps with some multiple argument command line option like:

p4 submit -form Description "This is my description"

Unfortunately that breaks down for fields that take multiple lines of data,
like the Files: section of the submit form. Perhaps someone would have a
better idea that could be implemented and used in a reasonably easy fashion.
Even if something like that could be built, it is probably best implemented
as an external program that formats the form's data that would then be piped
into "p4 -i". Perforce seems to want to keep the p4 client small and
lightweight, and I too think that's a great goal.

j

-----Original Message-----
From: perforce-user-***@perforce.com
[mailto:perforce-user-***@perforce.com] On Behalf Of Weintraub, David
Sent: Thursday, June 08, 2006 3:30 PM
To: perforce-***@perforce.com
Subject: [p4] Perforce Return Codes and other headaches


Do other people hate the fact that the "p4" command returns a zero even if
the command doesn't work?

Yes, I understand that the P4Perl API has P4::Errors() and
P4::Warnings() that allows me to test for errors and warnings, but that
doesn't work in instances where I can't use the P4::Perl API, or if I am
writing a shell script.

This is becoming a big headache in debugging scripts because I'm constantly
coming up with various tests to see if a Perforce command fails. Triggers
are a big problem.


And, while I'm venting:

* When a trigger fails, why does it display STDOUT, and not STDERR like
Subversion does? When a trigger script fails, the output from the error
isn't being displayed because of this.

* It would also be nice if the various sub-commands of "p4" had a few more
parameters. For example, most version control systems I've worked with have
short, long, and verbose output for most of their commands. In ClearCase,
many of the commands had a "-fmt" option that allowed me to specify the
format (and fields) I wanted to output. I'd also like to be able to specify
a few more parameters, like limit the listing of the "p4 clients" command to
clients owned by a specific owner, or labels created after a particular
date, or by a particular user.

* I would also like a way to submit changes and other functions without
having to bring up a form. For example:

$ p4 submit -description "This is my description" -force

The "-force" parameter means to submit the changeset without presenting a
form. The "-description" parameter allows me to specify the description on
my changeset. This would make it a lot easier to write quick little shell
scripts since I wouldn't have to be processing forms.

Enough venting for now.

--
David Weintraub
***@bankofamerica.com ***@bofasecurities.com

[G. Matthew Rice]

Post by Weintraub, David
* When a trigger fails, why does it display STDOUT, and not STDERR like
Subversion does? When a trigger script fails, the output from the error
isn't being displayed because of this.

Unless I'm completely out to lunch, any output STDOUT or STDERR _used_ to get
returned. However, with version 2005.2 (and maybe a little earlier) and
later it is just displaying STDOUT's messages. I don't know why it changed.

Post by Weintraub, David
* I would also like a way to submit changes and other functions without
$ p4 submit -description "This is my description" -force
The "-force" parameter means to submit the changeset without presenting
a form. The "-description" parameter allows me to specify the
description on my changeset. This would make it a lot easier to write
quick little shell scripts since I wouldn't have to be processing forms.

You could write a script that would build up a form and run 'p4 submit -i'
(or p4 change/p4 submit -c xxx) to make it automatic.

I agree that some of these things would be nice features. All I can suggest
is that you send the feature requests to ***@perforce.com. They'll add
you to the list of people that want the same features and, I hear, they do
consider the popularity of each request in their planning. <vote early, vote
often>.

Regards,

[Robert Cowham]

Post by Weintraub, David
Do other people hate the fact that the "p4" command returns a
zero even if the command doesn't work?

Not one of my favourite features.

Perforce is rather inconsistent. It was suggested to me when I first started
developing P4OFC to do things like an fstat after a command has been
implemented and check that the result was what I was expecting. In some
cases this has been well worth it.

One extra thing from the command line:

P4 -s <command>

E.g.

C:\bruno_ws>p4 -s files //depot/main/jam/jam...
info: //depot/main/jam/jam.1#36 - delete change 582 (text)
info: //depot/main/jam/jam.1.html#4 - delete change 620 (text)
info: //depot/main/jam/jam.c#36 - edit change 721 (text)
:
info: //depot/main/jam/jamMR.html#5 - delete change 620 (text)
exit: 0

C:\bruno_ws>p4 -s files //depot/main/jam/jamasdf...
error: //depot/main/jam/jamasdf... - no such file(s).
exit: 0


Thus you can parse for "error:" and "warning:" - as you can see above exit
code is still 0 for an error situation!

This whole error checking, and also error codes thing has long been a
weakness. Also the format of return strings etc - the inability to translate
them for example without breaking lots of stuff. (Minor nit - things like
"p4 lock" returns "locking" even though at that point it is locked!). If
Perforce were to do a rewrite without worrying about breaking backward
compatibility, I think they would reconsider in this area...

Post by Weintraub, David
Yes, I understand that the P4Perl API has P4::Errors() and
P4::Warnings() that allows me to test for errors and
warnings, but that doesn't work in instances where I can't
use the P4::Perl API, or if I am writing a shell script.
This is becoming a big headache in debugging scripts because
I'm constantly coming up with various tests to see if a
Perforce command fails. Triggers are a big problem.
* When a trigger fails, why does it display STDOUT, and not
STDERR like Subversion does? When a trigger script fails, the
output from the error isn't being displayed because of this.

[Weintraub, David]

I just talked to Perforce about these issues:

* ALWAYS RETURNING A ZERO EXIT CODE EVEN WHEN THE COMMAND "DIDN'T WORK"
There is a feeling that if a p4 command returns a non-zero return code,
you *might* assume that Perforce had an error.

This of course is not what a non-zero error code means. A non-zero error
code means that the results that were returned might have been
unexpected. If you grep for a non-existent string in a file, grep will
return an error code of 1. If the file doesn't exist, or can't be
opened, grep returns an error code of 2. This behavior is documented in
the manpage. If you "ls" a file that doesn't exist, "ls" returns an
error code of "2".

* LACK OF COMMAND LINE OPTIONS
There has been a concerted effort at Perforce to limit the number of
command line parameters in order to keep the commands from getting
overly complex.

But, this doesn't make sense. If I run a command without options, you
revert to the default behavior, and no one would notice any problems.
However, if I need something a bit different, the command line option
would be available. If nothing else, it would be nice if listing
commands took a "-short" parameter which would limit their output to the
main information requested.

For example "p4 labels" lists the label, the date it was created, and
the description. It would be nice if "p4 labels -short" only listed the
label name. It would also be nice if these various listing commands like
"p4 labels" and "p4 clients" took a single label or client name like "p4
labels -short FOO_LABEL" which would list FOO_LABEL if it existed (and
maybe return a non-zero error code if label FOO_LABEL didn't exist).

* THE ABILITY TO USE COMMAND LINE PARAMETERS INSTEAD OF PERFORCE FORMS
The biggie is the "p4 submit" command. 90% of the time, all I want to do
is submit the files that are already on the changelist, and I simply
want to add the description.

Instead, I must do a "p4 change -o", filter for the "Description:" line,
add my description without changing anything else in the file, then
resubmit this with the "p4 submit -i". Being able to say "p4 submit
-desc 'This is my description'" would save a lot of headaches.

Believe it or not, the support person I talked to was extremely familiar
with all these issues, and has also complained about them. However,
there are people high up in Perforce who feel strongly about these
issues in the other direction, and that's why things are the way they
are.

He did tell me that if enough people also voice these concerns, Perforce
will change its mind and possibly implement some of these ideas.

So if you have similar feelings about these issues, please call up
Perforce Support and register your complaint. Perforce's support phone
number is 1-510-864-7400.



________________________________

From: Weintraub, David
Sent: Thursday, June 08, 2006 4:30 PM
To: perforce-***@perforce.com
Subject: Perforce Return Codes and other headaches


Do other people hate the fact that the "p4" command returns a
zero even if the command doesn't work?

Yes, I understand that the P4Perl API has P4::Errors() and
P4::Warnings() that allows me to test for errors and warnings, but that
doesn't work in instances where I can't use the P4::Perl API, or if I am
writing a shell script.

This is becoming a big headache in debugging scripts because I'm
constantly coming up with various tests to see if a Perforce command
fails. Triggers are a big problem.


And, while I'm venting:

* When a trigger fails, why does it display STDOUT, and
not STDERR like Subversion does? When a trigger script fails, the output
from the error isn't being displayed because of this.

* It would also be nice if the various sub-commands of "p4" had
a few more parameters. For example, most version control systems I've
worked with have short, long, and verbose output for most of their
commands. In ClearCase, many of the commands had a "-fmt" option that
allowed me to specify the format (and fields) I wanted to output. I'd
also like to be able to specify a few more parameters, like limit the
listing of the "p4 clients" command to clients owned by a specific
owner, or labels created after a particular date, or by a particular
user.

* I would also like a way to submit changes and other functions
without having to bring up a form. For example:

$ p4 submit -description "This is my description" -force

The "-force" parameter means to submit the changeset without
presenting a form. The "-description" parameter allows me to specify the
description on my changeset. This would make it a lot easier to write
quick little shell scripts since I wouldn't have to be processing forms.

Enough venting for now.

--
David Weintraub
***@bankofamerica.com
***@bofasecurities.com

[Ivey, William]

Post by Melissa Kacher
-----Original Message-----
Weintraub, David

[...]

Post by Melissa Kacher
* LACK OF COMMAND LINE OPTIONS
There has been a concerted effort at Perforce to limit the number of
command line parameters in order to keep the commands from getting
overly complex.

That's understandable - each additional option adds maintenance,
support and documentation costs to the command. On the other hand,
if they solve problems that have resulted in calls to support, or
customers just find really annoying, it's usually worth it.

To keep things reasonable for p4 help, that command could have an
option which would display help for less common options.

-Wm