Skip to content

exo-open can't handle certain UTF strings

I'm seeing a really weird bug with exo-open 4.18.0. I have a custom handler defining the xclip://... protocol:

[Desktop Entry]
Name=Copy to clipboard
Exec=xclip-handler %u
Icon=xfce4-clipman-plugin
Type=Application
Terminal=false
MimeType=x-scheme-handler/xclip;

and the corresponding xclip-handler Python script which invokes xclip with the data from the URL, so that exo-open xclip://foobar will result in foobar being placed in the clipboard.

For the most part this works great, and it also works for encoded URLs such as xclip://foo%20bar.

However, when the URL contains non-ASCII UTF characters, either encoded or raw, things get weird and sometimes fail with the error Unable to detect the URI-scheme of "xclip://...":

$ exo-open 'xclip://it’s'         # U+2019 with no encoding; works
$ exo-open 'xclip://it’s '        # U+2019 with no encoding and space; broken
$ exo-open 'xclip://it’s+fine'    # U+2019 with space encoded as plus; works
$ exo-open 'xclip://it’s%20fine'  # U+2019 with space encoded as %20; broken

Finally, the length of the URL can also somehow play a factor! This URL of 64 bytes works:

$ exo-open 'xclip://xxxxxxxxxxxxx’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

but anything longer including this non-ASCII character breaks, again with the Unable to detect ... error:

$ exo-open 'xclip://xxxxxxxxxxxxx’xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

and removing the non-ASCII character allows longer URLs to work fine:

$ exo-open 'xclip://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

In contrast, gio open handles all of these flawlessly.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information