Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 56084 invoked from network); 18 Aug 2009 20:36:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 18 Aug 2009 20:36:32 -0000 Received: (qmail 78674 invoked by uid 500); 18 Aug 2009 20:36:51 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 78602 invoked by uid 500); 18 Aug 2009 20:36:51 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 78592 invoked by uid 99); 18 Aug 2009 20:36:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Aug 2009 20:36:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates 209.85.218.228 as permitted sender) Received: from [209.85.218.228] (HELO mail-bw0-f228.google.com) (209.85.218.228) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Aug 2009 20:36:41 +0000 Received: by bwz28 with SMTP id 28so3218900bwz.6 for ; Tue, 18 Aug 2009 13:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=zg8l35kk3yNioRdfd2UEdaw0K7H9yGnbg7shiAoejRU=; b=f6Y60GZZjWBKk5CaISt+zCGMtq3L7H0oMdr8mgCVZxXesxbprZDCnBYQYifUCyrt6V z6OLPB3G/jbd0wsplnBhDBS0QhDihY7nwT+HAZDEUMmxlUoHV7XYfLmxxWuZ4Ny97Eh8 kDOwoi71GhxqfNFn7X5uxaHB+JHvQRG/SIV64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AOyHTowru7Q8dwEJJCPjpvB16NaY0GR5Y2/prc8HRr471U6TZ+FqWjNcGuWhf7MHiM 87stsnjpKTm5gXyM/KVInHnawsepnk+GVZTx6+aHr4BFJsXFgV1VgFbRUnHKrapL7Vs+ wme5B1eXMm5soiOkjbKL/pNkZHh9qm10MfDlk= MIME-Version: 1.0 Received: by 10.223.145.3 with SMTP id b3mr1368041fav.67.1250627779369; Tue, 18 Aug 2009 13:36:19 -0700 (PDT) In-Reply-To: References: <9b350d680908111427m7248dccay4e1dab27a8d2e872@mail.gmail.com> <4A82C59A.5060408@ungoverned.org> <9b350d680908160430j5641f48aycd01ab4edbd7b7cc@mail.gmail.com> <9b350d680908180017t6a2f3320m30acf32bba9082e6@mail.gmail.com> Date: Tue, 18 Aug 2009 22:36:19 +0200 Message-ID: Subject: Re: Gogo From: Guillaume Nodet To: dev Content-Type: multipart/alternative; boundary=0023545bcf20891d4c04717078b9 X-Virus-Checked: Checked by ClamAV on apache.org --0023545bcf20891d4c04717078b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Another example taken from the existing test suite: assertEquals("ca b", c.execute("e = { echo c$args } ; ")); This test currently works fine. When extracting the patch for FELIX-1498, this one and the two following ones are the only one to fail. The reason is again caused by the fact that a single argument won't cause any exception if it's not a command. This wasn't a problem because "ca b" is simply returned, but by splitting it, it becomes more evident that the result is evaluated, which is not the intent of the test. On Tue, Aug 18, 2009 at 16:46, Guillaume Nodet wrote: > > > On Tue, Aug 18, 2009 at 09:17, Derek Baum wrote: > >> 2009/8/17 Guillaume Nodet >> >> > >> > 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> | tac >> ab >> karaf@root> echo a; >> 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 >> in gogo. >> > > Well the key difference between those operators in bash is the number of > times the evaluation happen. > > ( ) does not change the number of times a command will be evaluated, that's > why i call it grouping. > What i mean is that if you remove the ( ), the commands will be executed > the same number of time. > echo a => echo a > ( echo a ) => echo a > ( ( echo a ) ) => echo a > All of those will produce the same result. > > $( ) will increment the number of evaluation each time it's used, and is > therefore not idemptotent. > echo echo echo a => echo echo a > $(echo echo echo a) => echo a > $( $( echo echo echo a) ) => a > > I don't really see how we can conflate both operators using < > or any > other syntax. > With the current state of gogo, you're not really sure how many times > evaluation will happen. > > >> >> 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("") + ""); >> >> This fails because 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. > > > Right, and I think this reparsing of arguments should be done anyway. So > maybe we need a separate jira for that one. > > I think I understood where our uncomprehension comes from. I first started > to have a look at FELIX-1325 (throwing an exception when the can't be found, > even if it has no arguments). The problem is that all those issues are > linked. > What you describe above works only because when you have a single token on > the command line and that no command is found, the token is simply returned. > This means that in all the above examples, the number of evaluation is not > really important, because executing "a" will return "a". > This hides some real issues imho, as the following tests, that all pass on > trunk show: > > assertEquals("echo echo", c.execute("echo echo echo")); > assertEquals("echo", c.execute("")); > assertEquals("", c.execute("<>")); > > assertEquals("echo a", c.execute("echo echo a")); > assertEquals("a", c.execute("")); > assertEquals("a", c.execute("<>")); > > > So the behavior of < > is that it run the command(s) inside it *and* > evaluates it. It's not only grouping. > > Now, let's take an example: > > assertEquals("a", c.execute("echoout \"a\nb\" | grep a | > capture")); > assertEquals("b", c.execute("echoout \"a\nb\" | grep b | > capture")); > assertEquals("ab", c.execute(" > ; | capture")); > > assertEquals("", c.execute(" capture> ; | capture")); > > The first two tests are ok. The third test is equivalent to "test1 ; test2 > | capture". > Remember that atm ';' takes precedence over '|'. > > Now the last test is the same as the third one, but with different values. > The output should be "echogrep", but isn't, due to the additional > evaluation. > The third test would also fail if we apply FELIX-1325 afaik. > > >> >> 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. >> > >> > >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --0023545bcf20891d4c04717078b9--