INTRODUCTION

Any program can only be really useful if it complies with the Unix philosophy. Web browsers (and other tools that work with HTML, such as feed readers) are frequent violators of this principle:

The Uzbl project was started as an attempt to resolve this.

EDITIONS

"Uzbl" is an umbrella project consisting of different flavors. In the future more things may come, but for now:

uzbl-core: main component meant for integration with other tools and scripts

uzbl-browser: a complete browser experience based on uzbl-core

uzbl-tabbed: wraps around uzbl-browser and multiplexes it

Throughout the documentation, when referring to uzbl we mean uzbl-core, unless otherwise specified.

CONFIGURATION / CONTROL:

The general idea is that Uzbl by default is very bare bones. You can send it commands to update settings and perform actions, through various interfaces. There is a limited default configuration. Please see config.h to see what it contains. By default, there are no keybinds defined at all. (Default keybinds would work counterproductive when you try to customize). For examples of the possibilities what you can do, please see the sample config(s), and uzbl wiki page.

There are several interfaces to interact with Uzbl:

When uzbl forks a new instance (eg "open in new window") it will use the same command line arguments (eg the same --config <file>), except --uri and --named. If you made changes to the configuration at runtime, these are not passed on to the child.

Uzbl-browser

Uzbl-tabbed

COMMAND SYNTAX

Uzbl will read commands via standard input, named FIFO pipe (if fifo_dir is set) and Unix socket (when socket_dir is set). For convenience, uzbl can also be instructed to read commands from a file on startup by using the --config option. Indeed, the config file is nothing more than a list of commands.

Each command starts with the name of a command or a uzbl variable that expands to it. A command is terminated by a newline. Empty lines and lines that start with the hash sign are ignored by the parser. Command names are always written in lowercase.

The following commands are recognized:

VARIABLES AND CONSTANTS

Uzbl has a lot of internal variables and constants. You can get the values (using the print command, see above), and for variables you can also change the value at runtime. Some of the values can be passed at start up through commandline arguments, others need to be set by using commands (eg in config file).

Variables

Constants (not dumpable or writeable)

VARIABLE EXPANSION AND COMMAND / JAVASCRIPT SUBSTITUTION

Variable expansion works pretty much as known from shell interpreters (sh, bash, etc.). This means you can construct strings with uzbl variables in them and have uzbl replace the variable name with its contents.

In order to let uzbl know what to expand you'll need to prepend @ to the variable name:

print The variable \@show_status contains @show_status

The above example demonstrates two things:

Command substitution will launch any commands and substitute the call with the return value of the command. There are two methods:

This method allows you to use POSIX shell syntax in your commands.

This example will execute uname directly.

Note that you can access any uzbl variable from within a command substitution:

print @(echo -n 'Accessing the show_status var from an external script, value: @show_status')@

JavaScript substitution works in the exact same way as command substitution but you will need to enclose the JavaScript in @< >@.

print The currently viewed document contains @<document.links.length>@ links

The @<>@ substitution can also load JavaScript from a file, syntax: @<+filename>@

print JS return value from file: @<+/path/to/file.js>@

Variable expansion also works within a JavaScript substitution.

When a piece of text needs to be XML escaped after it is expanded (for example, in the status bar format), you can use @[ ]@ substitution:

print This text is XML escaped: @[<&>]@

# prints: This text is XML escaped: &lt;&amp;&gt;

NOTE: If you need to use literal @ or \ characters you will need to escape them:

print At sign: \@  and backslash: \\

TITLE AND STATUS BAR EVALUATION

The contents of the status bar can be customized by setting the status_format variable. The contents of the window title can be customized by setting the title_format_short variable (which is used when the status bar is displayed) and the title_format_long variable (which is used when the status bar is not displayed). Their values can be set using the expansion and substitution techniques described above.

These variables are expanded in multiple stages; once when the variable is set, and again every time that the status bar or window title are updated. Expansions that should be evaluated on every update need to be escaped:

set title_format_short = @(date)@
# this expansion will be evaluated when the variable is set.
# the title will stay constant with the date that the variable was set.

set title_format_short = \@(date)\@
# this expansion will be evaluated when the window title is updated.
# the date in the title will change when you change pages, for example.

set title_format_short = \\\@(date)\\\@
# the title will stay constant as a literal "@(date)@"

The status_format and status_format_right variables can contain Pango markup . In these variables, expansions that might produce the characters <, & or > should be wrapped in @[ ]@ substitutions so that they don't interfere with the status bar's markup; see the sample config for examples.

EXTERNAL SCRIPTS

You can use external scripts with Uzbl the following ways:

Have a look at the sample configs and scripts!

Scripts called by uzbl (with spawn, sync_spawn, sh or sync_sh) have access to the following environment variables:

Handler scripts (download_handler, cookie_handler, scheme_handler, request_handler, and authentication_handler) are called with special arguments:

Formfiller.sh

Example config entries for formfiller script

set formfiller = spawn @scripts_dir/formfiller.sh
@cbind    za        = @formfiller add
@cbind    ze        = @formfiller edit
@cbind    zn        = @formfiller new
@cbind    zl        = @formfiller load
@cbind    zo        = @formfiller once

NEW action generates new file with formfields for current domain. Note that it will overwrite existing file.

EDIT action calls an external editor with curent domain profiles.

ADD action adds another profile to current domain. Remember to name the profiles, by default the have a name with random numbers.

LOAD action loads form data. If there is more then one profile, it will call dmenu first to choose the profile you want to fill in the form.

ONCE action generates a temp file with formfields including the textareas and after closing the editor, it will load the data into the formfields. The temp file is removed

HTTP/BASIC AUTHENTICATION

You can use the authentication_handler variable to denote how http authentication should be handled. If this variable is:

Example:

set authenticationhandler = syncspawn /patch/to/your/script

Script will be executed on each authentication request. It will receive four auth-related parameters:

$1 authentication zone unique identifier (may be used as 'key')
$2 domain part of URL that requests authentication
$3 authentication realm
$4 FALSE if this is the first attempt to authenticate, TRUE otherwise

Script is expected to print exactly two lines of text on stdout (that means its output must contain exactly two '\n' bytes). The first line contains username, the second one - password. If authentication fails, script will be executed again (with $4 = TRUE). Non-interactive scripts should handle this case and do not try to authenticate again to avoid loops. If number of '\n' characters in scripts output does not equal 2, authentication will fail. That means 401 error will be displayed and uzbl won't try to authenticate anymore.

The simplest example of authentication handler script is:

!/bin/sh

[ "$4" == "TRUE ] && exit echo alice echo wonderland

This script tries to authenticate as user alice with password wonderland once and never retries authentication. See examples for more sofisticated, interactive authentication handler.

WINDOW MANAGER INTEGRATION

As mentined before, the contents of the window title can be customized by setting the title_format_short variable and the title_format_long variable (see above to figure out when each of them is used). You can also set icon variable to path of the icon file. Some advanced window managers can also take WM_WINDOW_ROLE in account, which can be set by modifying window_role variable.

There is currently no support of updating window icon automatically to site's favicon, but there are some scripts for that at wiki pages.

Uzbl sets special X window property UZBLURI which is always the uri of the page loaded into uzbl, except for web inspector windows which has no UZBLURI.

EVENTS

Unlike commands, events are not handled in uzbl itself, but are propagated (dispatched) asynchronously through a text stream on stdout and/or through a socket. You'll usually use uzbl by piping it's output to a so-called "event manager" (EM), or by having the EM listen to a socket.

The EM allows:

Note: Cookie events are sent in addition to (optionally) being handled by the cookie handler (set by the cookiehandler var). If using a handler it will take precedence before the internal state configured by (add|delete)cookie commands.

Events have this format:

 EVENT [uzbl_instance_name] EVENT_NAME event_details

Reported events

Events/requests which the EM and its plugins listens for

COMMAND LINE ARGUMENTS

uzbl is invoked as

uzbl-(core|browser|tabbed) [ arguments ] [ uri ]

where arguments and uri are both optional. arguments can be:

uzbl-core scheme://address will work as you expect. If you don't provide the scheme:// part, it will check if the argument is an existing file in the filesystem, if it is, it will prepend file://, if not, it will prepend http://.

BUGS

Please report new issues to the Uzbl bugtracker.