All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Brandon Casey <casey@nrlssc.navy.mil>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jay Soffian <jaysoffian@gmail.com>,
	git@vger.kernel.org, Tay Ray Chuan <rctay89@gmail.com>
Subject: Re: [PATCH] t5540-http-push.sh: avoid non-portable grep -P
Date: Thu, 26 Feb 2009 16:24:20 -0800	[thread overview]
Message-ID: <7vr61kpw0b.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <4WGE1cq9SGp9DuzqT2ZuVN0RzLGmBe1mAX4n1O4-TNyRqiZqxDP62A@cipher.nrlssc.navy.mil> (Brandon Casey's message of "Thu, 26 Feb 2009 18:12:26 -0600")

Brandon Casey <casey@nrlssc.navy.mil> writes:

> Johannes Schindelin wrote:
>> Hi,
>> 
>> On Thu, 26 Feb 2009, Brandon Casey wrote:
>> 
>>>    sed -e 'script' input-file
>>>
>>> rather than
>>>
>>>    sed -e 'script' < input-file
>> 
>> What should make the former more preferable to the latter?
>
> It's less complex, but as you describe in the next paragraph, if the
> file name is not desired in the result then the latter is preferable.
> I initially viewed the latter form as a useless use of cat, equivalent
> to:
>
>    cat input-file | sed -e 'script'
>
>> Especially given that the latter way is preferable with other commands (at 
>> least as far as our test suite is concerned), such as grep, because you do 
>> not get the file name as part of the result?
>> 
>> And especially given that sed means _stream_ editor, not file editor?
>
> especially? Your first argument is valid, but this last sentence means nothing.
>

Ok, ok, I heard all of you.  I think "sed -e 'script' file" is better
because it is one letter shorter than with "<" rediretion, nothing else.

I merely was shooting for rejecting an obvious crap, not aiming for
perfection.

Here is the final one.  Let's stop wasting time and go on with our lives
;-)

Thanks.

-- >8 --
From: Jay Soffian <jaysoffian@gmail.com>
Date: Thu, 26 Feb 2009 18:44:40 -0500
Subject: [PATCH] t5540-http-push.sh: avoid non-portable grep -P

OS X's GNU grep does not support -P/--perl-regexp.

We use a basic RE instead, and simplify the pattern slightly by
replacing '+' with '*' so it can be more easily expressed using a basic
RE.  The important part of pattern, checking for a SHA-1 has suffix in
the successful PUT/MOVE operations, remains the same.  Also, a-z instead
of a-f was an obvious mistake in the original RE. Here are samples of
what we want to match:

127.0.0.1 - - [26/Feb/2009:22:38:13 +0000] "PUT /test_repo.git/objects/3e/a4fbb9e18a401a6463c595d08118fcb9fb7426_fab55116904c665a95438bcc78521444a7db6096 HTTP/1.1" 201 277
127.0.0.1 - - [26/Feb/2009:22:38:13 +0000] "MOVE /test_repo.git/objects/3e/a4fbb9e18a401a6463c595d08118fcb9fb7426_fab55116904c665a95438bcc78521444a7db6096 HTTP/1.1" 201 277

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t5540-http-push.sh |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 11b3432..10e5fd0 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -94,10 +94,15 @@ test_expect_success 'MKCOL sends directory names with trailing slashes' '
 
 '
 
-test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
+x1="[0-9a-f]"
+x2="$x1$x1"
+x5="$x1$x1$x1$x1$x1"
+x38="$x5$x5$x5$x5$x5$x5$x5$x1$x1$x1"
+x40="$x38$x2"
 
-	grep -P "\"(?:PUT|MOVE) .+objects/[\da-z]{2}/[\da-z]{38}_[\da-z\-]{40} HTTP/[0-9.]+\" 20\d" \
-		< "$HTTPD_ROOT_PATH"/access.log
+test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
+	sed -e "s/PUT /OP /" -e "s/MOVE /OP /" "$HTTPD_ROOT_PATH"/access.log |
+	grep -e "\"OP .*/objects/$x2/${x38}_$x40 HTTP/[.0-9]*\" 20[0-9] "
 
 '
 
-- 
1.6.2.rc2.91.gf9a36

  reply	other threads:[~2009-02-27  0:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26 19:49 [PATCH] t5540-http-push.sh: avoid non-portable grep -P Jay Soffian
2009-02-26 20:30 ` Junio C Hamano
2009-02-26 20:43   ` Jay Soffian
2009-02-26 20:46     ` Jay Soffian
2009-02-26 21:48     ` Junio C Hamano
2009-02-26 22:19       ` Jay Soffian
2009-02-26 22:37         ` Junio C Hamano
2009-02-26 22:40           ` Jay Soffian
2009-02-26 22:45             ` [PATCH v3] " Jay Soffian
2009-02-26 23:29             ` [PATCH] " Junio C Hamano
2009-02-26 23:40               ` Jay Soffian
2009-02-26 23:44               ` [PATCH v4] " Jay Soffian
2009-02-26 23:51               ` [PATCH] " Brandon Casey
2009-02-26 23:58                 ` Johannes Schindelin
2009-02-27  0:12                   ` Brandon Casey
2009-02-27  0:24                     ` Junio C Hamano [this message]
2009-02-26 21:41   ` [PATCH v2] " Jay Soffian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr61kpw0b.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=casey@nrlssc.navy.mil \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    --cc=rctay89@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.