Return-Path: Delivered-To: apmail-felix-dev-archive@www.apache.org Received: (qmail 9762 invoked from network); 11 Aug 2009 14:46:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Aug 2009 14:46:00 -0000 Received: (qmail 19226 invoked by uid 500); 11 Aug 2009 14:46:07 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 19158 invoked by uid 500); 11 Aug 2009 14:46:07 -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 19148 invoked by uid 99); 11 Aug 2009 14:46:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 14:46:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates 209.85.218.205 as permitted sender) Received: from [209.85.218.205] (HELO mail-bw0-f205.google.com) (209.85.218.205) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 14:45:56 +0000 Received: by bwz1 with SMTP id 1so3131300bwz.22 for ; Tue, 11 Aug 2009 07:45:34 -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 :content-transfer-encoding; bh=s1Fl2z9+wS0mgIV9Vk4/2JMtLbg4cqYYIbCoiu2bon8=; b=W5LE2S43Mq9MwTSxnRwvs+570C+YagJMHQr2T5EqrWChQuv4gPoKi9Wismv2am8ra1 rBGhNHt04GMt+5TfZku+j8DmTzrE9l1tueDf0X0U7VbmWXCwJO+BQk0mdE55URuhD2tK UHsCz5wam8LgRY4PfqV4p7NZkz7JU5eCoRcMQ= 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:content-transfer-encoding; b=fapudmp6vr8nxqOCD3Hu6z8YWy4YG7uS96T9S5yXOM8WALfNGpzWF39wnF1tkTsa1t XWLQzdDf5JKcePgULfG9+C4j/1seF67FA/O9sP0/APCP4QaEvNeUnzuKPecrTuk1xQ4F kCe6J2+eM96+c0uoD6hrCxKhnrFtIWCCZVYqo= MIME-Version: 1.0 Received: by 10.223.119.77 with SMTP id y13mr1373585faq.4.1250001934480; Tue, 11 Aug 2009 07:45:34 -0700 (PDT) In-Reply-To: References: <9b350d680907140059s59e313fapbae1dba0b268a62a@mail.gmail.com> <9b350d680907160722k1e0e77fr7db40b5cfa33c1dd@mail.gmail.com> <9b350d680907170425u4fb79d66n82d28632e425dcea@mail.gmail.com> Date: Tue, 11 Aug 2009 16:45:34 +0200 Message-ID: Subject: Re: Gogo From: Guillaume Nodet To: dev@felix.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I also want to raise another problem, which is the undeterministic aspect of the evaluation. A statement is considered a comment if the first argument is a string, else it assumes it represents a method call. Thus, you can't call a method on a string. This would be a problem when using things like $a getClass where the execution would be different depending of the type of $a On Tue, Aug 11, 2009 at 14:20, Guillaume Nodet wrote: > I'd like to tackle this issue but I'm still not comfortable at the meanin= g > of $() and (). > The problem I have is whether the output should be evaluated or not. > > For example, if we consider () to be equivalent to <> > > =A0echo a =A0 =A0 =A0=A0=A0=A0 =3D> "a" > =A0echo echo a =A0=A0=A0 =3D> "echo a" > =A0echo a ; echo b =3D> "ab" > > Now, when using parenthesis, we have the following options > > =A0(echo echo a)=A0=A0 =3D> "a"=A0 or "echo a" > > I think it should be "echo a", else we can't really use it for grouping > commands for piping: > > =A0e =3D { echo $0 } ; (e a=A0=A0 b | capture) > > This would fail because "e a=A0 b" would be evaluated to "a", then captur= e, > but the resulting value is not a command, so a command not found exceptio= n > would be thrown. > > I think it would be more intuitive for the evaluation to be the > differenciator between () and $(). > So we'd have: > > =A0echo echo a =A0 =A0 =3D> "echo a" > =A0 (echo echo a)=A0=A0 =3D> "echo a" > =A0 ((echo echo a)) =3D> "echo a" > =A0 $(echo echo a)=A0 =3D> "a" > > Thoughts ? > > On Wed, Jul 22, 2009 at 12:43, Hiram Chirino wrote: >> On Fri, Jul 17, 2009 at 7:25 AM, Derek Baum >> wrote: >> >>> In RFC132, although <> are compared to shell backquotes, there are >>> actually >>> just executing the command, >>> and not capturing its output as done by shell backquotes, so I agree th= at >>> <> >>> should become () and not $(). >>> >>> Some background to help clarify: >>> >>> In Unix shells, parenthesis () are used to run commands in a subshell, = so >>> for example, all output goes to the pipe: >>> >>> $ echo one; echo two | nl >>> one >>> =A0 =A0 1 =A0two >>> >>> $ (echo one; echo two) | nl >>> =A0 =A0 1 =A0one >>> =A0 =A0 2 =A0two >>> >>> $() is the modern equivalent of backquotes `` in Unix shells, and can b= e >>> nested. >>> >>> It is also logical: () runs a group of commands and $() captures the >>> result >>> as a string: >>> >>> $ hg paths default >>> ssh://hg@hg.paremus.com:24/posh >>> $ project=3D$(basename $(hg paths default)) >>> $ echo $project >>> posh >>> >>> However in RFC132, we rarely need to capture output as strings - we can >>> use >>> the returned objects directly, >>> so the above could look like this in RFC132: >>> >>> > project =3D (basename (hg paths default)) >>> >>> or if 'hg paths default' returned a File object: >>> >>> > project =3D (hg paths default) getName >>> >>> >>> Shell backquotes are similar to the 'tac' command in RFC132, which >>> captures >>> the output of a command and returns it as a string: >>> >>> assuming grep prints to stdout and returns boolean to indicate whether = it >>> found a match: >>> >>> This sets b to the boolean result of grep: >>> >>> % b =3D >>> 000000 ACT org.apache.felix.framework-1.8.1 >>> % echo $b >>> true >>> >>> We can use tac to capture the output of grep as a string: >>> >>> % b =3D >>> % echo $b >>> 000000 ACT org.apache.felix.framework-1.8.1true >>> >>> We _could_ instead define $() to capture output, as it does in Unix: >>> >>> % b =3D $(bundles | grep felix) >>> >>> Derek >>> >> >> +1. =A0The fact of the matter is the 'casual' users of the shell will NO= T be >> aware of the more powerful underlying type system that is available via >> arguments and return types. =A0These users will prefer to work with stdo= ut >> results since it's output is 'self-documenting'. =A0Support for construc= ts >> like $(...) will make these kinds of user's lives easier. >> >> >> >>> >>> >>> >>> >>> 2009/7/17 Peter Kriens >>> >>> > I am not sure I see why we need $( ... ) for evaluation, instead of ( >>> > ... >>> > )? >>> > >>> > Kind regards, >>> > >>> > =A0 =A0 =A0 =A0Peter Kriens >>> > >>> > >>> > >>> > >>> > >>> > On 16 jul 2009, at 16:22, Derek Baum wrote: >>> > >>> > =A02009/7/16 Peter Kriens >>> >> >>> >> >>> >>> I do agree that we should replace the <> with (). This makes a lot = of >>> >>> sense >>> >>> and there are not that many filters in use anyway. We could now mak= e >>> >>> filters >>> >>> <> if we want. >>> >>> >>> >>> [snip] >>> >>> >>> >>> About the priority of | and ; ... I remember thinking long and hard >>> about >>> >>> this but forgot why I picked this model, it still seems slightly mo= re >>> >>> powerful because the newline acts as a ';' with a higher priority >>> >>> than >>> >>> the >>> >>> '|' but I am not opposed to switching the priority. >>> >>> >>> >> >>> >> >>> >> if we agree to use $() for command execution instead of <> >>> >> then we can use () for command grouping, and thus the examples below >>> would >>> >> work the same in Unix or RFC132 shell: >>> >> >>> >> echo a; echo b | cat >>> >> (echo a; echo b) | cat >>> >> >>> >> We could also add a converter to coerce a string into an LDAP filter >>> >> to >>> >> make >>> >> up for stealing the (). >>> >> >>> >> >>> >> >>> >> =A0I am not sure about throwing an error when a command is not >>> >> recognized. >>> >>> Using its value seems sufficient to me and has some advantages. I d= o >>> not >>> >>> think this would ever confuse me. >>> >>> >>> >> >>> >> >>> >> It has already confused users on Karaf :-) >>> >> >>> >> A 'command not found' error only occurs if you pass an argument to a= n >>> >> unknown command, otherwise it silently evaluates to itself. >>> >> >>> >> Although this may be apparent to a user at the console, it would be >>> >> much >>> >> more difficult to diagnose in a script containing a mis-spelled >>> >> command. >>> >> >>> >> I have attached a simple patch to experiment with this to >>> >> https://issues.apache.org/jira/browse/FELIX-1325 >>> >> >>> >> This patch simply avoids re-evaluating a single argument to an >>> assignment, >>> >> so >>> >> >>> >> x =3D hello >>> >> >>> >> works as before, but when evaluated in a non-assignment context, it >>> fails >>> >> if >>> >> a 'hello' command is not found. >>> >> >>> >> Variable expansion using ${ab} rather than $ab is still problematic. >>> >> >>> >> the ${ab} notation is in common usage: >>> >> >>> >> =A0- Unix allows it to delimit the variable name from following text >>> >> =A0- Many Java programs interpret ${xx} as expansion of system >>> >> properties >>> >> >>> >> It also works in the RFC132 shell, but in this case {ab} defines a >>> closure >>> >> and the $ evaulates it. >>> >> >>> >> If you really wanted to capture the result of executing ab, then >>> >> or >>> >> our >>> >> proposed $(ab) is the way to go. >>> >> >>> >> This would then allow us to interpret ${ab}, according to its comon >>> usage >>> >> - >>> >> enhanced variable expansion. >>> >> We could also usefully add the Unix variable expansion: >>> >> ${var:-default} >>> >> >>> >> Derek >>> >> >>> >> >>> >> >>> >>> >>> >>> Nice to get some discussion going! However, please note that this i= s >>> >>> an >>> >>> OSGi RFC. I will update the RFC in the coming weeks and discuss it = in >>> >>> CPEG. >>> >>> I hope to schedule it then for inclusion in an upcoming compendium. >>> >>> >>> >>> I'd like to add one more thing. In Blueprint we spent a lot of time >>> >>> on >>> >>> type >>> >>> conversion and I like very much what we got there. I think it would >>> >>> be >>> a >>> >>> good idea to use the same type converters, especially because they >>> >>> also >>> >>> handle generics when available. >>> >>> >>> >> >>> >> >>> >> >>> >>> Kind regards, >>> >>> >>> >>> =A0 =A0 =A0Peter Kriens >>> >>> >>> >>> >>> >>> >>> > >>> >> >> >> >> -- >> Regards, >> Hiram >> >> Blog: http://hiramchirino.com >> >> Open Source SOA >> http://fusesource.com/ >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > > > --=20 Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com