felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Derek Baum <derek.b...@paremus.com>
Subject Re: OSGi Shell
Date Wed, 12 May 2010 10:54:12 GMT
> Any other items that should be taken care of?

FELIX-1304: Better support for variables evaluation in arguments
this introduced ${xxx} as an alternative way to expand variables, useful if
they are adjacent to other text e.g. $HOMEXXX vs ${HOME}XXX. Gogo now also
implements the bash-like defaulting: ${HOME:-default} expands to $HOME, but
if it is null it instead expands to the supplied default.

FELIX-1325: gogo doesn't report a command not found error unless an argument
is supplied

FELIX-1487: Support for commands on multiple lines
this makes NEWLINE an alternative to semicolon (;) as statement separator

FELIX-1493: automatic expansion of $args in Closure stops direct access to
$args list
this adds $argv variable which can always be accessed as a List

FELIX-1494: Closure arguments should start at $1

FELIX-1506: allow invocation of static methods

Comments on your existing feedback:

>    2.    FELIX-1473 When the first argument is a string, gogo considers it
to be a command. 
The problem is that it leads to unpredictible behavior
when using variables 

> $a length 

Depending on the type of $a, it will
either try to call a command named by the value of $a, or call the length
method on the $a object. Felix added a . to force the interpretation to be a
string. Guess (string $a) length would also work.

Alternatively, $a length could always be treated as a method call, and we
could use some other syntax to indicate we want to treat it as a command,
for example: "$a" length, as quoting forces the expansion to a String.

However, the FELIX-1473 solution of using . to force a method call is
probably easier.
It also has the advantage of allowing simpler chaining of method calls, for
example:

% myhost = (((bundle 0) loadclass java.net.InetAddress) localhost) hostname

is simplified by using the dot notation:

% myhost = (bundle 0) . loadclass java.net.InetAddress . localhost .
hostname


>    4.    #49.1 Request to provide Set<String> getCommands. I suggest we
create a CommandDescription that is returned. This description will provide
sufficient info to not only finish the name of the command but also fill in
parameters and show flags. See annotations later.

#49 refers to https://www.osgi.org/bugzilla/show_bug.cgi?id=49

>    5.    #49.2 Provide access to the variables. Makes a lot of sense.

>    6.    #49.3 Allow removal of variables. Maybe we should use have a
Map<String,Object> getVariables method.

yes, this would also allow removal of the CommandSession get() and put()
methods, which could be replaced by session.variables().get(k) and
session.variables().put(k, v) instead.


>    7.    #49.4 Add boolean isTty(InputStream in); boolean
isTty(OutputStream out) so commands can adapt to interactive and piped. Not
sure, needs discussion. I am not that charmed by commands adapting, that is
why there are options.

another use case for this suggestion is for commands that use ANSI escape
sequences to produce coloured output. This method would enable these
commands to automatically suppress the ANSI sequences if they are outputting
to a pipe; otherwise, as you say, they would need some explicit "--no-ansi"
option.


>    8.    #49.5 Add InputStream setInput(InputStream in) for history etc. I
disagree. The request behavior can easily be gotten by proxying the input
stream, I think. Lets try to keep it simple.

I agree. I can work without this.

>    9.    #52 commands in osgi: scope need to be well defined. They're
currently defined as the methods on the BundleContext ... Will work on this.

The current commands in the osgi: scope in gogo include:
    methods on Bundle
    methods on BundleContext
    methods on PackageAdmin, StartLevel and PermissionAdmin, if service
available
    built-in procedural commands (each, if, tac, new)
    example commands (cat, echo, grep, etc)

    Richard Hall has asked me to reduce the default commands registered in
the gogo runtime to a minimum. The gogo console or other users of the gogo
runtime, can then easily register other commands as required.

I think the minimum from the above is just the methods on BundleContext, and
the procedural commands, as this then allows the other commands to be added,
if required, using a script:

    % addcommand osgi (bundle 0)

    % service = {
      refs = osgi:serviceReferences $1 null
      if {$refs} {osgi:getService ($refs 0)}
    }

    paclass = (bundle 0) loadclass
org.osgi.service.packageadmin.PackageAdmin
    paservice = service ($paclass name)
    % addcommand osgi $paservice $paclass

    I include 'tac' and 'new' in the group of 'built-in' commands, because
the RFC explicitly describes 'tac' as the way to direct output to a file and
'new' should leverage the same argument coercion used for method invocation.

    'addcommand' is currently in the shell: scope. I think this should be
moved to the osgi: scope and defined in the RFC.


Derek

On 11 May 2010 19:49, Peter Kriens <peter.kriens@aqute.biz> wrote:

> I am updated RFC 147 and prepare it for the meeting next week. I've got the
> following feedback so far:
>
>
>    1. FELIX-1526 Replace <> embedded execution with (). Originally the ()
>    were used for filters. I am ok in making this change and not directly
>    supporting filters.
>    2. FELIX-1473 When the first argument is a string, gogo considers it to
>    be a command.
>    The problem is that it leads to unpredictible behavior when using
>    variables
>
>    > $a length
>
>    Depending on the type of $a, it will either try to call a command named
>    by the value of $a, or call the length method on the $a object. Felix added
>    a . to force the interpretation to be a string. Guess (string $a) length
>    would also work
>    3. FELIX-1536 Reverse priority of statement and pipe. Currently a; b |
>    c pipes both and b through c. In unix this is different, it only pipes b
>    through c. I think the current syntax is more logical but compatibility with
>    unix is not irrelevant.
>    4. #49 Request to provide Set<String> getCommands. I suggest we create
>    a CommandDescription that is returned. This description will provide
>    sufficient info to not only finish the name of the command but also fill in
>    parameters and show flags. See annotations later.
>    5. #49 Provide access to the variables. Makes a lot of sense.
>    6. #49 Allow removal of variables. Maybe we should use have a
>    Map<String,Object> getVariables method.
>    7. #49 Add boolean isTty(InputStream in); boolean isTty(OutputStream
>    out) so commands can adapt to interactive and piped. Not sure, needs
>    discussion. I am not that charmed by commands adapting, that is why there
>    are options.
>    8. #49 Add InputStream setInput(InputStream in) for history etc. I
>    disagree. The request behavior can easily be gotten by proxying the input
>    stream, I think. Lets try to keep it simple.
>    9. #52 commands in osgi: scope need to be well defined. They're
>    currently defined as the methods on the BundleContext ... Will work on this.
>    10. #51 Define command search order. Makes sense to add a PATH variable
>    of type String[].
>    11. #53 Command help. Adding the CommandDescriptor would help here.
>
>
> Additionally, there is a development going on in Felix that made me want to
> add the following areas.
>
>
>    1. Richard and I played with annotations and the type conversion/method
>    coercion. I like to add a new package and then define generic annotations
>    for: Description + a special Parameter annotation. The description is
>    logical, the Parameter will allow flags (-x), optionality, and will allow
>    steering of type conversion. This made it clear to me that we need a type
>    conversion package that can handle the requirements of Blueprint, TSH, and
>    maybe even DS in the future. Type annotations can be provided to steer this
>    conversion. It seems that this problem pops up in lots of places.
>
>
> Any other items that should be taken care of?
>
> Kind regards,
>
> Peter Kriens
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message