[p4] Scripting with perforce, pitafalls ...

[Looney, James B (N-ULA)]

If you're scripting with a language which knows how to handle marshaled
data, I recommend using the -G option with the client.  I use Python
myself.  If you do that, part of the returned data is usually a field
called 'code'.  'code' will tell you directly whether or not it's an
error.

-James

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jeff 
> A. Bowles
> Sent: Monday, March 03, 2008 9:08 AM
> To: Ildefonzo Arocha
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Scripting with perforce, pitafalls ...
> 
> Step on: know what tools are available for the script writer.
> Option #1:  normal 'p4' command usage.
> 
> 
> Example:  "p4 sync" / "p4 files" / "p4 submit -i"
> 
> 
> Good/bad:
> 
> 
>    - simple, but you are parsing formatted output.
>    - Filenames with embedded spaces are headaches.
>    - Getting status / success-fail is harder.
> 
> Option #2: Use "p4 -s" for easier status / success-fail processing.
> 
> Example:  "p4 -s sync" / "p4 -s files"
> 
> 
> Good/bad:
> 
> 
>    - simple, but you are parsing formatted output.
>    - Filenames with embedded spaces are headaches.
>    - Getting status / success-fail is slightly easier. You 
> still need to
>    decide whether the command worked or not. ("Exit status" 
> from the 'p4' tells
>    you whether the protocol worked, not whether the command 
> worked, so '-s'
>    helps.)
> 
> Option #3: Read up on tagged output.
> 
> Example:  "p4 -Ztag  sync" / "p4 -Ztag files"
> 
> 
> Good/bad:
> 
> 
> 
>    - Output is name/value pairs, far easier to parse.
>    - Filenames with embedded spaces are easier to parse / work with.
>    - Many (nearly all) examples of tagged output are 
> parseable easily in
>    Perl.
>    - "p4 -Ztag describe" is a bit of a nuisance if the description is
>    multiple paragraphs. (You'll see why.)
>    - Getting status / success-fail is slightly easier. Still, 
> sometimes
>    an error or warning will appear as a single formatted 
> string to pass to the
>    user, and you cannot decide without parsing the string, if 
> it was a warning
>    or an error.
> 
> 
> I would say that "tagged output" is your best choice, right now.
> 
>    -Jeff Bowles
> 
> ps. If you can write in Python or Ruby, the "p4 -G / p4 -R" 
> output (it's
> binary, don't try this without redirecting the output!) is the best
> possibility.  You still have to deal with "was that a success 
> or failure?"
> but the parsing work is far better than anything in ASCII.
> 
> 
> On Mon, Mar 3, 2008 at 1:14 AM, Ildefonzo Arocha 
> <ilde.web at gmail.com> wrote:
> 
> > Hello Perforcers,
> >
> > Is it me or does anyone else find that even for the simplest task,
> > scripts have to handle and validate a lot of possible 
> errors/warnings.
> >
> > I am relatively new with Perforce.  In the last months I have been
> > developing some administrative and end-users scripts.  It has been a
> > challange though, no matter what I do, there is always some little
> > detail that makes my scripts fail.
> >
> > On some situations some warnings are sent out as 
> information messages
> > so parsing the output for "error" is not possible, same examples:
> >
> > > p4 -s add -n project.r
> > error: project.r - protected namespace - access denied.
> > exit: 0
> > ==> OK
> >
> > > p4 -s add project.xml
> > error: project.xml - file(s) not in client view.
> > exit: 0
> > ==> OK
> >
> > > p4 -s add -n test.p
> > info: //xp/i2/main/ui/test.p#1 - opened for add
> > info1: //xp/i2/main/ui/test.p - also opened by iar at main
> > exit: 0
> > ==> Not Ok?
> >
> > > p4 -s add test.p
> > info: //xp/i2/main/ui/test.p#1 - currently opened for add
> > exit: 0
> > ==> Not Ok?
> >
> > > p4 -s add -n ui/polylayout/LayoutLL/aadtgend02.lst
> > info: //xp/i2/main/ui/polylayout/LayoutLL/aadtgend02.lst - can't add
> > existing file
> > exit: 0
> > ==> Not Ok?
> >
> > > p4 -s edit -n ui/polylayout/LayoutLL/aadtgend02.lst
> > info: //xp/i2/main/ui/polylayout/LayoutLL/aadtgend02.lst - 
> can't edit
> > exclusive file already opened
> > info1: //xp/i2/main/ui/polylayout/LayoutLL/aadtgend02.lst - also
> > opened by vim at main
> > exit: 0
> > ==> Not OK?
> >
> > > p4 -s sync -n
> > error: File(s) up-to-date.
> > exit: 0
> > ==> Not OK?
> >
> > I have had several different situations, can't remember 
> them all, the
> > most recent had to do with a script the performs a "intergrate -n -b
> > ..." to list all missing revisions from a branch to another.  I
> > inadvertively changed something in the Protection Table, the script
> > then returned no results.  After some digging around I 
> found out that:
> >
> > > p4 -s -c "batch" integrate -n -r -b B_PRA
> > error: No permission for operation on file(s).
> > exit: 0
> > ==> OK, interpret as an error
> >
> > > p4 -s integrate -n -b B_5.01.04 -s 
> "//xp/i2/main/ui/... at 19026, at 19026"
> > error: //xp/i2/main/ui/... at 19026, at 19026 - all revision(s) already
> > integrated.
> > exit: 0
> > ==> Arguably I wouldn't consider this an error, but is this 
> behaviour
> > consistant?
> >
> > This last one is quite contradicting, you can argue that the
> > "integrate" command was not succesful hence "error" but then on the
> > examples above ("p4add" and "p4 edit") the commands are not 
> succesful
> > either, however it outputs "info".
> >
> > Because of this, I have been in the need to send the output 
> of each p4
> > command to some temporal file, analyze it for info messages 
> and error
> > messages and selectively ignore what is error and what is not.  Hard
> > coding error messages in a script is not something I like to do, and
> > since I don't know in advance all possible message 
> combination, I have
> > to do corrections on the scripts upon users feedback.  A major
> > annoyance, not to mention unproductive.
> >
> > Thoughts anyone?
> >
> > Regards,
> > Ildefonzo
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> 
> 
> 
> -- 
> ---
> Jeff Bowles - jeff.a.bowles at gmail.com
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>