Return-Path: 
 <dev-return-17154-apmail-felix-dev-archive=felix.apache.org@felix.apache.org>
Delivered-To: apmail-felix-dev-archive@www.apache.org
Received: (qmail 57616 invoked from network); 18 Aug 2009 07:17:27 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 18 Aug 2009 07:17:27 -0000
Received: (qmail 45009 invoked by uid 500); 18 Aug 2009 07:17:46 -0000
Delivered-To: apmail-felix-dev-archive@felix.apache.org
Received: (qmail 44906 invoked by uid 500); 18 Aug 2009 07:17:45 -0000
Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@felix.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@felix.apache.org>
List-Post: <mailto:dev@felix.apache.org>
List-Id: <dev.felix.apache.org>
Reply-To: dev@felix.apache.org
Delivered-To: mailing list dev@felix.apache.org
Received: (qmail 44896 invoked by uid 99); 18 Aug 2009 07:17:45 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Aug 2009 07:17:45 +0000
X-ASF-Spam-Status: No, hits=3.4 required=10.0
	tests=HTML_MESSAGE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [209.85.212.200] (HELO mail-vw0-f200.google.com)
 (209.85.212.200)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Aug 2009 07:17:36 +0000
Received: by vws38 with SMTP id 38so2797366vws.16
        for <dev@felix.apache.org>; Tue, 18 Aug 2009 00:17:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.67.158 with SMTP id r30mr6284349vci.15.1250579834606;
 Tue,
	18 Aug 2009 00:17:14 -0700 (PDT)
In-Reply-To: <b23ecedc0908161633r504200dp3d40353065abb56b@mail.gmail.com>
References: <a364c40b0907130145q6939153ci27b7cebd7a9bce23@mail.gmail.com>
	 <af2843cd0907220343x33ad6f8w25622ea6aebf7416@mail.gmail.com>
	 <b23ecedc0908110520n6c45c0d2j7d5623bea14de785@mail.gmail.com>
	 <9b350d680908111427m7248dccay4e1dab27a8d2e872@mail.gmail.com>
	 <b23ecedc0908120100i9af1069pb824f8f55e76e0cd@mail.gmail.com>
	 <4A82C59A.5060408@ungoverned.org>
	 <b23ecedc0908121206i4512f97bq4426e7d98ff7fb9b@mail.gmail.com>
	 <b23ecedc0908151813m4cf25555kbb912b6325bd5667@mail.gmail.com>
	 <9b350d680908160430j5641f48aycd01ab4edbd7b7cc@mail.gmail.com>
	 <b23ecedc0908161633r504200dp3d40353065abb56b@mail.gmail.com>
Date: Tue, 18 Aug 2009 08:17:14 +0100
Message-ID: <9b350d680908180017t6a2f3320m30acf32bba9082e6@mail.gmail.com>
Subject: Re: Gogo
From: Derek Baum <derek.baum@paremus.com>
To: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=001485e77058ce15c00471654ed2
X-Virus-Checked: Checked by ClamAV on apache.org

--001485e77058ce15c00471654ed2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

2009/8/17 Guillaume Nodet <gnodet@gmail.com>

>
> So in short, the patch does the following:
>  * replace <> with $()
>  * use ( ) for grouping commands when on the edge of the command
>  * make the number of evaluation predictable
>  * have a syntax and semantic which is mostly (fully) in sync with bash
>  * re-evaluate / split expanded arguments that are not quoted



I can still see no reason for having () and $() as two separate operators.
This unncessarily compllicates syntax without adding any new capability.

You previously gave the following example to demonstrate the need for a
separate grouping operator:

>The grouping operator is imho needed to be able to order pipes and columns:
>  (echo a ; echo b) | tac
>  echo a ; (echo b | tac)

However, this example works fine with the existing <> execution quotes:

karaf@root> <echo a; echo b> | tac
ab
karaf@root> echo a; <echo b | tac>
a
b

Do you have any other example or use case that demonstrates the need for a
separate grouping operator?

() in bash is NOT only used for grouping - it executes the command within
(), just like the existing <>.
$() in bash executes and captures stdout into a string - equivalent to
<command args | tac> in gogo.


To try to understand the need for separate () and $() operators, I have
taken the gogo TestParser.java from the FELIX-1471.patch and replaced both
$() and () with <>. I then ran the test against the unpatched code.

All tests worked except some newly added tests within
testGroupingAndEvaluation() like:

assertEquals("a", c.execute("<echo echo a>") + "");

This fails because <echo echo a> evaluates to the String "echo a", which is
then evaluated as a command and the command 'echo a' is not found.

assertEquals("a", c.execute("$(echo echo a)") + "");

This works because of the complex re-parsing done by $() that you describe
below.

In bash, if you need to re-parse some text, you use the 'eval' command:

$ eval $(echo echo '$HOME')
/Users/derek

We could take exactly the same approach in gogo, by adding a simple eval
command for use on the rare occassions when it is required.

Derek



>
>
> I'm happy to discuss things further, but the major problem is related to
> make the evaluation predictable, which sounds easy, but is not really ...
> And this require to re-evaluate / split the expanded arguments.
> See the following example:
>        assertEquals("a", c.execute("$($(echo echo echo a)) | capture"));
> The "echo echo echo a" command is executed and prints "echo echo a". This
> result is inside $() so it has to be interpreted as a full command line,
> not
> as a single argument which would be a string "echo echo a" as this would
> return a command not found.
>
>

--001485e77058ce15c00471654ed2--