Inspect and Extract GLib Resources with gresource

GTK apps love to bundle their icons, emoji and data files into a single compiled blob, and gresource is how you look inside one without guessing. By the end of this guide you will be able to inspect a compiled GLib resource bundle, find a resource path, check its metadata and extract its bytes. The examples use the installed /usr/bin/gresource and a bundle already present on this Ubuntu system.

Allow about 10 minutes. You need a shell and read access to the resource file. None of the inspection commands need elevated privileges. They read their input and write extracted data only where you explicitly redirect it.

1. Check the local command and version

The command is supplied by the libglib2.0-bin package. On this machine the package is version 2.80.0-6ubuntu3.9. gresource does not accept --version; asking for help is the useful availability check instead.

command -v gresource
dpkg-query -W -f='\${Package} \${Version}\n' libglib2.0-bin
/usr/bin/gresource help

Expected output includes the command path, the package version, and these subcommands: sections, list, details, extract and help. If your shell finds a different copy first, use /usr/bin/gresource in the remaining examples when you specifically want the Debian package version.

2. Choose the right input file

A resource file is commonly a compiled .gresource bundle. The tool can also inspect resources embedded in an ELF binary or shared library, but that support is a build-time capability, not something every installation has. The local binary reports gresource is built without elf support for ELF inputs, so start with a standalone bundle instead.

RESOURCE=/usr/share/gtk-3.0/emoji/de.gresource
test -r "$RESOURCE" && echo "readable: $RESOURCE"

Expected output is readable: /usr/share/gtk-3.0/emoji/de.gresource. Swap in your own bundle when applying the guide elsewhere. Do not use sudo merely to inspect a file you can already read.

3. List resource paths

Use list to see the paths the bundle exposes. The optional path argument filters the result by a matching resource path, handy when a large bundle contains many entries.

/usr/bin/gresource list "$RESOURCE"
/usr/bin/gresource list "$RESOURCE" /org/gtk/libgtk/emoji

For the example bundle, both commands show:

/org/gtk/libgtk/emoji/de.data

Keep the leading slash and copy the path exactly. A filesystem path such as /usr/share/gtk-3.0/emoji/de.data is not the same thing as the resource path stored inside the bundle.

4. Inspect size and compression

Use details when a name alone is not enough. It prints the resource size, compression marker and resource path. Supplying the path narrows the result to one entry.

/usr/bin/gresource details "$RESOURCE" /org/gtk/libgtk/emoji/de.data

The installed bundle reports:

170431 u /org/gtk/libgtk/emoji/de.data

That output is metadata, not the file contents. The size is a useful sanity check before extraction. Do not infer a human-readable format from the path or the compression marker.

5. Extract bytes to a new file

extract writes the selected resource to standard output. Redirect it to a destination when you need a file. This is also where a common distraction becomes a real error: the resource may be binary, so do not let it spill into your terminal.

set -o noclobber
/usr/bin/gresource extract "$RESOURCE" /org/gtk/libgtk/emoji/de.data > /tmp/de.data
wc -c /tmp/de.data

Expected output is:

170431 /tmp/de.data

If the destination already exists, no-clobber makes the shell refuse the redirection outright. To undo this example, remove the temporary file once you have finished inspecting it:

rm -- /tmp/de.data

This removes only the extracted copy in /tmp; it does not touch the resource bundle. Do not reach for a broad recursive removal command when a single known file is all you need to clean up.

6. Handle embedded resources and sections

For an ELF file containing more than one resource section, first ask sections for the section names:

/usr/bin/gresource sections /path/to/application

Then select one section before the subcommand:

/usr/bin/gresource --section SECTION_NAME list /path/to/application
/usr/bin/gresource --section SECTION_NAME extract /path/to/application /resource/path > /tmp/resource.out

Replace both placeholders with values printed by sections and list. The option belongs before the command name. If the local tool says it was built without ELF support, these commands cannot inspect an embedded resource with that binary: use a GLib build with ELF support, or obtain the standalone bundle instead. That is a capability limitation, not evidence the application has no resources.

Common traps

• "Don't know how to handle". The input is not a readable standalone bundle, or it is an ELF file unsupported by this build. Check the path and try sections only when ELF support is available.
• No matching resource. List the bundle again and copy the complete, leading-slash resource path. Resource paths are not host filesystem paths.
• Unreadable terminal output. Extract again with a redirection. The command deliberately writes resource bytes to standard output, including binary data.
• Permission denied. Fix the input or destination permissions within your own account first. Elevation may read more data than intended and does not correct a wrong resource path.

Done means

• Identified the exact gresource binary and package version.
• Listed the bundle and copied a valid resource path with its leading slash.
• Used details to confirm the resource metadata.
• Extracted to a deliberately chosen destination and checked its byte count.
• Know whether the installed build can inspect ELF sections.