{"thread":{"id":"33525","subject":"is git-p4 compatible with p4/linux?","startedAt":"2013-04-17T04:31:36Z","lastAt":"2013-04-20T13:22:33Z","messageCount":8,"participants":["Alexander Tomlinson","Pete Wyckoff","Alex Tomlinson","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"214568","messageId":"7BF81DF9-941D-400B-8304-6DA5F5C82D4F@aivor.com","threadId":"33525","inReplyTo":null,"subject":"is git-p4 compatible with p4/linux?","fromName":"Alexander Tomlinson","fromEmail":"alex@aivor.com","sentAt":"2013-04-17T04:31:36Z","receivedAt":"2013-04-17T04:31:36Z","isPatch":false,"sender":{"key":"alex@aivor.com","avatar":null},"body":"git-p4.py (1.8.2.1.418.gaec3f77) has at least two behaviors that\nseem to be incompatible with the version of p4 that I recently\ndownloaded from perforce.com (P4/LINUX26X86_64/2013.1/610569).\n\nTLDR: Is git-p4 written for an old version of p4 CLI with different\nbehavior?  Or for a windows or mac release of p4?  Or am I missing\nsomething?\n\nFirst issue\n-----------\n\ngit-p4 assumes the output of 'p4 print' adds a newline to the\ntarget.  To work around this, git-p4.py strips the last char from\nsymlinks as shown in the following snippet:\n\n    if type_base =3D=3D \"symlink\":\n        git_mode =3D \"120000\"\n        # p4 print on a symlink contains \"target\\n\"; remove the newline\n        data =3D ''.join(contents)\n        contents =3D [data[:-1]]\n\nBut my 'p4 print' does not output the newline:\n\n    $ ls -l pcre\n    lrwxrwxrwx 1 user group 12 Apr 16 10:27 pcre -> ../libs/pcre\n\n    $ p4 print -q pcre | od -t x1a\n    0000000  2e  2e  2f  6c  69  62  73  2f  70  63  72  65\n             .   .   /   l   i   b   s   /   p   c   r   e\n    0000014\n\nIf I use 'git p4 clone' the above file shows up in git as a\nsymlink to '../libs/pcr'.  I had another symlink whose target had\na strlen of 1 and the 'git p4 clone' failed b/c after stripping\nthe last char the result was an empty string.\n\nSecond issue\n------------\n\ngit-p4 uses 'p4 print -q -o o FILE' to print a file to stdout.\nAt least that is how I interpret this snippet:\n\n    text = p4_read_pipe(['print', '-q', '-o', '-', file['depotFile']])\n\nHowever, p4/Linux prints to stdout by default and '-o -' will save\nthe output in a file named '-'.\n\nMy git and p4 versions:\n\n    $ git --version\n    git version 1.8.2.1.418.gaec3f77\n\n    $ p4 -V\n    Perforce - The Fast Software Configuration Management System.\n    Copyright 1995-2013 Perforce Software.  All rights reserved.\n    This product includes software developed by the OpenSSL Project\n    for use in the OpenSSL Toolkit (http://www.openssl.org/)\n    See 'p4 help legal' for full OpenSSL license information\n    Version of OpenSSL Libraries: OpenSSL 1.0.1c 10 May 2012\n    Rev. P4/LINUX26X86_64/2013.1/610569 (2013/03/19).\n\n--Alex\n"},{"id":"214569","messageId":"278B6790-7EDC-4E7F-A944-B00A6AEE86F2@aivor.com","threadId":"33525","inReplyTo":"7BF81DF9-941D-400B-8304-6DA5F5C82D4F@aivor.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"Alexander Tomlinson","fromEmail":"alex@aivor.com","sentAt":"2013-04-17T04:37:36Z","receivedAt":"2013-04-17T04:37:36Z","isPatch":false,"sender":{"key":"alex@aivor.com","avatar":null},"body":"Sorry about the =3D escapes.  My first attempt to submit bounced b/c it was html and I missed\ncleaning some escapes.  The snippet should be:\n\n    if type_base == \"symlink\":\n        git_mode = \"120000\"\n        # p4 print on a symlink contains \"target\\n\"; remove the newline\n        data = ''.join(contents)\n        contents = [data[:-1]]\n\n\n--Alex\n"},{"id":"214787","messageId":"20130419000947.GB9048@padd.com","threadId":"33525","inReplyTo":"7BF81DF9-941D-400B-8304-6DA5F5C82D4F@aivor.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2013-04-19T00:09:47Z","receivedAt":"2013-04-19T00:09:47Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"alex@aivor.com wrote on Tue, 16 Apr 2013 23:31 -0500:\n> git-p4.py (1.8.2.1.418.gaec3f77) has at least two behaviors that\n> seem to be incompatible with the version of p4 that I recently\n> downloaded from perforce.com (P4/LINUX26X86_64/2013.1/610569).\n> \n> TLDR: Is git-p4 written for an old version of p4 CLI with different\n> behavior?  Or for a windows or mac release of p4?  Or am I missing\n> something?\n\nI had not done any testing beyond p4 12.2 (linux).  But running\nthe unit tests through 13.1 just now, they all pass.\n\n    $ p4 -V\n    Perforce - The Fast Software Configuration Management System.\n    Copyright 1995-2013 Perforce Software.  All rights reserved.\n    This product includes software developed by the OpenSSL Project\n    for use in the OpenSSL Toolkit (http://www.openssl.org/)\n    See 'p4 help legal' for full OpenSSL license information\n    Version of OpenSSL Libraries: OpenSSL 1.0.1c 10 May 2012\n    Rev. P4/LINUX26X86_64/2013.1/610569 (2013/03/19).\n\nI'm using python 2.7.3.\n\n> First issue\n> -----------\n> \n> git-p4 assumes the output of 'p4 print' adds a newline to the\n> target.  To work around this, git-p4.py strips the last char from\n> symlinks as shown in the following snippet:\n> \n>     if type_base =3D=3D \"symlink\":\n>         git_mode =3D \"120000\"\n>         # p4 print on a symlink contains \"target\\n\"; remove the newline\n>         data =3D ''.join(contents)\n>         contents =3D [data[:-1]]\n> \n> But my 'p4 print' does not output the newline:\n> \n>     $ ls -l pcre\n>     lrwxrwxrwx 1 user group 12 Apr 16 10:27 pcre -> ../libs/pcre\n> \n>     $ p4 print -q pcre | od -t x1a\n>     0000000  2e  2e  2f  6c  69  62  73  2f  70  63  72  65\n>              .   .   /   l   i   b   s   /   p   c   r   e\n>     0000014\n> \n> If I use 'git p4 clone' the above file shows up in git as a\n> symlink to '../libs/pcr'.  I had another symlink whose target had\n> a strlen of 1 and the 'git p4 clone' failed b/c after stripping\n> the last char the result was an empty string.\n\nThere wasn't an explict test for symlinks, but I threw\none together quickly and it seems to work.  Can you show\na bit more information about anything that potentially might\nbe odd with your install?\n\n    arf-git-test$ ls -l symlink\n    lrwxrwxrwx 1 pw pw 14 Apr 18 20:02 symlink -> symlink-target\n\n    $ p4 fstat symlink\n    ... depotFile //depot/symlink\n    ... clientFile /run/shm/trash directory.t9802-git-p4-filetype/cli/symlink\n    ... isMapped \n    ... headAction add\n    ... headType symlink\n    ... headTime 1366329740\n    ... headRev 1\n    ... headChange 6\n    ... headModTime 1366329740\n    ... haveRev 1\n\n    $ p4 print -q symlink | od -t x1a\n    0000000  73  79  6d  6c  69  6e  6b  2d  74  61  72  67  65  74  0a\n\t      s   y   m   l   i   n   k   -   t   a   r   g   e   t  nl\n    0000017\n\nNo idea why I get an \"nl\" but you do not.  If you run _without_\nthe \"| od ...\", then the shell prompt ends up on the same line\nas the output?  Any interesting shell or shell settings?\n\n> Second issue\n> ------------\n> \n> git-p4 uses 'p4 print -q -o o FILE' to print a file to stdout.\n> At least that is how I interpret this snippet:\n> \n>     text = p4_read_pipe(['print', '-q', '-o', '-', file['depotFile']])\n> \n> However, p4/Linux prints to stdout by default and '-o -' will save\n> the output in a file named '-'.\n> \n> My git and p4 versions:\n> \n>     $ git --version\n>     git version 1.8.2.1.418.gaec3f77\n> \n>     $ p4 -V\n>     Perforce - The Fast Software Configuration Management System.\n>     Copyright 1995-2013 Perforce Software.  All rights reserved.\n>     This product includes software developed by the OpenSSL Project\n>     for use in the OpenSSL Toolkit (http://www.openssl.org/)\n>     See 'p4 help legal' for full OpenSSL license information\n>     Version of OpenSSL Libraries: OpenSSL 1.0.1c 10 May 2012\n>     Rev. P4/LINUX26X86_64/2013.1/610569 (2013/03/19).\n\nThis code only happens on utf16 files.  But running it by hand,\nI cannot reproduce the different behavior:\n\n    $ p4 print -q //depot/f-ascii\n    three\n    line\n    text\n\n    $ p4 print -o - -q //depot/f-ascii\n    three\n    line\n\n    $ ls ./-\n    ls: cannot access ./-: No such file or directory\n\nI'm again confused.  Any hints you can give would be helpful.\n\n\t\t-- Pete\n"},{"id":"214791","messageId":"14D98038-C656-47B9-ABF2-CC12914F0C75@aivor.com","threadId":"33525","inReplyTo":"20130419000947.GB9048@padd.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"Alexander Tomlinson","fromEmail":"alex@aivor.com","sentAt":"2013-04-19T01:34:40Z","receivedAt":"2013-04-19T01:34:40Z","isPatch":false,"sender":{"key":"alex@aivor.com","avatar":null},"body":"\nOn Apr 18, 2013, at 7:09 PM, Pete Wyckoff <pw@padd.com> wrote:\n\n> alex@aivor.com wrote on Tue, 16 Apr 2013 23:31 -0500:\n>> git-p4.py (1.8.2.1.418.gaec3f77) has at least two behaviors that\n>> seem to be incompatible with the version of p4 that I recently\n>> downloaded from perforce.com (P4/LINUX26X86_64/2013.1/610569).\n>> \n>> TLDR: Is git-p4 written for an old version of p4 CLI with different\n>> behavior?  Or for a windows or mac release of p4?  Or am I missing\n>> something?\n> \n> I had not done any testing beyond p4 12.2 (linux).  But running\n> the unit tests through 13.1 just now, they all pass.\n> \n>    $ p4 -V\n>    Perforce - The Fast Software Configuration Management System.\n>    Copyright 1995-2013 Perforce Software.  All rights reserved.\n>    This product includes software developed by the OpenSSL Project\n>    for use in the OpenSSL Toolkit (http://www.openssl.org/)\n>    See 'p4 help legal' for full OpenSSL license information\n>    Version of OpenSSL Libraries: OpenSSL 1.0.1c 10 May 2012\n>    Rev. P4/LINUX26X86_64/2013.1/610569 (2013/03/19).\n> \n> I'm using python 2.7.3.\n> \n>> First issue\n>> -----------\n>> \n>> git-p4 assumes the output of 'p4 print' adds a newline to the\n>> target.  To work around this, git-p4.py strips the last char from\n>> symlinks as shown in the following snippet:\n>> \n>>    if type_base =3D=3D \"symlink\":\n>>        git_mode =3D \"120000\"\n>>        # p4 print on a symlink contains \"target\\n\"; remove the newline\n>>        data =3D ''.join(contents)\n>>        contents =3D [data[:-1]]\n>> \n>> But my 'p4 print' does not output the newline:\n>> \n>>    $ ls -l pcre\n>>    lrwxrwxrwx 1 user group 12 Apr 16 10:27 pcre -> ../libs/pcre\n>> \n>>    $ p4 print -q pcre | od -t x1a\n>>    0000000  2e  2e  2f  6c  69  62  73  2f  70  63  72  65\n>>             .   .   /   l   i   b   s   /   p   c   r   e\n>>    0000014\n>> \n>> If I use 'git p4 clone' the above file shows up in git as a\n>> symlink to '../libs/pcr'.  I had another symlink whose target had\n>> a strlen of 1 and the 'git p4 clone' failed b/c after stripping\n>> the last char the result was an empty string.\n> \n> There wasn't an explict test for symlinks, but I threw\n> one together quickly and it seems to work.  Can you show\n> a bit more information about anything that potentially might\n> be odd with your install?\n> \n>    arf-git-test$ ls -l symlink\n>    lrwxrwxrwx 1 pw pw 14 Apr 18 20:02 symlink -> symlink-target\n> \n>    $ p4 fstat symlink\n>    ... depotFile //depot/symlink\n>    ... clientFile /run/shm/trash directory.t9802-git-p4-filetype/cli/symlink\n>    ... isMapped \n>    ... headAction add\n>    ... headType symlink\n>    ... headTime 1366329740\n>    ... headRev 1\n>    ... headChange 6\n>    ... headModTime 1366329740\n>    ... haveRev 1\n> \n>    $ p4 print -q symlink | od -t x1a\n>    0000000  73  79  6d  6c  69  6e  6b  2d  74  61  72  67  65  74  0a\n> \t      s   y   m   l   i   n   k   -   t   a   r   g   e   t  nl\n>    0000017\n> \n> No idea why I get an \"nl\" but you do not.  If you run _without_\n> the \"| od ...\", then the shell prompt ends up on the same line\n> as the output?  Any interesting shell or shell settings?\n> \n\nYes.  The shell prompt is on the same line as the output:\n\n$ PS1=\"FOOBAR$\"\nFOOBAR$p4 print -q pcre\n../libs/pcreFOOBAR$\n\nPerhaps it is a configuration item on the server and/or client.   It seems we\nare running the same version of p4.  But just to be sure, check yours against\nmine:\n\n$ cksum $(which p4)\n3254530484 2420552 /usr/bin/p4\n\nIf yours if different, can you email a copy of your p4 executable to me\nso I can check if it works differently than mine?\n\nI will also check with coworkers here to see how their client behaves.\n\n>> Second issue\n>> ------------\n>> \n>> git-p4 uses 'p4 print -q -o o FILE' to print a file to stdout.\n>> At least that is how I interpret this snippet:\n>> \n>>    text = p4_read_pipe(['print', '-q', '-o', '-', file['depotFile']])\n>> \n>> However, p4/Linux prints to stdout by default and '-o -' will save\n>> the output in a file named '-'.\n>> \n>> My git and p4 versions:\n>> \n>>    $ git --version\n>>    git version 1.8.2.1.418.gaec3f77\n>> \n>>    $ p4 -V\n>>    Perforce - The Fast Software Configuration Management System.\n>>    Copyright 1995-2013 Perforce Software.  All rights reserved.\n>>    This product includes software developed by the OpenSSL Project\n>>    for use in the OpenSSL Toolkit (http://www.openssl.org/)\n>>    See 'p4 help legal' for full OpenSSL license information\n>>    Version of OpenSSL Libraries: OpenSSL 1.0.1c 10 May 2012\n>>    Rev. P4/LINUX26X86_64/2013.1/610569 (2013/03/19).\n> \n> This code only happens on utf16 files.  But running it by hand,\n> I cannot reproduce the different behavior:\n> \n>    $ p4 print -q //depot/f-ascii\n>    three\n>    line\n>    text\n> \n>    $ p4 print -o - -q //depot/f-ascii\n>    three\n>    line\n> \n>    $ ls ./-\n>    ls: cannot access ./-: No such file or directory\n> \n> I'm again confused.  Any hints you can give would be helpful.\n\nThis \"second issue\" is a non-issue.  It seems \"-o -\" does send to\nstdout for files.  For symlinks, it creates a symlink named \"-\".\nExample:\n\n$ ls -l pcre\nlrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 17:17 pcre -> ../libs/pcre/\n$ ls -l ./- ./xxx\n/bin/ls: cannot access ./-: No such file or directory\n/bin/ls: cannot access ./xxx: No such file or directory\n$ p4 print -q -o - pcre\n$ p4 print -q -o xxx pcre\n$ ls -l ./- ./xxx\nlrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 20:25 ./- -> ../libs/pcre/\nlrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 20:25 ./xxx -> ../libs/pcre/\n\n\n> \n> \t\t-- Pete\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\nThanks,\nAlex\n"},{"id":"214828","messageId":"20130419115513.GA7966@padd.com","threadId":"33525","inReplyTo":"14D98038-C656-47B9-ABF2-CC12914F0C75@aivor.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2013-04-19T11:55:13Z","receivedAt":"2013-04-19T11:55:13Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"alex@aivor.com wrote on Thu, 18 Apr 2013 20:34 -0500:\n> Perhaps it is a configuration item on the server and/or client.   It seems we\n> are running the same version of p4.  But just to be sure, check yours against\n> mine:\n> \n> $ cksum $(which p4)\n> 3254530484 2420552 /usr/bin/p4\n> \n> If yours if different, can you email a copy of your p4 executable to me\n> so I can check if it works differently than mine?\n\nIt is the same binary.  Assuming you're running p4d 2013.1 too?\n\n    $ p4 info\n    [..]\n    Server version: P4D/LINUX26X86_64/2013.1/610569 (2013/03/19)\n\nI'm using these p4 client settings:\n\n    Options:        noallwrite noclobber nocompress unlocked nomodtime normdir\n    SubmitOptions:  submitunchanged\n    LineEnd:        unix\n\nRunning \"strace -vf -s 2000 p4 print -q symlink\" shows that the\nnewline is embedded in the response from p4d:\n\n    read(7, \"...\\0\\0\\0symlink-target\\n\\0func\\0\\23...\", 4096) = 277\n\nAlso the file depot/symlink,v in the p4d depot area includes the\n\\n in the RCS file too, somewhat surprisingly:\n\n    $ cat depot/symlink,v\n    head     1.6;\n    [..]\n    @@\n    text\n    @symlink-target\n    @\n\n> I will also check with coworkers here to see how their client behaves.\n> > This code only happens on utf16 files.  But running it by hand,\n> > I cannot reproduce the different behavior:\n> > \n> >    $ p4 print -q //depot/f-ascii\n> >    three\n> >    line\n> >    text\n> > \n> >    $ p4 print -o - -q //depot/f-ascii\n> >    three\n> >    line\n> > \n> >    $ ls ./-\n> >    ls: cannot access ./-: No such file or directory\n> > \n> > I'm again confused.  Any hints you can give would be helpful.\n> \n> This \"second issue\" is a non-issue.  It seems \"-o -\" does send to\n> stdout for files.  For symlinks, it creates a symlink named \"-\".\n> Example:\n> \n> $ ls -l pcre\n> lrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 17:17 pcre -> ../libs/pcre/\n> $ ls -l ./- ./xxx\n> /bin/ls: cannot access ./-: No such file or directory\n> /bin/ls: cannot access ./xxx: No such file or directory\n> $ p4 print -q -o - pcre\n> $ p4 print -q -o xxx pcre\n> $ ls -l ./- ./xxx\n> lrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 20:25 ./- -> ../libs/pcre/\n> lrwxrwxrwx 1 atomlinson atomlinson 12 Apr 18 20:25 ./xxx -> ../libs/pcre/\n\nMe too.  That's annoying behavior, but not used by git-p4 fortunately.\nThe \"-o -\" option is only used for odd utf16 files where \"p4 print\"\ngenerates invalid output.\n\n\t\t-- Pete\n"},{"id":"214831","messageId":"517160D8.4060207@aivor.com","threadId":"33525","inReplyTo":"20130419115513.GA7966@padd.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"Alex Tomlinson","fromEmail":"alex@aivor.com","sentAt":"2013-04-19T15:20:56Z","receivedAt":"2013-04-19T15:20:56Z","isPatch":false,"sender":{"key":"alex@aivor.com","avatar":null},"body":"I found some symlinks in our depot that have the newline and\nothers that do not.  It looks like p4 print just dumps whatever\nis in the depot file, which of course is what you would expect\nit to do.  So the question (for me) is, how did some of my symlink\ntargets end up without the newline?  Note: that's not a question\nfor git-p4 because git-p4 was not involved in the creation of\nthis p4 depot (or the symlink).\n\ngit-p4 is off the hook since it appears to be an issue with\nthe depot itself.\n\nThanks for your time!\n--Alex\n"},{"id":"214911","messageId":"CAJDDKr4gLWev=N-yMw3j0norzVxBp99ie_EYAbNcUvWcL-_70w@mail.gmail.com","threadId":"33525","inReplyTo":"20130419000947.GB9048@padd.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-04-20T10:50:53Z","receivedAt":"2013-04-20T10:50:53Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff <pw@padd.com> wrote:\n>> First issue\n>> -----------\n>>\n>> git-p4 assumes the output of 'p4 print' adds a newline to the\n>> target.  To work around this, git-p4.py strips the last char from\n>> symlinks as shown in the following snippet:\n>>\n>>     if type_base == \"symlink\":\n>>         git_mode = \"120000\"\n>>         # p4 print on a symlink contains \"target\\n\"; remove the newline\n>>         data = ''.join(contents)\n>>         contents = [data[:-1]]\n\nThis line could be made more robust by changing it to:\n\n    contents = [data.rstrip('\\n')]\n\nThat way it only strips off newlines if they exist, which essentially\npapers over these rogue depot files.\nAlternatively, it could use rstrip() with no arguments to cast a wider\nnet and catch all whitespace.\n-- \nDavid\n"},{"id":"214919","messageId":"20130420132233.GA2094@padd.com","threadId":"33525","inReplyTo":"CAJDDKr4gLWev=N-yMw3j0norzVxBp99ie_EYAbNcUvWcL-_70w@mail.gmail.com","subject":"Re: is git-p4 compatible with p4/linux?","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2013-04-20T13:22:33Z","receivedAt":"2013-04-20T13:22:33Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"davvid@gmail.com wrote on Sat, 20 Apr 2013 03:50 -0700:\n> On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff <pw@padd.com> wrote:\n> >> First issue\n> >> -----------\n> >>\n> >> git-p4 assumes the output of 'p4 print' adds a newline to the\n> >> target.  To work around this, git-p4.py strips the last char from\n> >> symlinks as shown in the following snippet:\n> >>\n> >>     if type_base == \"symlink\":\n> >>         git_mode = \"120000\"\n> >>         # p4 print on a symlink contains \"target\\n\"; remove the newline\n> >>         data = ''.join(contents)\n> >>         contents = [data[:-1]]\n> \n> This line could be made more robust by changing it to:\n> \n>     contents = [data.rstrip('\\n')]\n> \n> That way it only strips off newlines if they exist, which essentially\n> papers over these rogue depot files.\n> Alternatively, it could use rstrip() with no arguments to cast a wider\n> net and catch all whitespace.\n\nI was tempted to do that, but it is possible to put \\n and other\nspace characters in the target of symlinks.  It's unfortunate\nthat p4 always appears to tack on a newline itself.\n\nWe'll see if Alex comes up with a pattern that shows how he ended\nup with the odd symlinks.\n\n\t\t-- Pete\n"}]}