There is a number of environment variables that alter the behavior of the Urbi tools.
Some variables define search-paths, i.e., colon-separated lists of directories in which library files (urbiscript programs, UObjects and so forth) are looked for.
The tools have predefined values for these variables which are tailored for your installation — so that Urbi tools can be run without any special adjustment. In order to provide the user with a means to override or extend these built-in values, the path variables support a special syntax: a lone colon specifies where the standard search path must be inserted. See the following examples about URBI_PATH.
# Completely override the system path. First look for files in# /home/jessie/urbi, then in /usr/local/urbi.
export URBI_PATH=/home/jessie/urbi:/usr/local/urbi
# Prepend the previous path to the default path. This is dangerous as# it may result in some standard files being hidden.
export URBI_PATH=/home/jessie/urbi:/usr/local/urbi:
# First look in Jessie’s directory, then the default location, and# finally in /usr/local/urbi.
export URBI_PATH=/home/jessie/urbi::/usr/local/urbi
# Extend the default path, i.e., files that are not found in the# default path will be looked for in Jessie’s place, and then in# /usr/local/urbi
export URBI_PATH=:/home/jessie/urbi:/usr/local/urbi
On Windows too directories are separated by colons, but backslashes are used instead of forward-slashes. For instance
Set the verbosity level of traces. This environment variable is meant for the developers of Urbi SDK, yet it is very useful when tracking problems such as a UObject that fails to load properly. Valid values are, in increasing verbosity order:
The search-path for urbiscript source files (i.e., ‘*.u’ files).
The Urbi SDK is relocatable: its components know the relative location of each other. Yet they need to “guess” the Urbi root, i.e., the path to the directory that contains the files. This variable also to override that guess. Do not use it unless you know exactly what you are doing.
The search-path for UObjects files. This is used by urbi-launch, by System.loadModule and System.loadLibrary.
This is the obsolete name for ‘global.u’.
If found in the URBI_PATH (see Section 18.1), this file is loaded by Urbi server upon start-up. It is the appropriate place to install features you mean to provide to all the users of the server. It is will be loaded via a special system connection, with its own private lobby. Therefore, purely local definitions will not be reachable from users; global modifications should be made in globally visible objects, say Global (??sec:std-Global).
If found in the URBI_PATH (see Section 18.1), this file is loaded by every connection established with an Urbi server. This is the appropriate place for enhancements local to a lobby.
This is the obsolete name for ‘global.u’.
The urbi program launches an Urbi server, for either batch, interactive, or network-based executions. It is subsumed by, but simpler to use than, urbi-launch (Section 18.5).
The ‘--fast’ flag makes the kernel run the program in “simulated time”, as fast as possible. A sleep in fast mode will not actually wait (from the wall-clock point of view), but the kernel will internally increase its simulated time.
For instance, the following session behaves equally in fast and non-fast mode:
{ sleep(2s); echo("after") } & { sleep(1s); echo("before") };[000000463] *** before[000001463] *** after
However, in non fast mode the execution will take two seconds (wall clock time), while it be instantaneous in fast mode. This option was designed for testing purpose; it does not preserve the program semantics.
This option should not be needed unless you have “stack exhausted” messages from urbi in which case you should try ‘--stack-size=512’ or more.
Alternatively you can define the environment variable URBI_STACK_SIZE. The option ‘--stack-size’ has precedence over the URBI_STACK_SIZE.
Defaults to 0.0.0.0.
The options ‘-e’, ‘-f’ accumulate, and are run in the same Lobby (??sec:std-Lobby) as ‘-i’ if used. In other words, the following session is valid:
# Create a file "two.u".
$ echo"var two = 2;">two.u
$ urbi -q -e’var one = 1;’-f two.u -i[00000000] 1[00000000] 2
one + two;[00000000] 3
Connect to an Urbi server, and fetch images from it, for instance from its camera.
The urbi-launch program launches an Urbi system. It is more general than urbi (Section 18.3): everything urbi can do, urbi-launch can do it too.
urbi-launch launches UObjects, either in plugged-in mode, or in remote mode. Since UObjects can also accept options, the command line features two parts, separated by ‘--’:
The modules are looked for in the URBI_UOBJECT_PATH. The module extension (‘.so’, or ‘.dll’) does not need to be specified.
Networking urbi-launch supports the same networking options (‘--host’, ‘--port’, ‘--port-file’) as urbi, see Section 18.3.
To launch a fresh server in an interactive session with the UFactory UObject compiled as the file ‘factory.so’ (or ‘factory.dll’ plugged in, run:
To start an Urbi server accepting connections on the local port 54000 from any remote host, with UFactory plugged in, run:
Connect to an Urbi server, and send commands or file contents to it. Stay connected, until server disconnection, or user interruption (such as C-c under a Unix terminal).
Without this option, urbi-send prompts the user to hit C-c to end the connection.
The umake programs builds loadable modules, UObjects, to be later run using urbi-launch (Section 18.5). Using it is not mandatory: users familiar with their compilation tools will probably prefer using them directly. Yet umake makes things more uniform and simpler, at the cost of less control.
Usage:
Compile the file. The files can be of different kinds:
As a convenience for common umake usages, some wrappers are provided: