The ldomterm terminal emulator

The ldomterm application is the preferred away of using DomTerm, so plain domterm is normally installed as an alias for it.

If you run ldomterm with no arguments, you get a fairly nice terminal emulator, just as if you’d start xterm, say.

The actual ldomterm program is primarily a server for WebSockets and http. When it receives a connection, it runs a specified command, by default a shell.

Unless --port is specified, ldomterm will automatically start a browser session (the “front-end”) that connects to the server. The default is currently as if you specified --chrome, or --browser (if the Google Chome browser is not found).

ldomterm [options] [command arg...]

The command is the program that gets run. By default it is a shell such as /bin/bash.

The following options control which front-end (usually a browser), if any, is started.


Use program as a browser to run DomTerm in. If program is not specified, creates a new window or tab in your preferred desktop browser.

If program is specified, instead creates a window in the specified browser, where program is the name of a browser program that takes a single URL argument. The program can be a multi-word template, where %U replaced a URL generated by ldomterm.

Using firefox, chrome, or google-chrome for program enables some special tricks to search for those browsers. (Using chrome or google-chrome has the same effect.)


This uses the Google Chrome browser, started using the --app= option, so you get a fresh chrome-less window (with no menubar or toolbar).

This works well and the performance is good. This method provides no menubar or context-menu customization (so far).

This is currently the default, when available.


This is similar to the --chrome option, but using bare Firefox browser window, with a custom menubar, and custom context menu (what you get by right-clicking).

This is potentially a very nice terminal emulator, though it is based on XUL, which is being phased out.


Experimental (not all functionality is working). Either option (they do the same thing) runs qtdomterm with the --connect option, after starting up a websockets server.

--port portnum

Start a server, listening on the specified portnum. A portnum of 0 lets the system choose an available port, which is printed out. No front-end is started.


Only allow a single connect before shutting down. This option is the default unless --port is specified.

There are other ldomterm options which useful if you want to run DomTerm as a server.