Inspect and Extract GLib Resources with gresource

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 without guessing what the file contains. 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 needs elevated privileges. The commands 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.

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 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.

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. Replace the value with 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 that the bundle exposes. The optional path argument filters the result by a matching resource path, which is useful 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

The output is metadata, not the file contents. The size is useful for a quick 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 the point where a common distraction becomes a real error: the resource may be binary, so do not let it spill into your terminal.

Warning: a normal shell redirection replaces an existing destination before the command runs. Choose a new path first, or enable the shell's no-clobber option.

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. To undo this example, remove the temporary file when you have finished inspecting it:

rm -- /tmp/de.data

This removes only the extracted copy in /tmp; it does not modify the resource bundle. Do not use 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. This is a capability limitation, not evidence that the application has no resources.

7. Diagnose the usual failures

• "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 account first. Elevation may read more data than intended and does not correct a wrong resource path.

Done means

• You identified the exact gresource binary and package version.
• You listed the bundle and copied a valid resource path with its leading slash.
• You used details to confirm the resource metadata.
• You extracted to a deliberately chosen destination and checked its byte count.
• You know whether the installed build can inspect ELF sections.