Inspect X Toolkit Resources with appres

appres shows you the X resources an application, a named instance, or a widget subhierarchy would actually pick up. It is a read-only inspection: it never edits your resource database or changes the program being inspected. Allow about 10 minutes if you already have an X display, longer if you need to arrange a test one first.

Before you start

The examples use appres 1.0.6, installed here by the Debian x11-utils package. You need the command and an accessible X display: a normal desktop session usually supplies one, but a remote shell, a container, a cron job, or a machine running only Wayland may not.

Check the package and command without changing anything:

command -v appres
dpkg-query -W -f='\${Package} \${Version}\n' x11-utils
appres -V

Expected output includes a path such as /usr/bin/appres, the installed x11-utils version, and:

appres 1.0.6

If the version command instead says Can't open display, the program is installed fine, it just cannot reach the X server. Fix the session or the DISPLAY value first. A missing display is not evidence the application has no resources, just that you have not asked it yet.

1. List resources for an application class

Pass the application class as the first argument. X resource class names are conventionally capitalised, so use the class the target program actually understands:

appres XTerm

appres prints the resources an xterm program with the XTerm class can load. The exact lines come from the resource database on the connected display. An empty result is a valid answer: it means no matching resources exist there, not that the command failed.

Keep the command's diagnostic separate from its resource output when you check it in a script:

if appres XTerm > /tmp/xterm-resources.txt; then
    sed -n '1,20p' /tmp/xterm-resources.txt
else
    printf '%s\n' 'appres could not inspect this display' >&2
    exit 1
fi

That is a temporary report, not a configuration file. Remove it once you have finished reading it:

rm -- /tmp/xterm-resources.txt

Checkpoint: class versus instance

A class describes a family of applications. An instance identifies one particular launch. To match an instance explicitly, give it after the class:

appres XTerm myxterm

That asks for resources matching class XTerm and instance myxterm. The same instance can also be selected with the normal Xt toolkit option:

appres XTerm -name myxterm

Pick one form and stick to it. Supplying an instance as the second positional argument and also using -name makes the query harder to read, and can quietly produce a different result than the one you intended. If you are investigating a real program, copy its actual class and instance names rather than guessing from its executable name.

2. Inspect a widget hierarchy

Resource matching can go deeper than the application level. Give dot-separated class and instance paths with the same number of components:

appres Xman.TopLevelShell.Form xman.topBox.form

That checks the resource names for the xman top-level widget hierarchy. The class path and instance path run in parallel: the first class component pairs with the first instance component, and so on. A mismatched component count is a common mistake, and it will not give you a useful match.

To restrict the result to one hierarchy level, add -1:

appres XTerm.VT100 xterm.vt100 -1

Here the result is limited to the level matching the xterm vt100 widget. Do not add a toolkit instance option when you are already using hierarchical class and instance names: the hierarchy already supplies the instance path for this query.

3. Check the default query carefully

With no application class at all, appres uses the special class -AppResTest-:

appres

Easy to miss when a command gets copied into a script. It is not a request for every resource on the display, it asks only for entries matching that special test class, so an empty result is normal unless your resource database happens to contain matching entries.

Common failure points

• No display. Can't open display means the process cannot connect to an X server. Check DISPLAY and the session that owns the server. On a remote connection, use the X forwarding setup appropriate to that connection rather than copying a display value from another machine.
• Unexpectedly empty output. Resource lookup is specific to class, instance, and hierarchy. Try the class-only query first, then add the instance or path one component at a time.
• Wrong capitalisation. Class and instance names are different identifiers. Confirm them from the target toolkit or application rather than changing case until something appears.
• Confusing inspection with editing. appres only reports what it sees. To change an X resource database you would use a separate tool such as xrdb; do not swap an inspection command for a write command while diagnosing a live session.

No elevated privileges are needed here. If a resource file or application is readable only by another account, fix that separately rather than running the whole diagnostic as root: a root process may connect to a different display session and hand you a misleading result.

Done means

• appres -V reports the installed version and can reach the intended display.
• You have a class-only result before testing instance or hierarchy-specific matching.
• Any empty result has been explained by the selected class, instance, path, or display.
• You have not changed the X resource database or modified application configuration while investigating it.