xdg-utils issueshttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues2019-02-16T13:40:56Zhttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/142xdg-open open_generic_xdg_x_scheme_handler has unquoted `[ -n $scheme ]` test2019-02-16T13:40:56ZBugzilla Migration Userxdg-open open_generic_xdg_x_scheme_handler has unquoted `[ -n $scheme ]` test## Submitted by Dominic Evans
Assigned to **Portland Bugs**
**[Link to original bug (#109437)](https://bugs.freedesktop.org/show_bug.cgi?id=109437)**
## Description
xgd-open v1.1.3
A -n test doesn't work with unquoted arguments. ...## Submitted by Dominic Evans
Assigned to **Portland Bugs**
**[Link to original bug (#109437)](https://bugs.freedesktop.org/show_bug.cgi?id=109437)**
## Description
xgd-open v1.1.3
A -n test doesn't work with unquoted arguments. The `$scheme` must be double-quoted:
open_generic_xdg_x_scheme_handler()
{
scheme="`echo $1 | sed -n 's/\(^[[:alnum:]+\.-]*\):.*$/\1/p'`"
if [ -n $scheme ]; then
filetype="x-scheme-handler/$scheme"
open_generic_xdg_mime "$1" "$filetype"
fi
}
I'd suggest `if [ -n "${scheme:-}" ]; then`
Ref: https://github.com/koalaman/shellcheck/wiki/SC2070
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/139xdg-screensaver: Support xss-lock2023-10-01T21:14:40ZBugzilla Migration Userxdg-screensaver: Support xss-lock## Submitted by tpi..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#108865)](https://bugs.freedesktop.org/show_bug.cgi?id=108865)**
## Description
Created attachment 142613
Patch to support xss-lock in xdg-scree...## Submitted by tpi..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#108865)](https://bugs.freedesktop.org/show_bug.cgi?id=108865)**
## Description
Created attachment 142613
Patch to support xss-lock in xdg-screensaver.
The attached patch adds support for xss-lock to xdg-screensaver.
xss-lock runs a user specified locker in response to X server screen saver events (also some systemd events).
xss-lock would otherwise work fine with the 'screensaver_xserver' code in current xdg-screensaver, but there is no support for the 'lock' subcommand in screensaver_xserver, so some power managers (at least xfce4-power-manager) fail to lock the screen when suspending. Also, the desktop environment detection code could cause xdg-screensaver to use a code path for some other screen saver than screensaver_xserver, while xss-lock is running.
This patch detects a running xss-lock program and runs the appropriate actions, that is, it runs screensaver_xserver and replaces the 'lock' subcommand with 'activate'.
**Patch 142613**, "Patch to support xss-lock in xdg-screensaver.":
[xdg-screensaver.patch](/uploads/1e124f41acde5a50ca78890aba3dcc56/xdg-screensaver.patch)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/138recognize rxvt-unicode2019-02-16T13:40:42ZBugzilla Migration Userrecognize rxvt-unicode## Submitted by Egon
Assigned to **Portland Bugs**
**[Link to original bug (#108746)](https://bugs.freedesktop.org/show_bug.cgi?id=108746)**
## Description
In /usr/bin/xdg-terminal, in the function`terminal_generic()`, there is th...## Submitted by Egon
Assigned to **Portland Bugs**
**[Link to original bug (#108746)](https://bugs.freedesktop.org/show_bug.cgi?id=108746)**
## Description
In /usr/bin/xdg-terminal, in the function`terminal_generic()`, there is the command
```
terminal_exec=`which $TERM 2>/dev/null`
```
However, for example when `$TERM = rxvt-unicode`, this does not start rxvt-unicode as its executable bears a different name, namely `urxvt`
In fact, there is just below this line a check
```
elif [ x"$TERM" = x"urxvt" ] || [ x"$TERM" = x"rxvt-unicode" ] || [ x"$TERM" = x"rxvt" ]; then
```
for `rxvt-unicode`.
Still, the executable is set to `rxvt-unicode`, the value of `$TERM` instead of `urxvt`.
How about setting the executable instead to `urxvt` ?https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/135unused variables2023-08-09T08:41:40ZBugzilla Migration Userunused variables## Submitted by Alexander Larsson `@alexl`
Assigned to **Portland Bugs**
**[Link to original bug (#107996)](https://bugs.freedesktop.org/show_bug.cgi?id=107996)**
## Description
The shell scripts have some unused variables (which ...## Submitted by Alexander Larsson `@alexl`
Assigned to **Portland Bugs**
**[Link to original bug (#107996)](https://bugs.freedesktop.org/show_bug.cgi?id=107996)**
## Description
The shell scripts have some unused variables (which i got covertify warnings for):
xdg-utils/scripts/xdg-desktop-icon.in
$filetype is never read
scripts/xdg-open.in
$browser_with_arg is never set or readhttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/127autotests/t-xdg-open-url.sh needs an update for argument injection in xdg-ope...2023-08-09T08:47:56ZBugzilla Migration Userautotests/t-xdg-open-url.sh needs an update for argument injection in xdg-open fix## Submitted by Emilio Pozuelo Monfort
Assigned to **Portland Bugs**
**[Link to original bug (#106565)](https://bugs.freedesktop.org/show_bug.cgi?id=106565)**
## Description
From https://bugs.freedesktop.org/show_bug.cgi?id=103807...## Submitted by Emilio Pozuelo Monfort
Assigned to **Portland Bugs**
**[Link to original bug (#106565)](https://bugs.freedesktop.org/show_bug.cgi?id=106565)**
## Description
From https://bugs.freedesktop.org/show_bug.cgi?id=103807#c5
The autotests/t-xdg-open-url.sh autotest which was introduced with the ttps://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=094b73658a4fb11a40924d8df72165b054aac330 commit ('check that $BROWSER with %s is safe from shell injection') will need an adjustment after the https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=ce802d71c3466d1dbb24f2fe9b6db82a1f899bcb commithttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/124xdg-open not setting default handler for x-scheme-handler/magnet2019-02-16T13:39:55ZBugzilla Migration Userxdg-open not setting default handler for x-scheme-handler/magnet## Submitted by boo..@..it.com
Assigned to **Portland Bugs**
**[Link to original bug (#105836)](https://bugs.freedesktop.org/show_bug.cgi?id=105836)**
## Description
I'm on Arch Linux with xdg-utils 1.1.2.
Expected behaviour:
O...## Submitted by boo..@..it.com
Assigned to **Portland Bugs**
**[Link to original bug (#105836)](https://bugs.freedesktop.org/show_bug.cgi?id=105836)**
## Description
I'm on Arch Linux with xdg-utils 1.1.2.
Expected behaviour:
Opening a magnet link with xdg-open will open that link in the default bittorrent application.
Actual behaviour:
Opening a magnet link with xdg-open opens the link with the browser. Probably not the same as [bug 96472](https://bugs.freedesktop.org/show_bug.cgi?id=96472), in my case $BROWSER variable is not set and xdg-mime query comes back empty.
Steps to reproduce:
1. Set the default handler for magnet links: xdg-mime default rtm.desktop x-scheme-handler/magnet
1a. Check if 1 was set succesfully:
$ cat ~/.config/mimeapps.list
[Default Applications]
x-scheme-handler/magnet=rtm.desktop
1b. Make sure that $BROWSER is not set:
$ echo $BROWSER
2. xdg-mime query is coming back up empty:
$ xdg-mime query default x-scheme-handler/magnet
3. Run `xdg-open magnet:?xt=foo`.
4. The magnet link will be opened by the browser instead of the default application for magnet links.
Various blog posts suggested that the issue *might* be due to the xdg-open not recognising DE properly - sadly, my shell-fu is not up to the task to asses it. For what it's worth, I'm using a tiling wm instead of full-blown DE.
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/123xdg-desktop-menu uninstall /nonexistent/*.directory /nonexistent/*.desktop re...2023-08-09T09:00:03ZBugzilla Migration Userxdg-desktop-menu uninstall /nonexistent/*.directory /nonexistent/*.desktop removes unrelated files## Submitted by mar..@..edu.pl
Assigned to **Portland Bugs**
**[Link to original bug (#105635)](https://bugs.freedesktop.org/show_bug.cgi?id=105635)**
## Description
Providing arguments to xdg-desktop-menu with wildcards (not expa...## Submitted by mar..@..edu.pl
Assigned to **Portland Bugs**
**[Link to original bug (#105635)](https://bugs.freedesktop.org/show_bug.cgi?id=105635)**
## Description
Providing arguments to xdg-desktop-menu with wildcards (not expanded by shell - either because of quoting, or missing files) expand them internally, but ignoring directory part of the argument. This results in operation on unrelated files.
The most extreme case is: xdg-desktop-menu uninstall /nonexistent/*.directory /nonexistent/*.desktop
This results in removing all files from /usr/share/desktop-directories and /usr/share/applications.
While this behavior could be expected (if documented!) for just "*.desktop" argument, certainly it isn't when there was a full path provided.
Looks like missing quoting here:
uninstall)
for x in $xdg_dir $kde_dir $gnome_dir ; do
rm -f $x/$basefile # <- here
done
(this fragment appears twice in the script - once for directory files and once for desktop files)
Version: xdg-utils 1.1.1 (Fedora 26).
BTW I recommend running shellcheck on this (and other) script, it detects problems like this:
In /usr/bin/xdg-desktop-menu line 1411:
rm -f $x/$basefile
^-- SC2086: Double quote to prevent globbing and word splitting.
^-- SC2086: Double quote to prevent globbing and word splitting.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/121Open a URL in a specific browser profile2023-08-09T09:03:00ZBugzilla Migration UserOpen a URL in a specific browser profile## Submitted by Kai Hendry
Assigned to **Portland Bugs**
**[Link to original bug (#104721)](https://bugs.freedesktop.org/show_bug.cgi?id=104721)**
## Description
We use browsers commonly with profiles. However xdg-open seems to op...## Submitted by Kai Hendry
Assigned to **Portland Bugs**
**[Link to original bug (#104721)](https://bugs.freedesktop.org/show_bug.cgi?id=104721)**
## Description
We use browsers commonly with profiles. However xdg-open seems to open URLs from my terminals randomly in any of these active profiles. Is there some design or work going into to be more specific which profile to open a URL in?https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/120xdg-screensaver: bad xautolock invocation for reset action2023-08-09T09:04:25ZBugzilla Migration Userxdg-screensaver: bad xautolock invocation for reset action## Submitted by François Charlier
Assigned to **Portland Bugs**
**[Link to original bug (#104349)](https://bugs.freedesktop.org/show_bug.cgi?id=104349)**
## Description
xdg-screensaver invokes a xautolock with a wrong parameter fo...## Submitted by François Charlier
Assigned to **Portland Bugs**
**[Link to original bug (#104349)](https://bugs.freedesktop.org/show_bug.cgi?id=104349)**
## Description
xdg-screensaver invokes a xautolock with a wrong parameter for the reset action.
Currently it executes: "xautolock -restart"
To do what the manpage says, it should instead execute: "xautolock -unlocknow"
Calling with '-restart' causes some issues where xautolock will not work correctly after the call.
- From xdg-screensaver manpage:
reset Turns the screensaver off immediately. If the screen was locked the user may be asked to authenticate first.
- From xautolock manpage:
-restart Causes an already running xautolock process (if there is one and it does not have -secure switched on) to restart.
-unlocknow Causes an already running xautolock process (if there is one, if it does not have -secure switched on, and is not currently disabled) to unlock the display immediately (if it's locked) by sending the locker a SIGTERM signal.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/117xdg-desktop-menu does not treat folders with spaces correctly2023-08-09T09:17:48ZBugzilla Migration Userxdg-desktop-menu does not treat folders with spaces correctly## Submitted by Antti Savolainen
Assigned to **Portland Bugs**
**[Link to original bug (#103363)](https://bugs.freedesktop.org/show_bug.cgi?id=103363)**
## Description
Created attachment 134927
contents of ~./.config/menus
When e...## Submitted by Antti Savolainen
Assigned to **Portland Bugs**
**[Link to original bug (#103363)](https://bugs.freedesktop.org/show_bug.cgi?id=103363)**
## Description
Created attachment 134927
contents of ~./.config/menus
When editing wine program locations with menulibre the result often just breaks down with folders disappearing completely or some other weird glitch happening.
For example: If files in application-merged are removed so that they can be recreated, the files reappear after you move the .desktop files back to their folders with menulibre. If the folders contain spaces, it considers all spaces to be a separator for a sub-folder which can cause glitching (seen here https://i.imgur.com/JKOh4fF.png). Example file /menus/applications-merged/user-wine-wine-wine-Programs-League-of-Legends.menu in attachments
Steps to produce:
Install a program with spaces with wine
Delete the .menu file from applications-merged
Open menulibre and move the .desktop back to where it was
What happens
applications-merged should now contain a bugged file
I'm not sure how the folders disappearing works when you move the files around with menulibre without deleting anything from applications-merged.
**Attachment 134927**, "contents of ~./.config/menus":
[menus.tar](/uploads/783ff79f0c79e0d22ab8d5e06d1619fa/menus.tar)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/116xdg-desktop-menu adds entries to defaults.list2023-08-10T01:24:46ZBugzilla Migration Userxdg-desktop-menu adds entries to defaults.list## Submitted by Dmitry Mikhirev
Assigned to **Portland Bugs**
**[Link to original bug (#103125)](https://bugs.freedesktop.org/show_bug.cgi?id=103125)**
## Description
The xdg-desktop-menu script, when installing a menu entry, sets...## Submitted by Dmitry Mikhirev
Assigned to **Portland Bugs**
**[Link to original bug (#103125)](https://bugs.freedesktop.org/show_bug.cgi?id=103125)**
## Description
The xdg-desktop-menu script, when installing a menu entry, sets the application as default handler for MIME types that are listed in its desktop file. This behavior was introduced in commit 1f7f2ea7 with the following message:
> Make application the default handler for a mimetype if it is the only
> handler for that mimetype so far.
In fact, this is incorrect. xdg-desktop-menu does not check if there are other handlers or not, it only checks that there's no *default* handler already set. Even if it performed such a check, it would be strange to set the only possible handler as default explicitly.
I consider such a behavior is a misfeature. Is is not documented anywhere, and it is unexpected that the tool, the only purpose of which is to add a menu item, adds some MIME types associations. Furthermore, it is impossible to disable this (e.g via a command line option), and, as already reported in #71825, such an association is not removed when removing the corresponding menu entry or even when the application itself is being removed.
Please consider reverting commit 1f7f2ea7 and disabling such a strange behavior.
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/115[patch]Add support for trinity in xdg-utils2019-08-29T00:37:29ZBugzilla Migration User[patch]Add support for trinity in xdg-utils## Submitted by wof..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#102395)](https://bugs.freedesktop.org/show_bug.cgi?id=102395)**
## Description
Like the title sais.
trinity is KDE3 that is still been maintain...## Submitted by wof..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#102395)](https://bugs.freedesktop.org/show_bug.cgi?id=102395)**
## Description
Like the title sais.
trinity is KDE3 that is still been maintained.
It's like MATE.
The code is alredy in there, it's the code for KDE3.
Simply changing line 384 from "KDE)" to "KDE|Trinity)"
and in function "kfmclient_fix_exit_code()"
add
"if [ "$XDG_CURRENT_DESKTOP" = KDE ]; then fi"
around the block of code, excluding the "return 0"
and it's done.
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/114xdg-screensaver script does not follow freedesktop spec2023-08-09T09:22:46ZBugzilla Migration Userxdg-screensaver script does not follow freedesktop spec## Submitted by Kishore Gopalakrishnan
Assigned to **Portland Bugs**
**[Link to original bug (#102124)](https://bugs.freedesktop.org/show_bug.cgi?id=102124)**
## Description
Downstream bug report: https://bugs.kde.org/show_bug.cgi...## Submitted by Kishore Gopalakrishnan
Assigned to **Portland Bugs**
**[Link to original bug (#102124)](https://bugs.freedesktop.org/show_bug.cgi?id=102124)**
## Description
Downstream bug report: https://bugs.kde.org/show_bug.cgi?id=381160#c4
(From comment 4 of above report)
"xdg-screensaver is a script that does different things for each desktop.
The one that tries to use the standard fd.o interface is just completely wrong.
From the spec:
"Inhibition will stop when the UnInhibit function is called, or the application disconnects from the D-Bus session bus (which usually happens upon exit)."
https://people.freedesktop.org/~hadess/idle-inhibition-spec/ch03.html
dbus-send (called from the xdg-screensaver script) exits immediately after sending
We follow the fd.o spec so correctly remove the inhibition.
xdg-screensaver needs fixing, not plasma."
I am using version 1.1.2, but I could not fill that in the version field, as the option was missing.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/112Autotest results on Linux Mint 18.12023-08-09T09:24:00ZBugzilla Migration UserAutotest results on Linux Mint 18.1## Submitted by cyn..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#101640)](https://bugs.freedesktop.org/show_bug.cgi?id=101640)**
## Description
Created attachment 132332
test results
...
**Attachment 1323...## Submitted by cyn..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#101640)](https://bugs.freedesktop.org/show_bug.cgi?id=101640)**
## Description
Created attachment 132332
test results
...
**Attachment 132332**, "test results":
[results.txt](/uploads/5a2de67ac392e882cb3c0e8f5f89c35d/results.txt)
### Depends on
* [Bug 96472](https://bugs.freedesktop.org/show_bug.cgi?id=96472)
* [Bug 44163](https://bugs.freedesktop.org/show_bug.cgi?id=44163)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/108Add "google-chrome-unstable" and "google-chrome-beta" to fallback browsers2019-03-27T06:32:55ZBugzilla Migration UserAdd "google-chrome-unstable" and "google-chrome-beta" to fallback browsers## Submitted by Davide Palma
Assigned to **Portland Bugs**
**[Link to original bug (#101040)](https://bugs.freedesktop.org/show_bug.cgi?id=101040)**
## Description
Created attachment 131353
patch
Same as [bug 99366](https://bugs....## Submitted by Davide Palma
Assigned to **Portland Bugs**
**[Link to original bug (#101040)](https://bugs.freedesktop.org/show_bug.cgi?id=101040)**
## Description
Created attachment 131353
patch
Same as [bug 99366](https://bugs.freedesktop.org/show_bug.cgi?id=99366), but instead of "chromium", "google-chrome-unstable" and "google-chrome-beta" should be added.
On my updated Gentoo GNU/Linux system, xdg-open doesn't find google-chrome-unstable nor google-chrome-beta when trying to open a PDF file in fallback and goes on with the list. google-chrome-unstable is the binary name for the unstable (also referred as "development") version of Google Chrome, while google-chrome-beta is the beta version of the browser.
The attached patch adds the browsers to the list.
**Patch 131353**, "patch":
[patch](/uploads/aafde1c8cb8e3e8bc152cdc98dab63f2/patch)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/107xdg-mime does not handle whitespace in .desktop file names correctly2023-10-01T12:39:18ZBugzilla Migration Userxdg-mime does not handle whitespace in .desktop file names correctly## Submitted by Vladimir Panteleev
Assigned to **Portland Bugs**
**[Link to original bug (#101039)](https://bugs.freedesktop.org/show_bug.cgi?id=101039)**
## Description
On my system, running:
$ xdg-open http://google.com
Prints...## Submitted by Vladimir Panteleev
Assigned to **Portland Bugs**
**[Link to original bug (#101039)](https://bugs.freedesktop.org/show_bug.cgi?id=101039)**
## Description
On my system, running:
$ xdg-open http://google.com
Prints this to stderr:
/usr/sbin/xdg-mime: line 323: [: too many arguments
/usr/sbin/xdg-mime: line 325: [: too many arguments
xdg-mime at line 323 looks like this:
if [ -r $dir/applications/$vendor/$app ]; then
file_path=$dir/applications/$vendor/$app
elif [ -r $dir/applnk/$vendor/$app ]; then
file_path=$dir/applnk/$vendor/$app
fi
It looks like xdg-mime does not properly quote variables before expansion, which makes them subject to globbing and word splitting.
The particular file that causes xdg-mime to misbehave is:
/home/vladimir/.local/share/applications/userapp-Firefox Developer Edition-ZN8AEY.desktop
I'm not sure what created it, but it does have spaces in the file name.
Regardless of whether spaces are allowed in such file names, not quoting variables that are not intended to be expanded is a bug.
I strongly recommend linting shell scripts with ShellCheck (http://www.shellcheck.net/) to prevent bugs like this one.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/106xdg-email: Must not url-encode subject for Thunderbird2019-03-27T06:39:22ZBugzilla Migration Userxdg-email: Must not url-encode subject for Thunderbird## Submitted by h.g..@..ult.de
Assigned to **Portland Bugs**
**[Link to original bug (#100216)](https://bugs.freedesktop.org/show_bug.cgi?id=100216)**
## Description
Created attachment 130232
Scrrenshot of Thunderbird subject when...## Submitted by h.g..@..ult.de
Assigned to **Portland Bugs**
**[Link to original bug (#100216)](https://bugs.freedesktop.org/show_bug.cgi?id=100216)**
## Description
Created attachment 130232
Scrrenshot of Thunderbird subject when running xdg-email --utf8 --subject "Hällö"
Creating a mail with Thunderbird using
xdg-email --subject "Hällö"
or
xdg-email --utf8 --subject "Hällö"
gives a subject of
H%E4ll%F6
(see attached picture).
I would expect the Subject to be "Hällö".
Environment:
- Thunderbird 38.3.0
- de_DE.UTF-8 (any other UTF-8 locale should do)
**Attachment 130232**, "Scrrenshot of Thunderbird subject when running xdg-email --utf8 --subject "Hällö"":
![xdg-email-thunderbird](/uploads/4dd3de7c51a533b127bafd5e865a5fa9/xdg-email-thunderbird.png)
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/104xdg-open does not handle multiple applications returned from xdg-mime2023-08-09T09:32:30ZBugzilla Migration Userxdg-open does not handle multiple applications returned from xdg-mime## Submitted by Kjetil Torgrim Homme
Assigned to **Portland Bugs**
**[Link to original bug (#99538)](https://bugs.freedesktop.org/show_bug.cgi?id=99538)**
## Description
Created attachment 129146
possible default applications are ...## Submitted by Kjetil Torgrim Homme
Assigned to **Portland Bugs**
**[Link to original bug (#99538)](https://bugs.freedesktop.org/show_bug.cgi?id=99538)**
## Description
Created attachment 129146
possible default applications are separated by semicolons
on my Fedora 24 system, xdg-mime will return a semicolon separated list (from /usr/share//applications/mimeapps.list). xdg-open will use the whole string verbatim as the name of the desktop file, and it fails.
Example:
$ /bin/xdg-mime query default image/jpeg
eog.desktop;
$ /bin/xdg-mime query default image/svg+xml
eog.desktop;gthumb.desktop;
notice the trailing semicolon.
it seems to me xdg-open should split on ";" and look for each application in turn. I have a patch to do so at
https://github.com/kjetilho/xdg-utils/tree/open-fix
the patch is enclosed. it also fixes a trivial but critical typo in xdg-open.
**Patch 129146**, "possible default applications are separated by semicolons":
[open-fix.patch](/uploads/4622bb5eb57c8c901f8161f76a4c548f/open-fix.patch)
Version: TPhttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/102xdg-utils detectDE() fails to handle XDG_CURRENT_DESKTOP properly2019-02-16T13:38:16ZBugzilla Migration Userxdg-utils detectDE() fails to handle XDG_CURRENT_DESKTOP properly## Submitted by Michael Catanzaro
Assigned to **Rex Dieter**
**[Link to original bug (#98680)](https://bugs.freedesktop.org/show_bug.cgi?id=98680)**
## Description
$XDG_CURRENT_DESKTOP is a list, not a single value. It could be, f...## Submitted by Michael Catanzaro
Assigned to **Rex Dieter**
**[Link to original bug (#98680)](https://bugs.freedesktop.org/show_bug.cgi?id=98680)**
## Description
$XDG_CURRENT_DESKTOP is a list, not a single value. It could be, for instance, Endless:GNOME or Unity:GNOME, something like that. In cases like these, detectDE() in xdg-utils-common.in fails to parse $XDG_CURRENT_DESKTOP properly, since it's only expecting one single value.
This is not really a serious issue now because detectDE() has a fallback to check $GNOME_DESKTOP_SESSION_ID, but that variable is always set to this-is-deprecated nowadays and could conceivably disappear in the future. That could break desktop detection in desktops that want to be treated as GNOME by xdg-utils. It'd probably be a good idea to use a glob to see if GNOME (or any other desktop) appears anywhere in the list in the case statement at the start of detectDE() to avoid this.
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/101xdg-open does not support queries in file: URLs2019-02-16T13:38:12ZBugzilla Migration Userxdg-open does not support queries in file: URLs## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98648)](https://bugs.freedesktop.org/show_bug.cgi?id=98648)**
## Description
This is not really xdg-open's fault. For example, I believe it work...## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98648)](https://bugs.freedesktop.org/show_bug.cgi?id=98648)**
## Description
This is not really xdg-open's fault. For example, I believe it works in KDE (as per bug #7863); but it doesn't work in GNOME, because gvfs-open doesn't support it.
xdg-open should (as usual) paper over the cracks here, by detecting queries (and anchors) in file: URLs, and improving open_generic to open them with a browser. This can be achieved by improving is_file_url_or_path to be, as it were, is_plain_file_url_or_path.
This bug prevents xdg-open being used in some places, e.g. as Racket's launcher (www.racket-lang.org).