Apache Felix Gogo

Exclusive offer: get 50% off this eBook here
OSGi and Apache Felix 3.0 Beginner's Guide

OSGi and Apache Felix 3.0 Beginner's Guide — Save 50%

Build your very own OSGi applications using the flexible and powerful Felix Framework

$26.99    $13.50
by Walid Joseph Gédéon | November 2010 | Beginner's Guides Open Source

Felix Gogo, a sub-project of Apache Felix, is an implementation of this early draft specification. The Gogo shell is included with the Felix Framework Distribution since version 3.0.

It is worth noting that this specification is not yet part of the official OSGi specifications, and therefore, may change in the future.

In this article, by Walid Gédéon, author of OSGi and Apache Felix 3.0, we will:

  • Learn about the Tiny Shell Language and its syntax
  • Cover some of the commands provided by Gogo

So let's start with a quick overview of the language.

 

OSGi and Apache Felix 3.0 Beginner's Guide

OSGi and Apache Felix 3.0 Beginner's Guide

Build your very own OSGi applications using the flexible and powerful Felix Framework

  • Build a completely operational real-life application composed of multiple bundles and a web front end using Felix
  • Get yourself acquainted with the OSGi concepts, in an easy-to-follow progressive manner
  • Learn everything needed about the Felix Framework and get familiar with Gogo, its command-line shell to start developing your OSGi applications
  • Simplify your OSGi development experience by learning about Felix iPOJO
  • A relentlessly practical beginner's guide that will walk you through making real-life OSGi applications while showing you the development tools (Maven, Eclipse, and so on) that will make the journey more enjoyable
        Read more about this book      

(For more resources on this subject, see here.)

The Tiny Shell Language

The command syntax for the shell interface is based on the Tiny Shell Language (TSL) . It is simple enough to allow a lightweight implementation, yet provides features such as pipes, closures, variable setting and referencing, collection types such as lists and maps, and so on.

The TSL syntax allows the creation of scripts that can be executed by the shell runtime service. The introduction you will get here does not cover the complete syntax; instead, you will see the basic parts of it.

For a review of the proposal in its initial state, (http://www.osgi.org/download/osgi-4.2-early-draft.pdf). You may also refer to the RFC 147 Overview on the Felix documentation pages (http://felix.apache.org/site/rfc-147-overview.html) for potential differences with the initial draft .

Chained execution

A program is a set of chained execution blocks. Blocks are executed in parallel, and the output of a block is streamed as input to the next. Blocks are separated by the pipe character ( | ). Each block is made up of a sequence of statements, separated by a semicolon ( ; ).

For example, as we'll see in the next section, the bundles command lists the currently installed bundles and the grep command takes a parameter that it uses to filter the input. The program below:

bundles | grep gogo

is made of two statement blocks, namely, bundles and grep gogo. The output of the bundles statement will be connected to the input of the grep gogo statement (here each the statement block contains one statement).

Running this program on your Felix installation, in the state it is now, will produce:

g! bundles | grep gogo
2|Active | 1|org.apache.felix.gogo.command (0.6.0)
3|Active | 1|org.apache.felix.gogo.runtime (0.6.0)
4|Active | 1|org.apache.felix.gogo.shell (0.6.0)
true

The grep statement has filtered the output of the bundles statement for lines containing the filter string gogo. In this case, the grep statement outputs the results of its execution to the shell which prints it.

Executing the statement grep gogo on its own, without a piped block that feeds it input, will connect its input to the user command line. In that case, use Ctrl-Z to terminate your input:

g! grep gogo
line 1
line 2 gogo
line 2 gogo
line 3
^Z
true

Notice that line 2 gogo is repeated right after you have entered it, showing that the grep statement is running in parallel. It receives the input and processes it right after you enter it.

Variable assignment and referencing

A session variable is assigned a value using the equal character ( = ) and referenced using its name preceded with a dollar character ( $ ). For example:

g! var1 = 'this is a string'
this is a string
g! echo $var1
this is a string

The assignment operation returns the assigned value.

Value types

We've seen the string type previously, which is indicated by surrounding text with single quotes ( ' ).

A list is a sequence of terms separated by whitespace characters and is delimited by an opening and a closing square bracket.

For example:

g! days = [ mon tue wed thu fri sat sun ]
mon
tue
wed
thu
fri
sat
sun

Here the variable, days, was created, assigned the list as a value, and stored in the session.

A map is a list of assignments, the value is assigned to the key using the equal character ( = ) . For example:

For example:

g! sounds = [ dog=bark cat=meow lion=roar ]
dog bark
cat meow
lion roar

Here, the variable sounds is assigned a map with the preceding key value pairs.

Object properties and operations

The shell uses a mapping process that involves reflection to find the best operation to perform for a request. We're not going to go into the details of how this happens; instead, we'll give a few examples of the operations that can be performed. We'll see a few others as we go along.

In the same session, days and sounds are defined previously to retrieve an entry in the $days list:

g! $days get 1
tue

To retrieve an entry in the sounds map

g! $sounds get dog
bark

An example we've seen earlier is the bundles command used when illustrating the piping. Bundles was mapped to the method getBundles() from the Gogo Runtime bundle BundleContext instance. Another property of this object that we'll use in the next section is bundle &ltid> to get a bundle object instance using getBundle(long).

Execution quotes

Similar to the UNIX back-quote syntax, but providing one that's simpler for a lightweight parser, the execution quotes are used to return the output of an executed program.

For example:

g!(bundle 1) location
file:/C:/felix/bundle/org.apache.felix.bundlerepository-1.6.2.jar

Here, (bundle 1) has returned the bundle with ID 1, which we've re-used to retrieve the property location making use of Gogo's reflexion on beans (location is mapped to getLocation() on the Bundle object ).

Commands and scopes

The Gogo Runti me command processor is extensible and allows any bundle to register the commands it needs to expose to the user. Then, when the user types a command, the processor will attempt to find the method that's best fit to be executed, based on the command name and passed arguments.

However, there are potential cases where two bundles would need to register the same command name. To avoid this clash, commands are registered with an opti onal scope. When there is no ambiguity as to which scope the command belongs to, the command can be used without a scope; otherwise, the scope must be included.

The scope of a command is specified by pre-pending it to the command, separated from the command with a colon ( : ). In the previous examples, we've used the grep command, which is in the gogo scope. In this case, grep and gogo:grep achieve the same result.

We will look closer at the command registration mechanism.

Let's take a tour of some of the commands available in the Felix distribution.

At the time of writing of this article, the Gogo bundles are at version 0.6.0, which means that they are not yet finalized and may change by the time they are released with version 1.0.

felix scope commands

One of the many powerful features of Felix (and OSGi-compliant applications in general) is that many actions can be applied on bundles without needing to restart the framework. Bundles can be installed, updated, uninstalled, and so on while the remaining functionality of the framework is active.

The following are some of the available commands and a description of their usage. We will get to use many of those as we go along, so you need not worry much about learning them by heart. Just know they exist.

Listing installed bundles: lb

One of the most frequently used shell commands is the list bundles command (lb) , which gives a listing of the currently installed bundles, showing some informationon each of them.

Let's check what's running on our newly installed framework:

g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.6.0)
3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
4|Active | 1|Apache Felix Gogo Shell (0.6.0)

The listing provides the following useful information about each bundle:

  • Each bundle is given a unique id on install—this ID is used by commands such as update or uninstall to apply acti ons on that bundle
  • The bundle's start level
  • The bundle's name and version

This command also takes a parameter for filtering the bundles list. For example, to include only bundles that have 'bundle' in their name:

g! lb bundle
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)

help

The help command provides hints on the usage of commands.

When called without any parameters, the help command gives a listing of the available commands:

g! help
felix:bundlelevel
felix:cd
felix:frameworklevel
felix:headers
felix:help
felix:inspect
felix:install
felix:lb
felix:log
felix:ls
felix:refresh
felix:resolve
felix:start
felix:stop
felix:uninstall
felix:update
felix:which
gogo:cat
gogo:each
gogo:echo
gogo:format
gogo:getopt
gogo:gosh
gogo:grep
gogo:not
gogo:set
gogo:sh
gogo:source
gogo:tac
gogo:telnetd
gogo:type
gogo:until
obr:deploy
obr:info
obr:javadoc
obr:list
obr:repos
obr:source

More help on the syntax of each command can be requested by typing help &ltcommand-name>.

For example, for more help on the repos command:

g! help repos


repos - manage repositories
scope: obr
parameters:
String ( add | list | refresh | remove )
String[] space-delimited list of repository URL

When the command is available with multiple signatures, a help block per signature is provided, for example:

g! help help


help - displays information about a specific command
scope: felix
parameters:
String target command

help - displays available commands
scope: felix

Here, the help command has 2 syntaxes: one that takes a parameter (the target command), and another that takes no parameters. We've used the first one to get help on help.

Some commands may have not registered help content with the shell service. Those will show minimal information using help &ltcommand>. In most cases, they expose a separate help listing—usually &ltcommand> -? or &ltcommand> -- help.

install

The install command is used to instruct Felix to install an external bundle. The syntax is as follows:

g! help install


install - install bundle using URLs
scope: felix
parameters:
String[] target URLs

Each bundle is located using the URL and is downloaded to the local cache for installation.

Once a bundle is installed, it is given a unique id. This ID is used to refer to this bundle when using commands such as update or uninstall. For example:

g! install http://www.mysite.com/testbundle-1.0.0.jar
Bundle ID: 7

Here, the bundle I've just installed has the ID 7.

g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.6.0)
3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
4|Active | 1|Apache Felix Gogo Shell (0.6.0)
7|Installed | 1|Test Bundle (1.0.0)

In cases where many bundles are to be installed from the same base URL, you may want to set a session variable with the common base URL to simplify the task.

For example, instead of executing:

g! install http://site.com/bundle1.jar http://site.com/bundle2.jar

You would write:

g! b = http://site.com
g! install $b/bundle1.jar $b/bundle2.jar

OSGi and Apache Felix 3.0 Beginner's Guide Build your very own OSGi applications using the flexible and powerful Felix Framework
Published: November 2010
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on this subject, see here.)

update

As newer versions of bundles are released, it is easy to update the installed bundle with a newer version by using the update command.

The update command takes a bundle ID and an optional source URL as parameters. Its syntax is:

g! help update


update - update bundle
scope: felix
parameters:
Bundle target bundle

update - update bundle from URL
scope: felix
parameters:
Bundle target bundle
String URL from where to retrieve bundle

For example:

g! update 7 http://www.mysite.com/testbundle-1.0.1.jar
g!
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.6.0)
3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
4|Active | 1|Apache Felix Gogo Shell (0.6.0)
7|Installed | 1|Test Bundle (1.0.1)

Notice that the bundle ID remains unchanged.

When a source URL is not provided, the bundle is updated from the same location it was installed from.

resolve

The resolve command requests that the framework undergo the resolution process for the given bundle.

The syntax of this command is as follows:

g! help resolve


resolve - resolve bundles
scope: felix
parameters:
Bundle[] target bundles (can be null or empty)

If no parameter is provided, then the framework will resolve all unresolved bundles. To resolve specific bundles, the list ids of the bundles to be resolved are passed as parameters.

stop and start

The stop and start commands take a space-separated sequence of bundle IDs to stop or to start.

The stop command syntax is as follows:

g! help stop


stop - stop bundles
scope: felix
flags:
-t, --transient stop bundle transiently
parameters:
Bundle[] target bundles

Use the -t (or --transient) flag to stop the bundle in transient mode, that is, not saving its state to the persisted auto-start state. The framework will not remember this bundle as having been stopped the next time it is restarted.

The start command syntax is similar to the stop command:

g! help start


start - start bundles
scope: felix
flags:
-p, --policy use declared activation policy
-t, --transient start bundle transiently
parameters:
String[] target bundle identifiers or URLs

It uses the -t flag in the same way as the stop command

Use the -p (of --policy) flag to use the activation policy declared in the Bundle-ActivationPolicy header.

To exit the framework, use stop 0 which stops the System Bundle, thus launching the stop process for the other bundles before shutting down.

uninstall

The uninstall command is used to remove one or more bundles from the framework. The bundles are first stopped and then uninstalled.

The usage of this command is as follows:

g! help uninstall


uninstall - uninstall bundles
scope: felix
parameters:
Bundle[] target bundles

The list of IDs of bundles to be uninstalled is passed as a parameter.

refresh

The refresh command forces the update of the packages exported by the refreshed bundles. The refresh is performed to the provided bundles and the bundles that depend on them. It is typically used aft er an update or aft er an uninstall of a bundle, to update the packages exported by an updated bundle and to completely remove those of an uninstalled one.

The syntax of the refresh command is as follows:

refresh - refresh bundles
scope: felix
parameters:
Bundle[] target bundles (can be null or empty)

The syntax of the refresh command is as follows:

To refresh specific bundles, the ids of those bundles are passed as parameters. Otherwise, calling refresh with no parameters refreshes all bundles that were updated or uninstalled.

headers and inspect

The headers and inspect commands provide valuable information on how a bundle is perceived by the framework. The headers command lists the bundle headers in the main section of the bundle's manifest. Its usage is as follows:

g! help headers


headers - display bundle headers
scope: felix
parameters:
Bundle[] target bundles

For example, to display the headers of the bundle Apache Felix Bundle Repository, use:

g! headers 1


Apache Felix Bundle Repository (1)

----------------------------------

Bnd-LastModified = 1272565441581

Build-Jdk = 1.6.0_17

Built-By = gnodet

Bundle-Activator = org.apache.felix.bundlerepository.impl.Activator

Bundle-Description = Bundle repository service.

Bundle-DocURL = http://felix.apache.org/site/apache-felix-osgi-

bundle-repository.html

Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt

Bundle-ManifestVersion = 2

Bundle-Name = Apache Felix Bundle Repository

Bundle-Source = http://felix.apache.org/site/downloads.cgi

Bundle-SymbolicName = org.apache.felix.bundlerepository

Bundle-Url = http://felix.apache.org/site/downloads.cgi

Bundle-Vendor = The Apache Software Foundation

Bundle-Version = 1.6.2

Created-By = Apache Maven Bundle Plugin

...

The inspect command displays various information on a bundle's dependencies, requirements, packages it exports, and so on. Its usage is as follows:

g! help inspect


inspect - inspects bundle dependency information
scope: felix
parameters:
String (package | bundle | fragment | service)
String (capability | requirement)
Bundle[] target bundles

The first parameter is the inspection type:

  • package to inspect package-related information, for example, which packages the specified bundles import from or export to other bundles
  • bundle to inspect the requirements or capabilities of the given bundles
  • fragment to inspect fragment-related information, such as a fragment's host or the list of hosted fragments
  • service to inspect the bundles service related information, such as the list of imported or exported services

The second parameter is the direction of the inspection, with respect to the bundle:

  • capability to inspect what the specified bundles can give to the platform
  • requirement to inspect what the specified bundles need from the platform

The remaining parameters are one or more bundles to be inspected.

For example, the package capability of the bundle Apache Felix Bundle Repository are as follows:

g! inspect package capability 1
org.apache.felix.bundlerepository [1] exports packages:
-------------------------------------------------------
org.apache.felix.bundlerepository; version=2.0.0 imported by:
org.apache.felix.gogo.command [2]

This says that the bundle exports a package (org.apache.felix.bundlerepository), which is imported by bundle 2, Apache Felix Gogo Command.

Inspect also accepts shorthand first letters for the inspection type and direction. For example, the command inspect p c 1 can be used instead of the longer one seen previously.

which

The which command will provide information on where a given bundle loads a given class. This command is useful when investigating problems related to conflicts between classes or issues with their visibility.

Its syntax is as follows:

g! help which


which - determines from where a bundle loads a class
scope: felix
parameters:
Bundle target bundle
String target class name

The first parameter is the bundle to use as the context for the class loading and the second is the name of the class to load.

For example, to know where the bundle Apache Felix Gogo Command loads its org.apache.felix.bundlerepository.Repository class, use:

g! which 2 org.apache.felix.bundlerepository.Repository
Loaded from: org.apache.felix.bundlerepository [1]

The answer is bundle 1: Apache Felix Bundle Repository. The result shows the bundle symbolic name and the bundle ID.

log

The log command allows us to peek into the list of the last few log entries. Its usage is as follows:

g! help log


log - display some matching log entries
scope: felix
parameters:
int maximum number of entries
String minimum log level [ debug | info | warn | error ]

log - display all matching log entries
scope: felix
parameters:
String minimum log level [ debug | info | warn | error ]

The default Felix distribution doesn't come with a log service installed, so running this command at this point will issue a warning:

g! log debug
Log reader service is unavailable.

cd and ls

Some of the commands that are available through this console may read from or write to files. For example, the grep command can read a file and display the lines that match a given pattern. It will read the file relative to the shell session working directory. We will look at this and other file manipulating commands in a shortwhile.

The cd and ls commands are very similar to their Unix counterparts.

The cd command is used to display or change the current shell working directory. Its usage is as follows:

g! help cd


cd - change current directory
scope: felix
parameters:
CommandSession automatically supplied shell session
String target directory

cd - get current directory
scope: felix
parameters:
CommandSession automatically supplied shell session

When called without parameters, it will display the current working directory. To change the current directory, pass the target directory as a parameter.

The ls command is used to list the contents of a directory. Its syntax is as follows:

g! help ls


ls - get specified path contents
scope: felix
parameters:
CommandSession automatically supplied shell session
String path with optionally wild carded file name

ls - get current directory contents
scope: felix
parameters:
CommandSession automatically supplied shell session

The path of the directory to be listed is passed as a parameter. If no parameters are passed, then the contents of the current working directory are shown.

For example, the contents of the current directory are as follows:

g! ls
C:\felix\bin
C:\felix\bundle
C:\felix\conf
C:\felix\DEPENDENCIES
C:\felix\doc
C:\felix\felix-cache
C:\felix\LICENSE
C:\felix\LICENSE.kxml2
C:\felix\NOTICE
C:\felix\run.bat

Changing to a sub-directory:

g! cd bundle
Name bundle
CanonicalPath C:\felix\bundle
Parent C:\felix
Path C:\felix\bundle
AbsoluteFile C:\felix\bundle
AbsolutePath C:\felix\bundle
CanonicalFile C:\felix\bundle
ParentFile C:\felix

OSGi and Apache Felix 3.0 Beginner's Guide Build your very own OSGi applications using the flexible and powerful Felix Framework
Published: November 2010
eBook Price: $26.99
Book Price: $44.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on this subject, see here.)

frameworklevel and bundlelevel

The frameworklevel and bundlelevel commands allow us to modify start levels.

The frameworklevel command is used to get or set the framework's active start level. Its syntax is as follows:

g! help frameworklevel


frameworklevel - query framework active start level
scope: felix
frameworklevel - set framework active start level
scope: felix
parameters:
int target start level

To get the active start level of the framework, use the command without any parameters:

g! frameworklevel
Level is 1

To change it, pass the target start level as a parameter.

The bundle level displays and manipulates the bundle's start levels. Its syntax is:

g! help bundlelevel


bundlelevel - set bundle start level or initial bundle start level
scope: felix
flags:
-i, --setinitial set the initial bundle start level
-s, --setlevel set the bundle's start level
parameters:
int target level
Bundle[] target identifiers

bundlelevel - query bundle start level
scope: felix
parameters:
Bundle bundle to query

To query the start level of a bundle, use the command with one parameter—the bundle ID:

g! bundlelevel 2
org.apache.felix.gogo.command [2] is level 1

To change the framework's initial bundle start level, use the command with the option -i set:

g! bundlelevel -i 2

This has set the initial bundle start level to 2 for newly installed bundles.

To change the start level of one or more bundles, use the -s option followed by the target start level and the list of bundles to modify.

 

gogo scope commands

The commands in the gogo scope provide a few additional tools that are especially useful when scripting a recurrent set of operations. We will cover some of them here.

echo

The echo command will evaluate its arguments and display the result on the console. For example:

g! var1 = 'this is'
this is
g! var2 = ' a string'
a string
g! echo $var1$var2
this is a string

grep

The grep command is used to search the input for lines that match a given pattern; it is very similar to the Unix grep tool. The input is either standard input, the output of a command piped to grep, or the contents of files.

The grep command will return false if there were no lines in the input that match the pattern. It will return true otherwise.

Its usage is as follows:

g! grep -?
grep - search for PATTERN in each FILE or standard input.
Usage: grep [OPTIONS] PATTERN [FILES]
-? --help show help
-i --ignore-case ignore case distinctions
-n --line-number prefix each line with line number within its
input file
-q --quiet, --silent suppress all normal output
-v --invert-match select non-matching lines
true

The PATTERN argument is an encoded regular expression (regex) that defines the sequence of characters that are considered a match. It follows the regex pattern format, defined for the Java java.util.regex.Pattern class.

You can visit the following for more information on regex:

http://download-llnw.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html

 

For example, to grep the output of the lb command for lines containing the string Apache:

g! lb | grep Apache
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.6.0)
3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
4|Active | 1|Apache Felix Gogo Shell (0.6.0)
true

The -i (short for --ignore-case) option makes the pattern not case sensitive, thus matching both the lowercase and uppercase for a letter.

The -n (or --line-number) option requests that the command include the line number when printing the results. For example:

g! lb | grep -n Apache
4: 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
5: 2|Active | 1|Apache Felix Gogo Command (0.6.0)
6: 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
7: 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
true

The -q option (also --quiet or --silent) is used to suppress the grep command output. The command will only return true or false after it is finished with the input. This is especially useful when using the command for its returned value only (as a loop guard, for example).

The -v (or --invert-match) is used to show the lines that don't match the pattern (inverse match). For example:

g! lb | grep -v Apache
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
true

cat

The cat command is used to concatenate files and display their contents on the console. It takes one or more filenames relative to the current shell session directory (see cd and ls in the previous section) and displays them.

For example, to display the run.bat file we had created at the beginning of this article, use the following:

g! cat run.bat
java -jar bin/felix.jar

Separate the arguments with whitespace to display more than one file sequentially.

tac

The tac command, in a way, is the opposite of the cat command. Here it takes the text from the standard input and either returns it as a string or as a list for use as input for another command or writes it to a file.

The syntax is as shown here:

g! tac -?
tac - capture stdin as String or List and optionally write to file.
Usage: tac [-al] [FILE]
-a --append append to FILE
-l --list return List<String>
-? --help show help

The following example makes a list of the input and then gets the second item in the resulting list.

g! var1 = tac -l ; $var1 get 1
a1
a2
a3
^Z
a2

Notice the use of Ctrl-Z (shows as ^Z on the console display) to terminate user input.

Passing a filename as an argument will create the file and write the input text to it. The -a or --append option can be used to append to an existing file. For example, this will create a file from the standard input and display its contents using the cat command:

g! tac test.out ; cat test.out
this is a test, line 1
last line
^Z
this is a test, line 1
last line

The input of the tac command can also be the piped output of another. For example, the next command will make a backup copy of our test.out file created previously:

g! cat test.out | tac test.out.bak
this is a test, line 1 last line
g!
g! cat test.out.bak
this is a test, line 1
last line

set

The set command is used to inspect session variable information, as well as turn session tracing on or off.

Help on the usage of the set command can be retrieved as follows:

g! set -?
set - show session variables
Usage: set [OPTIONS] [PREFIX]
-? --help show help
-a --all show all variables, including those starting with .
-x set xtrace option
+x unset xtrace option
If PREFIX given, then only show variable(s) starting with PREFIX

The -x option is used to turn execution traces on. For example, taking one of the samples used previously, without setting the xtrace option:

g! var = 'this is a string'
this is a string
g! echo $var
this is a string

When setting the xtrace option, the shell will output a trace message for each command it will execute and for each result of that command. In this case:

g! set -x
g!
g! var = 'this is a string'
+ var '=' 'this is a string'
this is a string
g! echo $var
+ echo $var
this is a string

Setting shell execution traces on is especially useful when working on a script (see the previous source).

Use set +x to turn traces off.

Summary

In this article, you have learned about the Gogo command-line language and some of its commands. By now, you should:

  • Understand the Gogo command syntax
  • Know about most of the commands available in the Gogo shell
  • Know how to get help on the usage of commands

Further resources on this subject:


About the Author :


Walid Joseph Gédéon

Walid Joseph Michel Gédéon is a painter and sculptor living in the south of France. He is also a telecommunications network and OSS senior expert. Over the past decade, he has focused his attention on the design and integration of distributed operations support systems in the real world (and around it).

Books From Packt


Apache JMeter
Apache JMeter

Apache MyFaces 1.2 Web Application Development
Apache MyFaces 1.2 Web Application Development

Apache MyFaces Trinidad 1.2: A Practical Guide
Apache MyFaces Trinidad 1.2: A Practical Guide

Apache CXF Web Service Development
Apache CXF Web Service Development

Apache Roller 4.0 – Beginner's Guide
Apache Roller 4.0 – Beginner's Guide

Apache Geronimo 2.1: Quick Reference
Apache Geronimo 2.1: Quick Reference

Apache Maven 2 Effective Implementation
Apache Maven 2 Effective Implementation

Apache Struts 2 Web Application Development
Apache Struts 2 Web Application Development


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
2
U
e
j
2
D
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software