xdg-utils issueshttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues2023-10-14T15:36:05Zhttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/1Unquoted directory in desktop_file_to_binary of xdg-mime creates errors when ...2023-10-14T15:36:05ZBugzilla Migration UserUnquoted directory in desktop_file_to_binary of xdg-mime creates errors when filename contains forbidden characters## Submitted by Dillen Meijboom
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#104849)](https://bugs.freedesktop.org/show_bug.cgi?id=104849)**
## Description
In the `desktop_file_to_binary` function ...## Submitted by Dillen Meijboom
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#104849)](https://bugs.freedesktop.org/show_bug.cgi?id=104849)**
## Description
In the `desktop_file_to_binary` function of xdg-mime (version 1.1.2) line 323/325 there is an if statement in bash which checks if a directory exists (at least I think so). It uses an unquoted path which in my case contains forbidden characters in bash. Quoting this path fixes the issue.
Original source (line 323):
```
if [ -r $dir/applications/$vendor/$app ]; then
```
Fixed source (line 323):
```
if [ -r "$dir/applications/$vendor/$app" ]; then
```https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/2Add "xdg-mime query fileencoding"2018-10-14T13:34:33ZBugzilla Migration UserAdd "xdg-mime query fileencoding"## Submitted by Reuben Thomas
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#47359)](https://bugs.freedesktop.org/show_bug.cgi?id=47359)**
## Description
/usr/bin/file can guess the encoding of a fil...## Submitted by Reuben Thomas
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#47359)](https://bugs.freedesktop.org/show_bug.cgi?id=47359)**
## Description
/usr/bin/file can guess the encoding of a file. I haven't looked, but perhaps some of the other detectors used by xdg-mime can too?
Supporting this command via /usr/bin/file is as simple as passing --mime-encoding rather than --mime-type to file. Then one could use
xdg-mime query fileencoding foo.bar
to try to get the encoding of a file.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/4can't install a mime definition xml with a space in its path.2018-10-14T13:34:15ZBugzilla Migration Usercan't install a mime definition xml with a space in its path.## Submitted by John Goering
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#28579)](https://bugs.freedesktop.org/show_bug.cgi?id=28579)**
## Description
When the XML describing the mimetype is in a f...## Submitted by John Goering
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#28579)](https://bugs.freedesktop.org/show_bug.cgi?id=28579)**
## Description
When the XML describing the mimetype is in a folder which contains a space, xdg-mime does not install it. Otherwise the file works fine.
I tried it in two different ways:
> xdg-mime install "/home/dev/my folder/my-mfe.xml"
and
> xdg-mime install /home/dev/my\ folder/my-mfe.xml
Note that using the same XML file just in a different location, the following worked:
> xdg-mime install /home/dev/myfolderwithoutaspace/my-mfe.xml
Just for completeness' sake, here is my XML:
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="application/myfiletype.archive">
`<comment>`my type`</comment>`
<glob pattern="*.mfe"/>
`</mime-type>`
`</mime-info>`https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/5xdg-open ignores static arguments in .desktop files2023-08-10T01:23:07ZBugzilla Migration Userxdg-open ignores static arguments in .desktop files## Submitted by sam..@..il.com
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#80714)](https://bugs.freedesktop.org/show_bug.cgi?id=80714)**
## Description
Observed on Ubuntu with xdg-open 1.0.2
I cr...## Submitted by sam..@..il.com
Assigned to **Jonathan Blandford Blandford `@jrb`**
**[Link to original bug (#80714)](https://bugs.freedesktop.org/show_bug.cgi?id=80714)**
## Description
Observed on Ubuntu with xdg-open 1.0.2
I created a custom .desktop, placing it in ~/.local/share/applications and associated it to a few filetypes that I'm interested in.
For the sake of simplicity lets say the custom launcher is just supposed to echo the name of the file it is handed, adding a fixed parameter:
Exec: echo BOO
When I attempt to open my custom file (which is resolving the desktop correctly):
xdg-open myfile.fommil
# EXPECTED
BOO myfile.fommil
# OBSERVED
myfile.fommil
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables says that Exec takes arguments that are space separated.
# WORKAROUND
One must create a script that takes no parameters and adds all the extra fixed parameters (e.g. a script that calls 'echo BOO $*')https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/9README does not mention xdg-settings2023-08-09T08:37:13ZClarence "Sparr" RisherREADME does not mention xdg-settings"The following tools are included in xdg-utils 1.0:" in the README includes almost every script in the repo. A notable omission is xdg-settings."The following tools are included in xdg-utils 1.0:" in the README includes almost every script in the repo. A notable omission is xdg-settings.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/11xdg-settings attempts to call kde5-config instead of kf5-config2019-03-27T06:45:31ZClarence "Sparr" Risherxdg-settings attempts to call kde5-config instead of kf5-confighttps://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-settings.in#L161
when KDE_SESSION_VERSION is 5 the relevant script is called `kf5-config` not `kde5-config`, from what I've been able to gather. I can confirm that `kf...https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-settings.in#L161
when KDE_SESSION_VERSION is 5 the relevant script is called `kf5-config` not `kde5-config`, from what I've been able to gather. I can confirm that `kf5-config --path config` produces a `:`-delimited list of paths that contain kde config files including the `kdeglobals` file that I see this function trying to access in my current workflow.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/16xdg-icon, SVG not supported everywhere2019-02-16T13:28:18ZBugzilla Migration Userxdg-icon, SVG not supported everywhere## Submitted by Waldo Bastian
Assigned to **Portland Bugs**
**[Link to original bug (#7837)](https://bugs.freedesktop.org/show_bug.cgi?id=7837)**
## Description
needs investingation, needs test coverage
Version: beta2## Submitted by Waldo Bastian
Assigned to **Portland Bugs**
**[Link to original bug (#7837)](https://bugs.freedesktop.org/show_bug.cgi?id=7837)**
## Description
needs investingation, needs test coverage
Version: beta2https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/17xdg-mime doesn't check defaults.list correctly2019-02-16T13:28:23ZBugzilla Migration Userxdg-mime doesn't check defaults.list correctly## Submitted by Frederic Crozat Crozat `@fcrozat`
Assigned to **Portland Bugs**
**[Link to original bug (#10042)](https://bugs.freedesktop.org/show_bug.cgi?id=10042)**
## Description
version 1.0.1 of xdg-mime doesn't check default...## Submitted by Frederic Crozat Crozat `@fcrozat`
Assigned to **Portland Bugs**
**[Link to original bug (#10042)](https://bugs.freedesktop.org/show_bug.cgi?id=10042)**
## Description
version 1.0.1 of xdg-mime doesn't check defaults.list correctly :
it searchs for the first .desktop keyfile for a particular mimetype, without checking if this .desktop is available on the system.
The attached patch fixes this issue.
It isn't perfect, since xdg-mime doesn't checks if .desktop if valid (ie if Exec= is pointing to a existing executable file) or if it can be used (ie not in Hidden=true) but it is better.
Version: 1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/18duplicate menu entries in gnome2019-02-16T13:28:27ZBugzilla Migration Userduplicate menu entries in gnome## Submitted by Lei Zhang `@leiz`
Assigned to **Fathi Boudra**
**[Link to original bug (#11748)](https://bugs.freedesktop.org/show_bug.cgi?id=11748)**
## Description
I'm trying to use xdg-desktop-menu to add menu items to a direct...## Submitted by Lei Zhang `@leiz`
Assigned to **Fathi Boudra**
**[Link to original bug (#11748)](https://bugs.freedesktop.org/show_bug.cgi?id=11748)**
## Description
I'm trying to use xdg-desktop-menu to add menu items to a directory under one of the top level menus.
I ran the command:
xdg-desktop-menu install --novendor --mode system /usr/share/desktop-directories/Games.directory bar.directory bar.desktop
On this system, some third party software package created /usr/share/gnome/apps, so xdg-desktop-menu put a bar.desktop file there, with "OnlyShowIn=Old;" Gnome seems to ignore this, and thus we get a second menu entry.
(see screenshot: http://linux.ucla.edu/~leiz/freedesktop/duplicate_menu.png)
My proposed solution is to ignore /usr/share/gnome/apps if we detect a version of Gnome that knows about .desktop files in $XDG_DATA_DIRS/applications/. I'm guessing Gnome 2.8 and up, but I could be wrong.
Version: 1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/19Documentation should tell something about calling order of scripts2023-10-09T00:52:02ZBugzilla Migration UserDocumentation should tell something about calling order of scripts## Submitted by Yann Droneaud
Assigned to **Portland Bugs**
**[Link to original bug (#13097)](https://bugs.freedesktop.org/show_bug.cgi?id=13097)**
## Description
xdg scripts manual are not clear enough on the calling order of
xd...## Submitted by Yann Droneaud
Assigned to **Portland Bugs**
**[Link to original bug (#13097)](https://bugs.freedesktop.org/show_bug.cgi?id=13097)**
## Description
xdg scripts manual are not clear enough on the calling order of
xdg-icon-resource, xdg-mime, xdg-desktop-icon/xdg-desktop-menu
In case of an installation:
- Should I call xdg-icon-resource before calling xdg-mime
- Should I register a MIME type with xdg-mime before adding an application to handle it with xdg-desktop-menu/xdg-desktop-icon.
And in case of an uninstallation, is it necessary to use a reverse order ?
There is no explicit information about this.
Those questions must be answered in the XDG scripts manual.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/21xdg-screensaver expects xprop to exit if the window disappears2019-02-16T13:28:48ZBugzilla Migration Userxdg-screensaver expects xprop to exit if the window disappears## Submitted by Dima Ryazanov
Assigned to **Fathi Boudra**
**[Link to original bug (#13506)](https://bugs.freedesktop.org/show_bug.cgi?id=13506)**
## Description
As far as I understand, xdg-screensaver should resume the screensave...## Submitted by Dima Ryazanov
Assigned to **Fathi Boudra**
**[Link to original bug (#13506)](https://bugs.freedesktop.org/show_bug.cgi?id=13506)**
## Description
As far as I understand, xdg-screensaver should resume the screensaver if the window used to suspend it has disappeared - but this doesn't happen. Even worse, if the window has disappeared, it's impossible to enable the screensaver using "xdg-screensaver resume".
I found these lines in the xdg-screensaver code:
# Start tracking $window_id
$XPROP -id $window_id -spy > /dev/null &
xprop_pid=$!
[...]
# Wait for xprop to edit, it means that the window disappeared
wait $xprop_pid
(I assume it's "exit", not "edit".)
But 'xprop -spy' doesn't ever exit - and nowhere in the manual does it say that it should. I even looked at the xprop source code; it has an infinite loop at the end, so it looks like it was never intended to exit.
Version: 1.0
### Depends on
* [Bug 19381](https://bugs.freedesktop.org/show_bug.cgi?id=19381)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/23xdg-utils should provide a standard way for accessing localized through xdg-u...2019-02-16T13:28:56ZBugzilla Migration Userxdg-utils should provide a standard way for accessing localized through xdg-usr-dirs user directories## Submitted by Konstantinos Togias
Assigned to **Portland Bugs**
**[Link to original bug (#14367)](https://bugs.freedesktop.org/show_bug.cgi?id=14367)**
## Description
Created attachment 14136
xdg-cd shell script for changing to ...## Submitted by Konstantinos Togias
Assigned to **Portland Bugs**
**[Link to original bug (#14367)](https://bugs.freedesktop.org/show_bug.cgi?id=14367)**
## Description
Created attachment 14136
xdg-cd shell script for changing to localized user dirs giving their original english name
As I found out using ubuntu 7.10 with Greek local user dirs (Desktop, Documents, etc) are renamed to greek equivalent names (eg. Επιφάνεια Εργασίας, Έγγραφα, etc). Although most applications can access those localized dirs through XDG_.*_DIR XDG environment variables, there is not a standard/uniform/trivial way for the user to access them through console.
The greek (or any other non-latin language) directory names may be pleasant when using the GUI but cause problems when trying to access them (eg. change to) from console, or terminal. The most trivial inconvenience is thet one has to switch the keyboard layout to greek in order to type the localized dir name and then back to latin in order to continue typing the command. Furthermore, localized dirs can be completely inaccessible when working form a console where the proper keyboard layout switching is not set up, and/or the font is not capable for displaying greek characters or the system does not use unicode. The above issues raise frequently when using plain console (no X), or accessing a localized machine remotely through ssh, telnet, ftp from an other system that is not set up for greek. It also hinders users of localized machines to get help or follow howtos in english that suggest using terminal commands that involve accessing some of the folders that are localized. (eg. the directions: "Download through firefox this_link, open a terminal and type cd Desktop && sh this_file" will fail because the DOWNLOAD directory is not named Desktop but Επιφάνεια Εργασίας at the user's system.)
For the reasons above I think that it would be useful to have a script (or make cd xdg aware???) that would allow changing to user dirs using the default english names whether those dirs are localized or not. As an example/proposition I attach a small shell script I have written that creates a command named "xdg-cd". xdg-cd functions as following:
The user can change from everywhere in the filesystem to the ~/Desktop equivalent directory with:
$ xdg-cd Desktop
For example, if xdg-dirs are set to greek the above command is equivalent to this:
$ cd ~/Επιφάνεια\ Εργασίας
but with xdg-cd you don't have to switch layout and type greek characters. You don't even care how Desktop dir is named in greek or if the system is set up to greek or Japanese or any other layout. You just type xdg-cd Desktop and you are taken to your Desktop dir. The xdg-cd command works similarly for the other user dirs (Download, Documents, Music, etc). I think that such functionality should be added to xdg-utils in order to have a standard way to access localized user dirs regardless of the language to which they are translated.
In order to try the attached script put the attached file somewhere (eg.in ~/.xdg/) and add the following line to your ~/.bashrc :
alias xdg-cd='source ~/.xdg/xdg-cd'
Then open a new terminal or log in again, and you will be able to use xdg-cd command as described above.
**Attachment 14136**, "xdg-cd shell script for changing to localized user dirs giving their original english name":
[xdg-cd](/uploads/5700443b7b8615085a7ded98058ef098/xdg-cd)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/24xdg-autostart script2019-02-16T13:28:59ZBugzilla Migration Userxdg-autostart script## Submitted by Dana Jansens
Assigned to **Portland Bugs**
**[Link to original bug (#14778)](https://bugs.freedesktop.org/show_bug.cgi?id=14778)**
## Description
Here is a script that provides autostart functionality based on the ...## Submitted by Dana Jansens
Assigned to **Portland Bugs**
**[Link to original bug (#14778)](https://bugs.freedesktop.org/show_bug.cgi?id=14778)**
## Description
Here is a script that provides autostart functionality based on the fd.org autostart specification.
It is written in python and uses the PyXDG library.
### Depends on
* [Bug 7016](https://bugs.freedesktop.org/show_bug.cgi?id=7016)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/25xdg-desktop-menu doesn't update gnome-panel on clean installs...2019-02-16T13:29:05ZBugzilla Migration Userxdg-desktop-menu doesn't update gnome-panel on clean installs...## Submitted by Ryan C. Gordon
Assigned to **Portland Bugs**
**[Link to original bug (#14846)](https://bugs.freedesktop.org/show_bug.cgi?id=14846)**
## Description
(There is no 1.0.2 selection in the version field, but this is wit...## Submitted by Ryan C. Gordon
Assigned to **Portland Bugs**
**[Link to original bug (#14846)](https://bugs.freedesktop.org/show_bug.cgi?id=14846)**
## Description
(There is no 1.0.2 selection in the version field, but this is with 1.0.2.)
This is a little vague, since I'm not sure where the specific issue is.
Sometimes you will install a desktop menu item with xdg-desktop-menu and it won't show up in the Gnome panel's Applications menu. It seems like there is some state that xdg-utils is setting up correctly, but Gnome doesn't notice.
Reproduction steps:
1) Get an install of Ubuntu 7.10 x86, patched to the latest versions.
2) Create a new user with System->Administration->Users and Groups. I named the new login "test" ...
3) Log in as "test" so you're at a new, unmolested Gnome desktop.
4) Install a menu item and icon with "xdg-desktop-menu install" into, say, the "Games" directory.
5) Click Applications->Games, notice that the new icon isn't there.
6) From the Terminal app, run "killall -HUP gnome-panel" and see the panel flicker for a moment as it restarts.
7) Click Applications->Games, notice that the new icon has finally shown up.
8) Uninstall the menu item, notice it goes away immediately.
9) Notice that the initial behaviour of the icon not appearing immediately after the install command is no longer reproducible...it shows up right away on further attempts on this user's account.
My educated guess is that gnome-panel is watching some directory with inotify to decide when to add new items to the menu, but if that directory doesn't exist when gnome-panel starts, it doesn't have the watch in place, so you won't get changes until the process restarts with the directory already in place. The install attempt from xdg-desktop-menu creates the directory.
I guess what I'm asking here: is there some way that xdg-desktop-menu can realize that the crucial element is missing, and force a -HUP on gnome-panel after install in just that case? I'm not sure exactly WHAT the crucial element is, though: ~/.gnome/apps, perhaps.
(I haven't tried this on other distros, versions of Gnome, KDE, or XFCE.)
--ryan.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/27Using xdg-open in mailcap causes serious hole in Firefox!2023-11-27T21:08:29ZBugzilla Migration UserUsing xdg-open in mailcap causes serious hole in Firefox!## Submitted by Manuel Reimer
Assigned to **Portland Bugs**
**[Link to original bug (#19377)](https://bugs.freedesktop.org/show_bug.cgi?id=19377)**
## Description
Created attachment 21642
The mailcap file, as it gets delivered wit...## Submitted by Manuel Reimer
Assigned to **Portland Bugs**
**[Link to original bug (#19377)](https://bugs.freedesktop.org/show_bug.cgi?id=19377)**
## Description
Created attachment 21642
The mailcap file, as it gets delivered with Slackware 12.2
Hello,
i've attached the /etc/mailcap, Slackware 12.2 ships, by default, below.
Firefox uses mailcap to detect the default application. With the mailcap file, used in Slackware, Firefox uses xdg-open as default application for several "secure" mime types like audio files and PDF files. As xdg-open, itself, detects the "real" mime type (or better asks the desktop manager to detect it) it's possible to execute dangerous files by delivering them with a faked mime-type.
I've created a test page to demonstrate the problem (see URL above). Steps to test:
- Create a new user for the test (to be sure we are on default settings everywhere and to be secure the demonstration program doesn't kill something ;-)).
- Log into a KDE session with this user.
- Copy the attached mailcap to $HOME/.mailcap
- Start firefox
- Visit the above URL (you have to add a security exception, as the certificate belongs to mozdev.org), click the link and just hit "OK" to accept the default, selected by firefox.
Result: You'll see a small demonstration program, nested into the .desktop file.
I don't know why the Slackware developers got the idea to use xdg-open in mailcap, but you should add a note somewhere into your documentation (maybe the README file in your source) which warns to not use xdg-open too careless, as it may also execute potentially dangerous files. You should also add a note that xdg-open should not be used in mailcap files, as this may cause security problems if applications expect trusted "viewing applications", there (example: Firefox).
**Attachment 21642**, "The mailcap file, as it gets delivered with Slackware 12.2":
[mailcap](/uploads/bee01e6722a9fd59d937381ddaa5206a/mailcap)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/28xdg-screensaver should support a hook to specify a different screensaver2019-02-16T13:35:33ZBugzilla Migration Userxdg-screensaver should support a hook to specify a different screensaver## Submitted by Brian Cameron `@bacameron`
Assigned to **Portland Bugs**
**[Link to original bug (#20042)](https://bugs.freedesktop.org/show_bug.cgi?id=20042)**
## Description
xdg-screensaver is currently hardcoded to launch parti...## Submitted by Brian Cameron `@bacameron`
Assigned to **Portland Bugs**
**[Link to original bug (#20042)](https://bugs.freedesktop.org/show_bug.cgi?id=20042)**
## Description
xdg-screensaver is currently hardcoded to launch particular screensavers for
GNOME or KDE. It should support an interface so that if a person wants to use
an alternative screensaver, they can specify it. Perhaps xdg-screensaver could
check for a file on the system, and if present, run that script to start the
screensaver rather than doing its current magic.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/29xdg-utils should contain a trash bin tool2019-02-16T13:29:28ZBugzilla Migration Userxdg-utils should contain a trash bin tool## Submitted by Tassilo Horn
Assigned to **Portland Bugs**
**[Link to original bug (#20198)](https://bugs.freedesktop.org/show_bug.cgi?id=20198)**
## Description
[Sorry for filing this in the wrong product, but there seems to be n...## Submitted by Tassilo Horn
Assigned to **Portland Bugs**
**[Link to original bug (#20198)](https://bugs.freedesktop.org/show_bug.cgi?id=20198)**
## Description
[Sorry for filing this in the wrong product, but there seems to be no xdg-utils component.]
Most of the time I'm doing my file management in the shell, where `rm' means dead and gone forever. I'd love to see a command line tool facilitating the freedesktop.org trash bin. I would imagine it to work like this:
# Move baz.txt to the trash bin
$ xdg-trash /foo/bar/baz.txt
# Move the whole bar directory to the trash bin
$ xdg-trash /baz/bar/
# List the trash bin's contents (lists the original locations)
$ xdg-trash --list
[1] /foo/bar/baz.txt
[2] /baz/bar/
# Restore the bar directory
$ xdg-trash --restore 2
# Empty the trash bin
$ xdg-trash --emptyhttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/30xdg-desktop-menu Fails Without desktop-directories Folder.2023-10-10T07:34:19ZBugzilla Migration Userxdg-desktop-menu Fails Without desktop-directories Folder.## Submitted by Pat Suwalski
Assigned to **Portland Bugs**
**[Link to original bug (#20462)](https://bugs.freedesktop.org/show_bug.cgi?id=20462)**
## Description
I am in the process of making a fairly minimalistic XFCE-based distr...## Submitted by Pat Suwalski
Assigned to **Portland Bugs**
**[Link to original bug (#20462)](https://bugs.freedesktop.org/show_bug.cgi?id=20462)**
## Description
I am in the process of making a fairly minimalistic XFCE-based distribution. We use Thunar as the file manager, and one of the packages we would like to put on the system uses xdg-desktop-menu to install its ".desktop" file.
However, the file is never placed in /usr/share/applications, because the xdg-desktop-menu script errors out:
"No writable system menu directory found."
The issue is we don't have anything that installs a /usr/share/desktop-directories directory. Creating one causes the script to run properly and install the ".desktop" file in /usr/share/applications. However, the desktop-directories directory still remains empty.
The bug is that I can't see any reason why xdg-desktop-menu should error out when /usr/share/desktop-directories does not exist. It installs the ".desktop" file in /usr/share/applications anyway.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/31xdg-utils incorrectly parses output, causing wrong output2019-02-16T13:29:35ZBugzilla Migration Userxdg-utils incorrectly parses output, causing wrong output## Submitted by jam..@..al.com
Assigned to **Fathi Boudra**
**[Link to original bug (#21018)](https://bugs.freedesktop.org/show_bug.cgi?id=21018)**
## Description
This bug was reported in the Ubuntu bug tracker as a security vulne...## Submitted by jam..@..al.com
Assigned to **Fathi Boudra**
**[Link to original bug (#21018)](https://bugs.freedesktop.org/show_bug.cgi?id=21018)**
## Description
This bug was reported in the Ubuntu bug tracker as a security vulnerability. I do not feel it is a security vulnerability because it appears xdg-mime will at worst echo back the filename rather than the mimetype. Eg, from within a gnome session:
$ touch '/tmp/foo:runme'
$ KDE_FULL_SESSION=false GNOME_DESKTOP_SESSION_ID= xdg-mime query filetype /tmp/foo\:runme
runme
This is simply because info_kde(), info_gnome() and info_generic() use cut with a delimiter that if in the filename, causes unintended output. See the Ubuntu bug for details and a suggested patch.
xdg-utils 1.0.2 (1.0.2-6.1 on Ubuntu and Debian)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/38xdg-desktop-menu documentation wrong: s/Value/Version/2019-02-16T13:30:09ZBugzilla Migration Userxdg-desktop-menu documentation wrong: s/Value/Version/## Submitted by bet..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#31369)](https://bugs.freedesktop.org/show_bug.cgi?id=31369)**
## Description
The documentation for xdg-desktop-menu says that the key "Value" i...## Submitted by bet..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#31369)](https://bugs.freedesktop.org/show_bug.cgi?id=31369)**
## Description
The documentation for xdg-desktop-menu says that the key "Value" is required for both .desktop and .directory files "to indicate that the ... file follows the 1.0 version of the specification". I've never written a .desktop file before, but it looks like the key name should be "Version". The gedit syntax highlighter recognizes "Version" and not "Value", and "Version" makes more sense.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/39Mutt cannot open attachments w. xdg-open2023-08-10T13:23:04ZBugzilla Migration UserMutt cannot open attachments w. xdg-open## Submitted by Rex Dieter
Assigned to **Portland Bugs**
**[Link to original bug (#32016)](https://bugs.freedesktop.org/show_bug.cgi?id=32016)**
## Description
I'm using Mutt as an example, but there are cases when applications cr...## Submitted by Rex Dieter
Assigned to **Portland Bugs**
**[Link to original bug (#32016)](https://bugs.freedesktop.org/show_bug.cgi?id=32016)**
## Description
I'm using Mutt as an example, but there are cases when applications create a tmpfile, and use xdg-open on them. They assume that the helper application blocks until finished, then cleans up the tmpfile.
Problem being that assumption is false. At least in the kde-open case, it returns immediately, and the application cleans up the file prior to it actually being opened. kde-open does have a --tempfile option,
$ kde-open --help-kde-tempfile
...
KDE-tempfile options:
--tempfile The files/URLs opened by the application will be deleted after use
Obviously, great care needs to be taken if using this, however.
See also downstream report,
https://bugzilla.redhat.com/show_bug.cgi?id=653249
### See also
* https://bugzilla.redhat.com/show_bug.cgi?id=653249
* [Bug 652262](http://bugzilla.gnome.org/show_bug.cgi?id=652262)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/40xdg-open fails to handle file names beginning with - (missing -- option) [PATCH]2023-10-09T00:50:17ZBugzilla Migration Userxdg-open fails to handle file names beginning with - (missing -- option) [PATCH]## Submitted by Rüdiger
Assigned to **Portland Bugs**
**[Link to original bug (#32973)](https://bugs.freedesktop.org/show_bug.cgi?id=32973)**
## Description
Created attachment 41851
Patch
$ cat > -test.txt
test
^D
$ xdg-open -tes...## Submitted by Rüdiger
Assigned to **Portland Bugs**
**[Link to original bug (#32973)](https://bugs.freedesktop.org/show_bug.cgi?id=32973)**
## Description
Created attachment 41851
Patch
$ cat > -test.txt
test
^D
$ xdg-open -test.txt
xdg-open: unexpected option '-test.txt'
Try 'xdg-open --help' for more information.
$ xdg-open -- -test.txt
xdg-open: unexpected option '--'
Try 'xdg-open --help' for more information.
Most applications offer the -- flag to deactivate the handling of options and allow the application to handle file names beginning with -. I wrote a patch that adds support for -- to xdg-open. I added a test case and it worked for me with kde-open (should also work with exo-open and gnome. Haven't tried the generic/lxde stuff).
The patch does not support file names "--help" and so on because the code that handles those options is auto generated and not aware of --. I wasn't sure how to fix that and it's probably a very uncommon use case.
**Patch 41851**, "Patch":
[0001-Added-option-to-support-opening-filenames-beginning-.patch](/uploads/00907def51354cc66fbc9f720a5845eb/0001-Added-option-to-support-opening-filenames-beginning-.patch)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/58xdg-open should support selecting/highlighting a file/folder2023-10-14T15:40:18ZBugzilla Migration Userxdg-open should support selecting/highlighting a file/folder## Submitted by Calum
Assigned to **Portland Bugs**
**[Link to original bug (#49552)](https://bugs.freedesktop.org/show_bug.cgi?id=49552)**
## Description
Users have asked for highlighting a selected torrent file/folder in Downloa...## Submitted by Calum
Assigned to **Portland Bugs**
**[Link to original bug (#49552)](https://bugs.freedesktop.org/show_bug.cgi?id=49552)**
## Description
Users have asked for highlighting a selected torrent file/folder in Downloads when using Deluge and I found that xdg-open does not support such an option. Searching around I also found Chromium[1] and other applications are affected so it is needing solved somehow.
On OSX there is a -R option for open which reveals the file/folder in Finder instead of opening and on Windows a '/select,' option exists for explorer.exe
Nautilus now supports such an option if you pass just a filename, although not folders, but it is a starting point and apparently Dolphin has a '--select' option.
[1]http://code.google.com/p/chromium/issues/detail?id=35499https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/59[PATCH] xdg-email --attach with multiple attachments2019-02-16T13:34:58ZBugzilla Migration User[PATCH] xdg-email --attach with multiple attachments## Submitted by Serge Stroobandt
Assigned to **Portland Bugs**
**[Link to original bug (#50016)](https://bugs.freedesktop.org/show_bug.cgi?id=50016)**
## Description
xdg-email --attach %p should be able to work with multiple attac...## Submitted by Serge Stroobandt
Assigned to **Portland Bugs**
**[Link to original bug (#50016)](https://bugs.freedesktop.org/show_bug.cgi?id=50016)**
## Description
xdg-email --attach %p should be able to work with multiple attachments where %p is string of space-separated escaped paths.
Version: 1.1.0 rc1https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/60xdg-open does not mount shares before opening them2019-03-28T08:23:21ZBugzilla Migration Userxdg-open does not mount shares before opening them## Submitted by Martijn Bastiaan
Assigned to **Portland Bugs**
**[Link to original bug (#50401)](https://bugs.freedesktop.org/show_bug.cgi?id=50401)**
## Description
Created attachment 62146
git patch for xdg-open
Hi all,
There'...## Submitted by Martijn Bastiaan
Assigned to **Portland Bugs**
**[Link to original bug (#50401)](https://bugs.freedesktop.org/show_bug.cgi?id=50401)**
## Description
Created attachment 62146
git patch for xdg-open
Hi all,
There's a longstanding bug in xdg-utils: xdg-open does not mount shares (ftp/smb) before opening them. This results in annoying error-messages, and malfunctioning browsers.
For example, when a user clicks on a smb:// link in a major browser (Chrome, Firefox), it suggests opening it with xdg-open. After accepting the proposal nothing happens.
I've attached a patch which should solve the problem for ftp and smb shares.
Kind regards,
Martijn Bastiaan
**Patch 62146**, "git patch for xdg-open":
[mount-before-opening.diff](/uploads/700aba49d6c930d0a02d970badb6788d/mount-before-opening.diff)
Version: 1.1.0 rc1https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/61xdg-mime/xdg-open does not follow mime-actions-spec2023-10-07T19:09:13ZBugzilla Migration Userxdg-mime/xdg-open does not follow mime-actions-spec## Submitted by Vladimir
Assigned to **Portland Bugs**
**[Link to original bug (#56352)](https://bugs.freedesktop.org/show_bug.cgi?id=56352)**
## Description
Freedesktop.org mime-actions-spec (http://freedesktop.org/wiki/Specifica...## Submitted by Vladimir
Assigned to **Portland Bugs**
**[Link to original bug (#56352)](https://bugs.freedesktop.org/show_bug.cgi?id=56352)**
## Description
Freedesktop.org mime-actions-spec (http://freedesktop.org/wiki/Specifications/mime-actions-spec) states that default application for a MIME type is the one that is listed first for a given MIME type in section [Added Associations] of mimeapps.list, e.g.:
------
[Added Associations]
mimetype1=foo1.desktop;foo2.desktop;foo3.desktop;
------
foo1 will will be default for mimetype1
But xdg-open/xdg-mime (via generic function) uses [Default Applications] section
which is not covered in mime-actions-spec and therefore should not even exist in mimeapps.list.
It also completely ignores standard [Added Associations] section in mimeapps.list.
I edit mimeapps.list:
------
[Added Associations]
application/testapp=leafpad.desktop;
------
then run:
xdg-mime query default application/testapp
It returns nothing, but should return "leafpad.desktop".
Version: 1.1.0 rc1https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/62Clarify the xdg-su man page2019-02-16T13:35:14ZBugzilla Migration UserClarify the xdg-su man page## Submitted by Francois Gouget
Assigned to **Portland Bugs**
**[Link to original bug (#57921)](https://bugs.freedesktop.org/show_bug.cgi?id=57921)**
## Description
Created attachment 71040
Better check the -u and -c options and d...## Submitted by Francois Gouget
Assigned to **Portland Bugs**
**[Link to original bug (#57921)](https://bugs.freedesktop.org/show_bug.cgi?id=57921)**
## Description
Created attachment 71040
Better check the -u and -c options and document -c
The xdg-su man page says:
> xdg-su [-u user] -c command
>
> xdg-su provides a graphical dialog that prompts the user for a
> password to run command as user or as root if no user was specified.
The '-c' option is not documented and this does not clearly say if one should use 'xdg-su -c echo HelloWorld' or 'xdg-su -c "echo HelloWorld"'.
The example at the end of the page seems to imply the latter but then it's only one example and one may think that a second example could show that the other option is valid too.
> xdg-su -u root -c "/opt/shinythings/bin/install-GUI --install fast"
I'll further note that the situation is muddied by the fact that
xdg-su -c sh -c 'echo HelloWorld'
is equivalent to
xdg-su -c foo -c 'echo HelloWorld'
and to
xdg-su -c 'echo HelloWorld'
due to the limited parameter checking.
I'm attaching a patch as a starting point for a fix.
**Attachment 71040**, "Better check the -u and -c options and document -c":
[xdg-su.diff](/uploads/d1916efc0b7c71a978e65f121d95c4c1/xdg-su.diff)
Version: beta2https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/63add MATE desktop support in xdg-settings2023-08-10T01:34:56ZBugzilla Migration Useradd MATE desktop support in xdg-settings## Submitted by Elan Ruusamäe
Assigned to **Portland Bugs**
**[Link to original bug (#58861)](https://bugs.freedesktop.org/show_bug.cgi?id=58861)**
## Description
https://github.com/pld-linux/xdg-utils/commit/d00c89c373952fc89dc61...## Submitted by Elan Ruusamäe
Assigned to **Portland Bugs**
**[Link to original bug (#58861)](https://bugs.freedesktop.org/show_bug.cgi?id=58861)**
## Description
https://github.com/pld-linux/xdg-utils/commit/d00c89c373952fc89dc6179ad327785236a54782
MATE support was incomplete in b961235b197647d6649ef3d48d7cc2cecafe3d47
it did not add support for xdg-settings which Google Chrome/Chromium
uses to detect and set default browser.
MATE 1.5 uses same schema as gnome3, so shortcut to gnome3 methods
testcases:
$ xdg-settings get default-web-browser
chromium-browser.desktop
$ xdg-settings check
default-web-browser chromium-browser.desktop
yeshttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/64Can't unmount sshfs after playing a file with vlc (locked by xdg-screensaver)2019-02-16T13:35:21ZBugzilla Migration UserCan't unmount sshfs after playing a file with vlc (locked by xdg-screensaver)## Submitted by Konstantin Svist
Assigned to **Portland Bugs**
**[Link to original bug (#59732)](https://bugs.freedesktop.org/show_bug.cgi?id=59732)**
## Description
When I use VLC to play back a video file mounted via sshfs, I of...## Submitted by Konstantin Svist
Assigned to **Portland Bugs**
**[Link to original bug (#59732)](https://bugs.freedesktop.org/show_bug.cgi?id=59732)**
## Description
When I use VLC to play back a video file mounted via sshfs, I often run into the problem of unmounting the path after playback is finished (and VLC is closed)
VLC is set up to prevent screensaver from showing during playback, but the script that locks this (/usr/bin/xdg-screensaver) only checks for unlock every 50 seconds (using "sleep 50").
In this setup, some sshfs-mounted files remain open and sshfs refuses to unmount since the files are in use.
My temporary workaround is to modify xdg-screensaver to set "sleep 5" -- but this only works because I unmount by hand (5 seconds lag between closing vlc and running the command is acceptable to me). This may not work well if someone sets up a script, for example, to sshfs-mount, play a clip, and instantly unmount when playback is finished.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/72xdg-email opens browser in lxde2019-03-28T02:53:43ZBugzilla Migration Userxdg-email opens browser in lxde## Submitted by Flammie Pirinen
Assigned to **Portland Bugs**
**[Link to original bug (#77560)](https://bugs.freedesktop.org/show_bug.cgi?id=77560)**
## Description
When calling xdg-email on lxde (generic in current logic) it just...## Submitted by Flammie Pirinen
Assigned to **Portland Bugs**
**[Link to original bug (#77560)](https://bugs.freedesktop.org/show_bug.cgi?id=77560)**
## Description
When calling xdg-email on lxde (generic in current logic) it just goes through browsers to open. This affects most obviously to chromium for example, which just opens new windows on mailto: links. However, `xdg-open mailto:foo` correctly opens my preferred email application, so maybe xdg-email on generic should call xdg-open or figure out the x-scheme-handler/mailto?
Version: 1.1.0 rc2https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/74xdg-email manpage homepage is wrong2023-10-14T12:59:14ZBugzilla Migration Userxdg-email manpage homepage is wrong## Submitted by Profpatsch
Assigned to **Portland Bugs**
**[Link to original bug (#86290)](https://bugs.freedesktop.org/show_bug.cgi?id=86290)**
## Description
http://portland.freedesktop.org/wiki/EmailConfig doesn’t exist, it pro...## Submitted by Profpatsch
Assigned to **Portland Bugs**
**[Link to original bug (#86290)](https://bugs.freedesktop.org/show_bug.cgi?id=86290)**
## Description
http://portland.freedesktop.org/wiki/EmailConfig doesn’t exist, it probably should be http://portland.freedesktop.org/EmailConfig/.
Yet, that link is throwing a “Forbidden”.
While at it, a “BUGS“-section in the manpage wouldn’t hurt either, finding this site took me something like 15mins.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/75xdg-open does not handle x-schemes with no URL correctly (suggested PATCH)2023-10-07T20:19:49ZBugzilla Migration Userxdg-open does not handle x-schemes with no URL correctly (suggested PATCH)## Submitted by aay..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#86340)](https://bugs.freedesktop.org/show_bug.cgi?id=86340)**
## Description
I want tp use xdg-open to open my default browser or email-client ...## Submitted by aay..@..il.com
Assigned to **Portland Bugs**
**[Link to original bug (#86340)](https://bugs.freedesktop.org/show_bug.cgi?id=86340)**
## Description
I want tp use xdg-open to open my default browser or email-client by doing e.g.
xdg-open http: or xdg-open mailto:
If I do that, (in the former case) it opens the browser an empty page with the http:// URL and the error 'Page not found' (of course)
Here follows the fix, it needed some fixing on argument quoting (since of the arg is empty, it must not be quoted at all). I took the opportunity to fix [bug 66670](https://bugs.freedesktop.org/show_bug.cgi?id=66670) and change the quoting around the user's argument to single rather than double (it also takes care of single quotes present in it).
Also, first_word was defined twice (once in the beginning and once later one along with last_word) - moved definition of both to the beginning
And lastly, binary_to_desktop_file handled the deprecated applnk location, but nowhere else in the script was this supported - added it to all the other functions
--- xdg-open 2014-11-16 12:14:06.587351388 +0200
+++ xdg-open.fix 2014-11-16 13:08:47.224959973 +0200
@@ -132,6 +132,12 @@
echo "$first"
}
+last_word()
+{
+ read first rest
+ echo "$rest"
+}
+
#-------------------------------------------------------------
# map a binary to a .desktop file
binary_to_desktop_file()
@@ -172,14 +178,16 @@
IFS=:
for dir in $search; do
unset IFS
- [ "$dir" ] && [ -d "$dir/applications" ] || continue
- file="$dir/applications/$desktop"
- [ -r "$file" ] || continue
- # Remove any arguments (%F, %f, %U, %u, etc.).
- command="`grep -E "^Exec(\[[^]=]*])?=" "$file" | cut -d= -f 2- | first_word`"
- command="`which "$command"`"
- readlink -f "$command"
- return
+ [ "$dir" ] || continue
+ [ -d "$dir/applications" ] || [ -d "$dir/applnk" ] || continue
+ for file in "$dir"/applications/*.desktop "$dir"/applications/*/*.desktop "$dir"/applnk/*.desktop "$dir"/applnk/*/*.desktop; do
+ [ -r "$file" ] || continue
+ # Remove any arguments (%F, %f, %U, %u, etc.).
+ command="`grep -E "^Exec(\[[^]=]*])?=" "$file" | cut -d= -f 2- | first_word`"
+ command="`which "$command"`"
+ readlink -f "$command"
+ return
+ done
done
}
@@ -454,19 +462,6 @@
return 0
}
-# This handles backslashes but not quote marks.
-first_word()
-{
- read first rest
- echo "$first"
-}
-
-last_word()
-{
- read first rest
- echo "$rest"
-}
-
open_darwin()
{
open "$1"
@@ -572,10 +567,12 @@
command_exec=`which $command 2>/dev/null`
arguments="`grep -E "^Exec(\[[^]=]*])?=" "$file" | cut -d= -f 2- | last_word`"
arg_one="`echo "$arg" | sed 's/[&*\\]/\\\\&/g'`"
- arguments_exec="`echo "$arguments" | sed -e 's*%[fFuU]*"'"$arg_one"'"*g'`"
+ arg_one="`echo "$arg" | sed \"s/'/'\\\"'\\\"'/g\"`"
+ [ -n "$arg_one" ] && arg_one="'$arg_one'"
+ arguments_exec="`echo "$arguments" | sed -e 's*%[fFuU]*'"$arg_one"'*g'`"
if [ -x "$command_exec" ] ; then
- if echo "$arguments" | grep -iq '%[fFuU]' ; then
+ if echo "$arguments" | grep -iq '%[fu]' ; then
echo START "$command_exec" "$arguments_exec"
eval "$command_exec" "$arguments_exec"
else
@@ -600,15 +597,13 @@
filetype="$2"
default=`xdg-mime query default "$filetype"`
if [ -n "$default" ] ; then
- xdg_user_dir="$XDG_DATA_HOME"
- [ -n "$xdg_user_dir" ] || xdg_user_dir="$HOME/.local/share"
-
- xdg_system_dirs="$XDG_DATA_DIRS"
- [ -n "$xdg_system_dirs" ] || xdg_system_dirs=/usr/local/share/:/usr/share/
+ [ -n "$XDG_DATA_HOME" ] && xdg_user_dir="$XDG_DATA_HOME" || xdg_user_dir="$HOME/.local/share"
+ [ -n "$XDG_DATA_DIRS" ] && xdg_system_dirs="$XDG_DATA_DIRS" || xdg_system_dirs=/usr/local/share/:/usr/share/
DEBUG 3 "$xdg_user_dir:$xdg_system_dirs"
for x in `echo "$xdg_user_dir:$xdg_system_dirs" | sed 's/:/ /g'`; do
- search_desktop_file "$default" "$x/applications/" "$1"
+ [ -d "$x/applications/" ] && search_desktop_file "$default" "$x/applications/" "$1"
+ [ -d "$x/applnk/" ] && search_desktop_file "$default" "$x/applnk/" "$1"
done
fi
}
@@ -622,9 +617,11 @@
open_generic_xdg_x_scheme_handler()
{
scheme="`echo $1 | sed -n 's/\(^[[:alnum:]+\.-]*\):.*$/\1/p'`"
+ uri="`echo $1 | sed -n 's/^[[:alnum:]+\.-]*:\/\{1,\}//p'`"
if [ -n $scheme ]; then
filetype="x-scheme-handler/$scheme"
- open_generic_xdg_mime "$1" "$filetype"
+ [ -n "$uri" ] && open_generic_xdg_mime "$1" "$filetype"
+ open_generic_xdg_mime "" "$filetype"
fi
}
Version: 1.1.0 rc2
### Blocking
* [Bug 23105](https://bugs.freedesktop.org/show_bug.cgi?id=23105)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/76Give xdg-screensaver the ability to report the current timeout2023-08-10T01:17:00ZBugzilla Migration UserGive xdg-screensaver the ability to report the current timeout## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#88028)](https://bugs.freedesktop.org/show_bug.cgi?id=88028)**
## Description
This would be useful for programs that want to manage the screensav...## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#88028)](https://bugs.freedesktop.org/show_bug.cgi?id=88028)**
## Description
This would be useful for programs that want to manage the screensaver, to minimise polling. For example, Caffeine inhibits the screensaver if a window is full-screen. It currently checks every 30 seconds (a reasonable minimum), but if the screensaver timeout were known, it could check that often minus a few seconds and save CPU time and power.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/80xdg-open does not exit if it does not recognize the mimetype2019-02-16T13:36:31ZBugzilla Migration Userxdg-open does not exit if it does not recognize the mimetype## Submitted by Danny Arnold
Assigned to **Portland Bugs**
**[Link to original bug (#89902)](https://bugs.freedesktop.org/show_bug.cgi?id=89902)**
## Description
How to reproduce:
```
$ touch index.html
$ xdg-open index.html#test...## Submitted by Danny Arnold
Assigned to **Portland Bugs**
**[Link to original bug (#89902)](https://bugs.freedesktop.org/show_bug.cgi?id=89902)**
## Description
How to reproduce:
```
$ touch index.html
$ xdg-open index.html#test
xdg-mime: file 'index.html#test' does not exist
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
Could not determine mimetype for file: index.html#test
```
The process simply never returns, which breaks any app that calls xdg-open synchronously (like github atom).
Version: xdg-open 1.1.0 rc3
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/82xdg-icon-resource does not support svg2021-07-05T09:04:54ZBugzilla Migration Userxdg-icon-resource does not support svg## Submitted by Rodrigo Silva
Assigned to **Portland Bugs**
**[Link to original bug (#91759)](https://bugs.freedesktop.org/show_bug.cgi?id=91759)**
## Description
Spec includes SVG http://standards.freedesktop.org/icon-theme-spec/...## Submitted by Rodrigo Silva
Assigned to **Portland Bugs**
**[Link to original bug (#91759)](https://bugs.freedesktop.org/show_bug.cgi?id=91759)**
## Description
Spec includes SVG http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html , but xdg-icon-resource does not support them
Attempting to install an SVG icon gives:
xdg-icon-resource: icon file to install must be a *.png or *.xpm file
Try 'xdg-icon-resource --help' for more information.
This is perhaps a duplicate of bug #7837 , and it was reported in Ubuntu's Launchpad https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/790449
Also, for scalable icons like SVG the --size argument should be optional (or not allowed at all)
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/83xdg-settings assumes desktop files have exactly one Exec line2019-02-16T13:36:50ZBugzilla Migration Userxdg-settings assumes desktop files have exactly one Exec line## Submitted by Chad MILLER
Assigned to **Portland Bugs**
**[Link to original bug (#92170)](https://bugs.freedesktop.org/show_bug.cgi?id=92170)**
## Description
Example command:
xdg-settings set default-web-browser chromium-brows...## Submitted by Chad MILLER
Assigned to **Portland Bugs**
**[Link to original bug (#92170)](https://bugs.freedesktop.org/show_bug.cgi?id=92170)**
## Description
Example command:
xdg-settings set default-web-browser chromium-browser.desktop
In searching the desktop file for suitability, it scans for all lines that begin "Exec", and takes the result and packs it into a variable.
If there is exactly one Exec line, this takes out a command name to test for existence, but when more than one matches, the program name is captured as "firstexecprog\nsecondexecprog\nthirdexecprog", and "which" doesn't know how to look up a program like that and the subsequent tests fail.
Output with sh's "-x" option on:
+ grep -E ^Exec(\[[^]=]*])?= /usr/share//applications/chromium-browser.desktop
+ command=chromium-browser
chromium-browser
chromium-browser
chromium-browser
+ which chromium-browser
chromium-browser
chromium-browser
chromium-browser
+ command=
+ readlink -f
+ return
+ binary=
+ [ ]
+ exit_failure_file_missing
+ [ 0 -gt 0 ]
In desktop_file_to_binary and binary_to_desktop_file functions, it makes false assumptions how many times grep may match. Those should treat each Exec match separately.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/84xdg-open does not spawn terminal for Terminal=true2023-08-19T10:53:28ZBugzilla Migration Userxdg-open does not spawn terminal for Terminal=true## Submitted by Thomas Gläßle
Assigned to **Portland Bugs**
**[Link to original bug (#92514)](https://bugs.freedesktop.org/show_bug.cgi?id=92514)**
## Description
Created attachment 118945
Ad hoc patch to launch terminal
xdg-open...## Submitted by Thomas Gläßle
Assigned to **Portland Bugs**
**[Link to original bug (#92514)](https://bugs.freedesktop.org/show_bug.cgi?id=92514)**
## Description
Created attachment 118945
Ad hoc patch to launch terminal
xdg-open does not spawn terminals for desktop files with `Terminal=true`.
For example consider the following configuration:
`~/.local/share/applications/ranger.desktop`:
[Desktop Entry]
Name=ranger
Type=Application
Terminal=true
Exec=ranger %F
`~/.local/share/applications/mimeapps.list`:
[Default Applications]
inode/directory=ranger.desktop
inode/mount-point=ranger.desktop
Then I expect ranger to be opened in a terminal upon running:
xdg-open /
What currently happens is:
(a) if running the command from a non-terminal context, xdg-open tries to execute ranger without terminal. This errors and xdg-open falls back to execute mimeopen which ignores mimeapps.list and only looks at defaults.list and therefore confusingly may use another default.
(b) if running the command within a terminal, ranger is opened in the current terminal. While this is fine, I think it would be fine as well to spawn a new terminal.
This applies to xdg-utils 1.1.1.
The attached patch spawns a new terminal asynchronously indiscriminately of case (a) versus case (b). It uses the TERMINAL environment variable, similar to what `mimeopen` does.
**Attachment 118945**, "Ad hoc patch to launch terminal":
[spawn_terminal.diff](/uploads/c0207e28d55645cd43a101301bb2ad99/spawn_terminal.diff)
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/87xdg-screensaver should call system perl instead of just perl2023-08-14T01:18:18ZBugzilla Migration Userxdg-screensaver should call system perl instead of just perl## Submitted by Tim Heaney
Assigned to **Portland Bugs**
**[Link to original bug (#93596)](https://bugs.freedesktop.org/show_bug.cgi?id=93596)**
## Description
Created attachment 120820
patch against current git repo
I installed ...## Submitted by Tim Heaney
Assigned to **Portland Bugs**
**[Link to original bug (#93596)](https://bugs.freedesktop.org/show_bug.cgi?id=93596)**
## Description
Created attachment 120820
patch against current git repo
I installed an alternate version of Perl higher in my path than the system perl and started getting warnings when I called parole
$ parole foo.mp4
Can't locate Net/DBus.pm in @INC (you may need to install the Net::DBus module) (@INC contains: /home/tim/perl/lib /home/tim/.plenv/versions/5.22.1/lib/perl5/site_perl/5.22.1/x86_64-linux /home/tim/.plenv/versions/5.22.1/lib/perl5/site_perl/5.22.1 /home/tim/.plenv/versions/5.22.1/lib/perl5/5.22.1/x86_64-linux /home/tim/.plenv/versions/5.22.1/lib/perl5/5.22.1 .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
After some fussing, I determined that the warning was coming from xdg-screensaver, specifically, the screensaver_gnome_screensaver() function. It calls Perl with just "perl -e" which assumes that whatever perl is highest in the path has the Net::DBus module. I changed line 918 from "perl -e" to "/usr/bin/perl -e" and now all is well.
$ xdg-screensaver --version
xdg-screensaver 1.1.0 rc3
$ lsb_release --description
Description: Ubuntu 15.10
That's on my system, but the issue still seems to be present. I've attached a patch against the current source.
**Attachment 120820**, "patch against current git repo":
[xdg-screensaver.in.patch](/uploads/7ec813122e9120c6a773340558beecde/xdg-screensaver.in.patch)
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/89xdg-screensaver reset silently fails on gnome2019-02-16T13:37:22ZBugzilla Migration Userxdg-screensaver reset silently fails on gnome## Submitted by Jason Papakostas
Assigned to **Portland Bugs**
**[Link to original bug (#97001)](https://bugs.freedesktop.org/show_bug.cgi?id=97001)**
## Description
`xdg-screensaver reset` does nothing on gnome but fails silently...## Submitted by Jason Papakostas
Assigned to **Portland Bugs**
**[Link to original bug (#97001)](https://bugs.freedesktop.org/show_bug.cgi?id=97001)**
## Description
`xdg-screensaver reset` does nothing on gnome but fails silently, returning exit code 0
https://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-screensaver.in?id=066b46418f454c0b7e1b5e1478f5f94d91276c14#n533
If you add --print-reply you can at least get a non-zero exit status and this message:
Error org.freedesktop.DBus.Error.UnknownMethod: No such method 'SimulateUserActivity'
I believe this is the where gnome rejects the call:
https://github.com/GNOME/gnome-settings-daemon/blob/f8db21e27f89e58e1439be42052f12d5bdf8ecc1/plugins/screensaver-proxy/gsd-screensaver-proxy-manager.c#L257-L258
I don't know if there's a replacement API, I couldn't find one.
I'm using Arch Linux,
extra/gnome-shell 3.20.3-1 (gnome) [installed]
extra/xdg-utils 1.1.1-3 [installed]
Though the version reported by xdg-screensaver is different:
❯ xdg-screensaver --version
xdg-screensaver 1.1.0 rc3
Version: 1.1.0 rc3https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/92quotation character not parsing properly in .desktop2023-08-09T09:42:45ZBugzilla Migration Userquotation character not parsing properly in .desktop## Submitted by Scott
Assigned to **Portland Bugs**
**[Link to original bug (#97632)](https://bugs.freedesktop.org/show_bug.cgi?id=97632)**
## Description
when quotations are used for Icon= the .desktop file fails to launch when c...## Submitted by Scott
Assigned to **Portland Bugs**
**[Link to original bug (#97632)](https://bugs.freedesktop.org/show_bug.cgi?id=97632)**
## Description
when quotations are used for Icon= the .desktop file fails to launch when clicked on.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/93Warn / fail if xdg-screensaver cannot find xprop2023-08-09T09:42:06ZBugzilla Migration UserWarn / fail if xdg-screensaver cannot find xprop## Submitted by nic..@..min.me
Assigned to **Portland Bugs**
**[Link to original bug (#97811)](https://bugs.freedesktop.org/show_bug.cgi?id=97811)**
## Description
On Gnome 3, xdg-screensaver fails to suspend the screensaver if xp...## Submitted by nic..@..min.me
Assigned to **Portland Bugs**
**[Link to original bug (#97811)](https://bugs.freedesktop.org/show_bug.cgi?id=97811)**
## Description
On Gnome 3, xdg-screensaver fails to suspend the screensaver if xprop is not installed.
Without xprop the $screensaver_file is not created (as xdg-screensaver cannot retrieve the window ID), and so the "inhibitor" placed on the session via DBus expires after the 10s sleep in the Perl DBus script loop.
---
while (1) {
sleep(10);
my $status = new IO::File($screensaver_file, "r")
or exit 0;
---
xdg-screensaver seems to try to support the case where xprop is not installed (It checks for xprop, and various functions bail out early if it's not available). However with Gnome 3 (and perhaps with other environments) it seems it's a hard requirement, and as such the user should be warned if it's missing.
I believe that affects numerous users as there have been several reports of xdg-screensaver failing with Gnome in various projects:
* https://bugzilla.redhat.com/show_bug.cgi?id=665918
* https://trac.videolan.org/vlc/ticket/4739
* https://forum.videolan.org/viewtopic.php?t=127389
Version: 1.1.0https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/96xdg-open: support multiple command-line arguments2019-02-16T13:37:45ZBugzilla Migration Userxdg-open: support multiple command-line arguments## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98498)](https://bugs.freedesktop.org/show_bug.cgi?id=98498)**
## Description
Created attachment 127614
Add multiple argument support to xdg-open...## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98498)](https://bugs.freedesktop.org/show_bug.cgi?id=98498)**
## Description
Created attachment 127614
Add multiple argument support to xdg-open
Attached, a patch against current git to extend xdg-open to support multiple command-line arguments.
Some use cases (e.g. Emacs's dired launcher) assume a command that can launch multiple files/URLs at once.
In case of error, the first error is returned, but xdg-open continues to process the rest of its arguments.
I also attach a related patch that removes documentation of error code 3 (one of the files passed on the command line does not exist), which is never used by xdg-open.
**Patch 127614**, "Add multiple argument support to xdg-open":
[0003-xdg-open-support-multiple-arguments.patch](/uploads/f5ab64907d2ce7e84b68f303f8a16a58/0003-xdg-open-support-multiple-arguments.patch)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/98Fix xdg-screensaver to work with untitled windows2023-08-09T09:38:37ZBugzilla Migration UserFix xdg-screensaver to work with untitled windows## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98519)](https://bugs.freedesktop.org/show_bug.cgi?id=98519)**
## Description
Created attachment 127649
Patch to xdg-screensaver to fix suspendin...## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98519)](https://bugs.freedesktop.org/show_bug.cgi?id=98519)**
## Description
Created attachment 127649
Patch to xdg-screensaver to fix suspending with window ID where the window has no name
Currently, xdg-screensaver fails (but does not report an error) if the window ID given belongs to a window with no WM_NAME, e.g. the root window.
The attached patch against current git master fixes that.
**Patch 127649**, "Patch to xdg-screensaver to fix suspending with window ID where the window has no name":
[0005-xdg-screensaver-fix-suspending-using-window-without-.patch](/uploads/171bf35b50fe0ed57aee2c3d4ebc8881/0005-xdg-screensaver-fix-suspending-using-window-without-.patch)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/100Common up xdg-screensaver code that deals with Freedesktop desktop idleness i...2023-08-09T09:36:07ZBugzilla Migration UserCommon up xdg-screensaver code that deals with Freedesktop desktop idleness inhibition API## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98614)](https://bugs.freedesktop.org/show_bug.cgi?id=98614)**
## Description
At present xdg-screensaver contains several almost-identical functi...## Submitted by Reuben Thomas
Assigned to **Portland Bugs**
**[Link to original bug (#98614)](https://bugs.freedesktop.org/show_bug.cgi?id=98614)**
## Description
At present xdg-screensaver contains several almost-identical functions to deal with the various desktops that implement the Freedesktop desktop idleness inhibition DBus API, or something like it.
One example is the code for MATE, which bears the following comment:
# DBUS interface for mate-screensaver
# This is same as gnome's for now but may change in the future as MATE
# does not follow gnome's developement necessarily.
I think this is an unfortunate attitude to take with respect to Freedesktop standards in Freedesktop project code. We should be optimistic about the adoption of standards, and encourage their use.
Hence, I suggest that the following functions have their common code factored out:
screensaver_freedesktop (ironically only used for KDE)
screensaver_mate_screensaver
screensaver_gnome_screensaver (also used for GNOME 3's gnome-shell)
screensaver_cinnamon_screensaver
Even some DBus end-points not covered by the Freedesktop spec, such as "SimulateUserActivity" are common between most or all of the above, with the exception of a different prefix.https://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).https://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/146xdg-mime checks if the item really exists, but not when storing2019-02-21T21:37:00Z積丹尼 Dan Jacobsonxdg-mime checks if the item really exists, but not when storingOn https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922914
we observe xdg-mime does a check on if the item really exists, but it is only done on
retrieving it. Not storing it. Why not both?On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922914
we observe xdg-mime does a check on if the item really exists, but it is only done on
retrieving it. Not storing it. Why not both?https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/147xdg-open and xdg-mime disagree on the default handler app2023-10-09T00:50:59ZJānis Elmerisxdg-open and xdg-mime disagree on the default handler app`xdg-open ~` opens my home folder in "Nemo" although `xdg-mime` tells "Visual Studio Code" should be used:
```
[2019-03-12 15:43:17] janis@janispc:~$ xdg-mime query default inode/directory
com.visualstudio.code.desktop
```
It looks like...`xdg-open ~` opens my home folder in "Nemo" although `xdg-mime` tells "Visual Studio Code" should be used:
```
[2019-03-12 15:43:17] janis@janispc:~$ xdg-mime query default inode/directory
com.visualstudio.code.desktop
```
It looks like the Code's handler is set in Flatpak's `/var/lib/flatpak/exports/share/applications/com.visualstudio.code.desktop` (cached in `/var/lib/flatpak/exports/share/applications/mimeinfo.cache`), which gets read by `xdg-mime` before it gets to `/usr/share/applications/defaults.list`, where Nemo is listed as the default app.
The problem here is the inconsistency. Given my mime handler configuration files, should the directories be opened by Code or Nemo? Why does `xdg-open` think differently than `xdg-mime`?
Output from my current machine:
```
$ XDG_UTILS_DEBUG_LEVEL=2 xdg-mime query default inode/directory
Checking /home/janis/.config/mimeapps.list
Checking /home/janis/.local/share/applications/mimeapps.list
Checking /home/janis/.local/share/applications/defaults.list and /home/janis/.local/share/applications/mimeinfo.cache
Checking /home/janis/.local/share/applications/defaults.list and /home/janis/.local/share/applications/mimeinfo.cache
Checking /usr/share/cinnamon/applications/defaults.list and /usr/share/cinnamon/applications/mimeinfo.cache
Checking /usr/share/cinnamon/applications/defaults.list and /usr/share/cinnamon/applications/mimeinfo.cache
Checking /usr/share/gnome/applications/defaults.list and /usr/share/gnome/applications/mimeinfo.cache
Checking /usr/share/gnome/applications/defaults.list and /usr/share/gnome/applications/mimeinfo.cache
Checking /home/janis/.local/share/flatpak/exports/share/applications/defaults.list and /home/janis/.local/share/flatpak/exports/share/applications/mimeinfo.cache
Checking /home/janis/.local/share/flatpak/exports/share/applications/defaults.list and /home/janis/.local/share/flatpak/exports/share/applications/mimeinfo.cache
Checking /var/lib/flatpak/exports/share/applications/defaults.list and /var/lib/flatpak/exports/share/applications/mimeinfo.cache
com.visualstudio.code.desktop
```
Output from a freshly installed other machine (no directory handler set for Code):
```
$ XDG_UTILS_DEBUG_LEVEL=2 xdg-mime query default inode/directory
Checking /home/janis/.config/mimeapps.list
Checking /home/janis/.local/share/applications/defaults.list and /home/janis/.local/share/applications/mimeinfo.cache
Checking /home/janis/.local/share/applications/defaults.list and /home/janis/.local/share/applications/mimeinfo.cache
Checking /usr/share/cinnamon/applications/defaults.list and /usr/share/cinnamon/applications/mimeinfo.cache
Checking /usr/share/cinnamon/applications/defaults.list and /usr/share/cinnamon/applications/mimeinfo.cache
Checking /usr/share/gnome/applications/defaults.list and /usr/share/gnome/applications/mimeinfo.cache
Checking /usr/share/gnome/applications/defaults.list and /usr/share/gnome/applications/mimeinfo.cache
Checking /home/janis/.local/share/flatpak/exports/share/applications/defaults.list and /home/janis/.local/share/flatpak/exports/share/applications/mimeinfo.cache
Checking /home/janis/.local/share/flatpak/exports/share/applications/defaults.list and /home/janis/.local/share/flatpak/exports/share/applications/mimeinfo.cache
Checking /var/lib/flatpak/exports/share/applications/defaults.list and /var/lib/flatpak/exports/share/applications/mimeinfo.cache
Checking /var/lib/flatpak/exports/share/applications/defaults.list and /var/lib/flatpak/exports/share/applications/mimeinfo.cache
Checking /usr/local/share/applications/defaults.list and /usr/local/share/applications/mimeinfo.cache
Checking /usr/local/share/applications/defaults.list and /usr/local/share/applications/mimeinfo.cache
Checking /usr/share/applications/defaults.list and /usr/share/applications/mimeinfo.cache
nemo.desktop
```
I'm using Linux Mint 19.1. You may find more details regarding my case in Linux Mint forums thread – https://forums.linuxmint.com/viewtopic.php?f=47&t=289929https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/148[RFE] allow xdg-mime to set defaults "for all subtypes"2023-08-09T08:24:07ZKonstantin Kharlamov[RFE] allow xdg-mime to set defaults "for all subtypes"For example, there's countless number of file types under the `text/`, e.g. `text/x-diff`, `text/plain`, `text/x-c++`, etc. No way one would be able to cover every one of them manually, it would be great if `xdg-mime default …` instead w...For example, there's countless number of file types under the `text/`, e.g. `text/x-diff`, `text/plain`, `text/x-c++`, etc. No way one would be able to cover every one of them manually, it would be great if `xdg-mime default …` instead would allow sort of shell expansion `text/*` *(though I assume `*` may be a valid symbol, it's just an example, maybe a command line option would solve that)*.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/149xdg-email fails to attach filesnames with a comma "," to thunderbird2023-08-09T08:23:43ZAlexander Hofmannxdg-email fails to attach filesnames with a comma "," to thunderbirdWhen attaching a file to Thunderbird using xdg-email, it passes the full path to Thunderbird, as possible with TB3+. However, the syntax of TB uses the comma "," as filename separator. If a filename already contains a comma, Thunderbird ...When attaching a file to Thunderbird using xdg-email, it passes the full path to Thunderbird, as possible with TB3+. However, the syntax of TB uses the comma "," as filename separator. If a filename already contains a comma, Thunderbird will not find it and fails to attach it.
This could probably be fixed in Thunderbird, but would require them to change their command line syntax which is a big change. A different solution is to change from the "full path" syntax to "file://<path>" using a full URL-encodeing?
Example: the file is located at "/home/someuser/file, name.txt"
Calling xdg-email with `xdg-email --attach '/home/someuser/file, name.txt'` will produce (`XDG_UTILS_DEBUG_LEVEL=1`)
`/usr/lib/thunderbird/thunderbird.sh -compose "attachment='/home/someuser/file, name.txt'"`
And Thunderbird expects two files now, one "/home/someuser/file" and the other "name.txt". Instead
`/usr/lib/thunderbird/thunderbird.sh -compose "attachment='file///home/someuser/file%2C%20name.txt'"`
works.
As it turned out, not much needs to be changed. I created a crude patch to change from "file name scheme" to "uri scheme" against the current (I think) version with (for me) solves the issue. Note that I'm not a bash expert, so the solution might give room for improvement.
```
570c570,571
< ATTACH=$(/bin/echo -e $(echo "$MAILTO" | grep '^attach=' | sed 's/^attach=//;s/%\(..\)/\\x\1/g' | awk '{ printf "%s,",$0 }' | sed 's/,$//'))
---
> ATTACH=$(/bin/echo -e $(echo "$MAILTO" | grep '^attach=' | sed 's/^attach=/file:\/\//' ))
> ATTACH=$(echo $ATTACH | tr '\n' ',' | sed 's/,$//')
```
I initially posted it on bugs.launchpad.net here: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1823689https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/151URL handler and xdg-mime not working when Exec line contains quoted path2023-12-21T05:22:59ZJonathan HaylettURL handler and xdg-mime not working when Exec line contains quoted pathWhen the command file path in the `Exec` field of a desktop file is wrapped in double quotes, xdg-mime and the URL handling seem to be unable to deal with it.
E.g.
```
[Desktop Entry]
Name=Slippi Launcher
Comment=Slippi Desktop App for ...When the command file path in the `Exec` field of a desktop file is wrapped in double quotes, xdg-mime and the URL handling seem to be unable to deal with it.
E.g.
```
[Desktop Entry]
Name=Slippi Launcher
Comment=Slippi Desktop App for browsing and playing replays.
Exec="/home/haystack/source/Slippi-Launcher-1.4.5-x86_64.AppImage" %U
Terminal=false
Type=Application
Icon=appimagekit-slippi-desktop-app
StartupWMClass=Slippi Launcher
X-AppImage-Version=1.4.5
MimeType=x-scheme-handler/slippi;
Categories=Development;
X-AppImage-BuildId=1K1bOeuJzPhoG9WcseHboZyGhZK
X-Desktop-File-Install-Version=0.24
X-AppImage-Comment=Generated by /tmp/.mount_SlippipSpjHL/AppRun
TryExec=/home/haystack/source/Slippi-Launcher-1.4.5-x86_64.AppImage
```
```
❯ xdg-settings set default-url-scheme-handler slippi appimagekit-slippi-desktop-app.desktop
which: no Slippi-Launcher-1.4.5-x86_64.AppImage" in (./"/home/haystack/source)
```
[The desktop entry spec](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables) seems to say that quoting the path should be fine. Based on this it seems that xdg-utils is not correctly implementing the desktop file specification. Desktop files with a quoted exec path usually work fine.
[electron-builder](https://github.com/electron-userland/electron-builder) also seems to (quite reasonably) create desktop files with a quoted file path, but then they are broken with xdg-utils (URL handling won't work, nor will xdg-mime). If there are spaces in the file path or any other special character that needs escaping, then backslashes would have to be inserted which is much more inconvenient than quoting the whole path, which works pretty much everywhere else in GNU/Linux.
I believe this is something that should be fixed on xdg-utils' end, not in electron-builder or any other program that quotes the executable paths in desktop entries.
See also:
https://github.com/project-slippi/slippi-desktop-app/issues/24
https://github.com/electron-userland/electron-builder/issues/2759https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/156xdg-open executable filetype2019-08-30T00:10:43Zklausxdg-open executable filetypewhen i try to use xdg-open with an exe file, i see my brower being launched instead.
like this: `xdg-open /some/path/my_exe_file`
actualy does this: `www-browser /some/path/my_exe_file`
apparently xdg-open / xdg-mime doesn't know what t...when i try to use xdg-open with an exe file, i see my brower being launched instead.
like this: `xdg-open /some/path/my_exe_file`
actualy does this: `www-browser /some/path/my_exe_file`
apparently xdg-open / xdg-mime doesn't know what to do with executables filetype.
please consider this:
```
$ file my_exe_file
my_exe_file: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=7b881c37c7e49c7d8950ef4f9b1fe5c4a79bf399, not stripped
$ xdg-mime query filetype my_exe_file
application/x-executable
$ xdg-mime query default application/x-executable
(returns nothing)
$ xdg-open my_exe_file
(browser pops up)
```
so xdg-mime knows there is such a filetype as "application/x-executable".
but there is no action associated to those, and i don't know what to put there.
am i supposed to create an 'execute.desktop' file of some sort? if yes, what to put in it then?
how can i use xdg-open to correctly allow me to run files that are of type "application/x-executable" ?https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/157xdg-open should look at targets of symbolic links2019-09-05T22:35:47ZChris Grahamxdg-open should look at targets of symbolic linksIf I have a symbolic link `foo`, pointing to `foo.xlsx`, `xdg-open` will open `foo` as a zip file based on falling back to 'magic' detection of mime type. I think preferred behavior would be it would, failing to get a file extension of t...If I have a symbolic link `foo`, pointing to `foo.xlsx`, `xdg-open` will open `foo` as a zip file based on falling back to 'magic' detection of mime type. I think preferred behavior would be it would, failing to get a file extension of the symlink itself, recognize it as a symlink and look at the file extension of the target.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/159xdg-mime --all query default2023-08-09T08:04:33Z積丹尼 Dan Jacobsonxdg-mime --all query defaultSure we can do one by one
```
$ xdg-mime query default image/png
wine-extension-png.desktop
$ xdg-mime query default application/zip
...
```
but why not allow us to see them all
`$ xdg-mime query default ALL`
or
`$ xdg-mime --all quer...Sure we can do one by one
```
$ xdg-mime query default image/png
wine-extension-png.desktop
$ xdg-mime query default application/zip
...
```
but why not allow us to see them all
`$ xdg-mime query default ALL`
or
`$ xdg-mime --all query default`https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/161xdg-open only substitutes field codes that are surrounded by spaces2023-11-16T00:30:07ZSebastiaan Lokhorstxdg-open only substitutes field codes that are surrounded by spaces`xdg-open` only substitutes field codes such as `%f` if they are separate arguments, i.e. if they are surrounded by spaces.
This works:
```
Exec=foo --bar %f
```
This doesn't work:
```
Exec=foo --bar=%f
```
The [Desktop Entry Specific...`xdg-open` only substitutes field codes such as `%f` if they are separate arguments, i.e. if they are surrounded by spaces.
This works:
```
Exec=foo --bar %f
```
This doesn't work:
```
Exec=foo --bar=%f
```
The [Desktop Entry Specification](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables) does not seem to mention that field codes have to be surrounded by spaces. Other openers such as `gio open` do not have this limitation.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/170xdg-settings for setting mailto handler does nothing2020-04-19T05:48:58ZJaakko Luttinenxdg-settings for setting mailto handler does nothingWhy doesn't `thunderbird.desktop` get set as my default `mailto` handler, but `chromium-browser.desktop` instead?
I hope this contains all relevant information:
Here are my XDG data dirs:
```
$ echo $XDG_DATA_DIRS
/home/jluttine/.nix-p...Why doesn't `thunderbird.desktop` get set as my default `mailto` handler, but `chromium-browser.desktop` instead?
I hope this contains all relevant information:
Here are my XDG data dirs:
```
$ echo $XDG_DATA_DIRS
/home/jluttine/.nix-profile/share:/etc/profiles/per-user/jluttine/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share
```
Just to verify the first three paths don't exist:
```
$ ls /home/jluttine/.nix-profile/share
ls: cannot access '/home/jluttine/.nix-profile/share': No such file or directory
$ ls /etc/profiles/per-user/jluttine/share
ls: cannot access '/etc/profiles/per-user/jluttine/share': No such file or directory
$ ls /nix/var/nix/profiles/default/share
ls: cannot access '/nix/var/nix/profiles/default/share': No such file or directory
```
So, `thunderbird.desktop` from the fourth/last XDG data dir must be used. It's content:
```
$ cat /run/current-system/sw/share/applications/thunderbird.desktop
[Desktop Entry]
Type=Application
Exec=thunderbird %U
Terminal=false
Name=Thunderbird
Icon=/nix/store/xhj0aysfcqy1zwnl37iwnfl2zd5dq3j9-thunderbird-68.7.0/lib/thunderbird/chrome/icons/default/default256.png
GenericName=Mail Reader
MimeType=x-scheme-handler/mailto;message/rfc822;x-scheme-handler/feed;application/rss+xml;application/x-extension-rss;x-scheme-handler/news;x-scheme-handler/snews;x-scheme-handler/nntp
Categories=Application;Network
```
Yes, it seems to have `x-scheme-handler/mailto` in `MimeType`. So, let's set it as our default `mailto` handler:
```
$ xdg-settings set default-url-scheme-handler mailto thunderbird.desktop
```
Let's check it actually got set:
```
$ xdg-settings get default-url-scheme-handler mailto
chromium-browser.desktop
```
What...???? Why is it `chromium-browser.desktop`??https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/171xdg-mime not race-condition safe2020-04-20T04:31:17ZJaakko Luttinenxdg-mime not race-condition safe`xdg-mime` doesn't seem to work properly if one tries to set values too fast/simultaneously. I'm able to reproduce the bad behavior as follows:
```
$ rm ~/.config/mimeapps.list
$ xdg-mime default okularApplication_epub.desktop applicat...`xdg-mime` doesn't seem to work properly if one tries to set values too fast/simultaneously. I'm able to reproduce the bad behavior as follows:
```
$ rm ~/.config/mimeapps.list
$ xdg-mime default okularApplication_epub.desktop application/epub & xdg-mime default okularApplication_pdf.desktop application/pdf
[1] 9211
mv: cannot stat '/home/jluttine/.config/mimeapps.list.new': No such file or directory
[1]+ Done xdg-mime default okularApplication_epub.desktop application/epub
$ cat ~/.config/mimeapps.list
[Default Applications]
application/pdf=okularApplication_pdf.desktop
p
```
Not only did it miss the other setting, but it seems that the file is corrupted.
I think `xdg-mime` should definitely handle this case for at least the following reasons:
- in a desktop environment, it is possible that multiple processes are setting some values at the same time
- it is likely to happen, because it is easy to write some initialization code that runs a bunch of commands in parallel (e.g., running xdg-mime commands in i3 config)
- in general, it's just bad file IO handling if it corrupts the file like this
*A simple solution*
If needed, I think it would be acceptable if some of the settings would get ignored, but at least the file shouldn't get corrupted. Some pseudo-solution sketching with shell commands:
First create a random unique file safely (in the same directory):
```
TEMPFILE=$(mktemp ~/.config/mimeapps.list.XXXXXX)
```
Write the stuff into this file. Then, at the end, use `mv` because it's atomic:
```
mv -f $TEMPFILE ~/.config/mimeapps.list
```
This way the file will not get corrupted, but you will might lose some settings if they are done at the same time. To handle simultaneous settings correctly, some kind of file locking (or database, please no...) would be needed.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/172Add support for --program-prefix, --program-suffix and --program-transform-na...2023-08-09T03:20:46ZAndrey ``Bass'' ShcheglovAdd support for --program-prefix, --program-suffix and --program-transform-name to the configure scriptPlease add support for `--program-prefix`, `--program-suffix` and `--program-transform-name` switches to the `configure` script. These switches are standard for _Autoconf_, with the corresponding `m4` macros defined in `general.m4`.
Whe...Please add support for `--program-prefix`, `--program-suffix` and `--program-transform-name` switches to the `configure` script. These switches are standard for _Autoconf_, with the corresponding `m4` macros defined in `general.m4`.
When testing the trunk version of `xdg-utils`, it is useful to have them installed with slightly different names.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/173xdg-open doesn't expand %u in Exec if it's not delimited with spaces2023-10-03T14:26:23ZAndrey ``Bass'' Shcheglovxdg-open doesn't expand %u in Exec if it's not delimited with spacesConsider the following desktop entry:
```
[Desktop Entry]
Exec=seamonkey -remote openURL(%u%,new-tab)
```
Here, `%u` is never expanded upon execution, and the actual command executed is
```
/usr/bin/seamonkey -remote 'openURL(%u,new-w...Consider the following desktop entry:
```
[Desktop Entry]
Exec=seamonkey -remote openURL(%u%,new-tab)
```
Here, `%u` is never expanded upon execution, and the actual command executed is
```
/usr/bin/seamonkey -remote 'openURL(%u,new-window)' http://example.com
```
Your [documentation](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables) doesn't mention that such a limitation exists.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/174xdg-open fails to process a quoted argument with spaces and splits it instead2023-11-15T18:51:44ZAndrey ``Bass'' Shcheglovxdg-open fails to process a quoted argument with spaces and splits it insteadThere appears to be a workaround for issue #173: use `bash -c` as a wrapper and pass the last argument (`%u` in our example) to it as `$1` (see [this answer](https://unix.stackexchange.com/a/588170/94327) for details). Okay, `xdg-open` h...There appears to be a workaround for issue #173: use `bash -c` as a wrapper and pass the last argument (`%u` in our example) to it as `$1` (see [this answer](https://unix.stackexchange.com/a/588170/94327) for details). Okay, `xdg-open` has an undocumented limitation noone has thought of in the first place, but we can deal with it.
In theory this would look like this:
```
[Desktop Entry]
Exec=bash -c 'seamonkey -remote openURL($1,new-tab)' seamonkey-wrapper %u
```
Here, `bash` will name the shell `seamonkey-wrapper` and eventually execute
```
seamonkey -remote openURL(%u,new-tab)
```
with `%u` already expanded by `xdg-open`.
The [specification](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables) prescribes that double quotes should be escaped, and whatever is to be quoted should be quoted.
The problem is, I can't get this to work. No matter how exactly I escape and/or quote my arguments:
```
Exec=bash -c "seamonkey -remote openURL($1,new-tab)" seamonkey-wrapper %u
Exec=bash -c \"seamonkey -remote openURL($1,new-tab)\" seamonkey-wrapper %u
Exec=bash -c 'seamonkey -remote openURL($1,new-tab)' seamonkey-wrapper %u
Exec=bash -c \'seamonkey -remote openURL($1,new-tab)\' seamonkey-wrapper %u
```
-- I can't pass `seamonkey -remote openURL($1,new-tab)` as a single quoted argument to `bash`, w/o `xdg-open` splitting it into three tokens.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/176symlinks not respected properly2020-07-31T16:13:12Z積丹尼 Dan Jacobsonsymlinks not respected properlyIn http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39349
we see how symlinks are not respected properly.In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39349
we see how symlinks are not respected properly.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177Attaching files with mailto:?attach=... parameter is considered dangerous2024-03-17T22:18:44ZJens MuellerAttaching files with mailto:?attach=... parameter is considered dangerousIn `run_thunderbird()`, xdg-email greps for a proprietary `attach` parameter:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-email.in#L51
This allows arbitrary websites with mailto links to add local files on dis...In `run_thunderbird()`, xdg-email greps for a proprietary `attach` parameter:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-email.in#L51
This allows arbitrary websites with mailto links to add local files on disk into the Thunderbird's email composition dialog and should be removed: https://twitter.com/i/status/1295357952480751616
After Thunderbird removed this functionality years ago, I think xdg-email somewhat re-introduced it.
Original bug report for Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=1613425https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/179Add a verbose output option to xdg tools2023-08-09T03:15:27ZBruno DuyéAdd a verbose output option to xdg toolsHi,
I'm using `xdg-open` on different files but in many cases nothing happens. I would like to be able to see what's going on here, using something like `xdg-open --verbose`, and `xdg-mime --verbose`
Example:
```
$ wget https://www.goo...Hi,
I'm using `xdg-open` on different files but in many cases nothing happens. I would like to be able to see what's going on here, using something like `xdg-open --verbose`, and `xdg-mime --verbose`
Example:
```
$ wget https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png
# file --mime-type returns the correct filetype
$ file --mime-type googlelogo_color_272x92dp.png
googlelogo_color_272x92dp.png: image/png
# but xdg-mime query filetype returns nothing
$ xdg-mime query filetype googlelogo_color_272x92dp.png
```
Is it possible to imagine adding some log debugs ?
Thankshttps://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/180Missing parameter in set_url_scheme_handler_gnome3?2021-05-04T01:47:55ZargenosMissing parameter in set_url_scheme_handler_gnome3?I've been down a small rabbit hole, trying to figure out why [some electron apps set themselves as the default `text/html` application](https://github.com/electron/electron/issues/20382#issuecomment-537627348).
Based on what I've learned...I've been down a small rabbit hole, trying to figure out why [some electron apps set themselves as the default `text/html` application](https://github.com/electron/electron/issues/20382#issuecomment-537627348).
Based on what I've learned, it seems that they're using `xdg-utils` to set up custom URL protocols.
Could it be that the issue is that on this [line](https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L691), it passes no 2nd param the first time, which defaults to `text/html`? See [this](https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-settings.in#L134) too.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/181xdg-email is not working with attachments2021-01-09T21:54:46ZTobias Lindigxdg-email is not working with attachmentsthis open only a e-mail dialog without the attachment:
``` sh
xdg-email --attach $HOME/.bash_history
```
That works fine, attachment is in the opened e-mail dialog:
``` sh
thunderbird -compose attachment="file:///$HOME/.bash_history"
`...this open only a e-mail dialog without the attachment:
``` sh
xdg-email --attach $HOME/.bash_history
```
That works fine, attachment is in the opened e-mail dialog:
``` sh
thunderbird -compose attachment="file:///$HOME/.bash_history"
```
Seams to be also the cause for issues, that "Send as e-mail" in Nemo or other programs do not work.
see also here: https://github.com/Foundry376/Mailspring/issues/1804
My system is: Linux Mint 20 with xdg-email 1.1.3 and Thunderbird 68.10.0
(Kernel: 5.8.0-33-generic x86_64 bits: 64; Desktop: Cinnamon 4.6.7; Distro: Linux Mint 20 Ulyana; base: Ubuntu 20.04 focal)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/185xdg-open breaks when trying to open hyphen-prefixed files.2023-08-09T03:12:34ZSamuel Hunterxdg-open breaks when trying to open hyphen-prefixed files.Valid file names may include a hyphen `-` at the start. `xdg-open` mistakes these types of files to be a flag, giving an error:
```
$ mv -- example.png -example.png
$ xdg-open -example.png
xdg-mime: unexpected option '-example.png'
Try ...Valid file names may include a hyphen `-` at the start. `xdg-open` mistakes these types of files to be a flag, giving an error:
```
$ mv -- example.png -example.png
$ xdg-open -example.png
xdg-mime: unexpected option '-example.png'
Try 'xdg-mime --help' for more information.
xdg-open: unexpected option '-example.png'
Try 'xdg-open --help' for more information.
```
Sane file-accepting CLI's use `--` to stop parsing flags and parse all following arguments as files, even if they look like flags. Neither `xdg-open` nor `xdg-mime` support this convention:
```
$ xdg-mime query filetype -- -example.png
xdg-mime: unexpected option '--'
Try 'xdg-mime --help' for more information.
$ xdg-open -- -example.png
xdg-mime: unexpected option '-example.png'
Try 'xdg-mime --help' for more information.
xdg-open: unexpected option '-example.png'
Try 'xdg-open --help' for more information.
```
The current workaround is "don't do that" and keep all files from looking like flags. The better long-term solution would be to add support for `--` to stop parsing flags and instead unconditionally parse the next argument as a file.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/186xdg-screensaver does not recognize xfce4-screensaver2023-08-09T03:11:54ZJarno Sunixdg-screensaver does not recognize xfce4-screensaverxfce4-screensaver should be used, if the daemon is running.
This test seems to detect it:
`dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.xfce.ScreenSaver`xfce4-screensaver should be used, if the daemon is running.
This test seems to detect it:
`dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.xfce.ScreenSaver`https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/188xdg-settings set default-web-browser on XFCE4 doesn't change mimeapps.list2023-08-09T03:11:05ZYuwei Huangxdg-settings set default-web-browser on XFCE4 doesn't change mimeapps.listIt appears that running `xdg-settings set default-web-browser` only changes `WebBrowser` in `~/.config/xfce4/helpers.rc` and it doesn't change `~/.config/mimeapps.list`. The problem is that some apps stubbornly use the URL scheme handler...It appears that running `xdg-settings set default-web-browser` only changes `WebBrowser` in `~/.config/xfce4/helpers.rc` and it doesn't change `~/.config/mimeapps.list`. The problem is that some apps stubbornly use the URL scheme handlers in the `[Default Applications]` section of mimeapps.list, e.g. `gio open http://google.com`.
The `Settings > Default Applications` app in the XFCE desktop will change the default browser for `x-scheme-handler/http` and `x-scheme-handler/https` in both `[Default Applications]` and `[Added Associations]` in the mimeapps.list file to `xfce4-web-browser.desktop`, in addition to changing the helpers.rc file, so I guess xdg-settings may want to do the same thing for XFCE.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/189xdg-open does not obey .desktop file spec re: spaces surrounding equals2023-08-09T03:09:00ZScott Mcdermottxdg-open does not obey .desktop file spec re: spaces surrounding equalsdespite the freedesktop [desktop entry specification](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) saying we can surround `=` with spaces in desktop files:
> space before and after the equals...despite the freedesktop [desktop entry specification](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) saying we can surround `=` with spaces in desktop files:
> space before and after the equals sign should be ignored
this doesn't work because xdg-open, in `binary_to_desktop_file()` does
```
grep -E "^Exec(\[[^]=]*])?=" "$file"
```
which does not properly match an equals sign with spaces surrounding it. It means we cannot align columns in .desktop file. Whitespace should be ignored before and after the `=` until the first/last non-whitespace character, at which point whitespace becomes significant.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/190xdg-open open_generic timeout for testing out different browser2023-08-31T05:11:17ZLutz Fischerxdg-open open_generic timeout for testing out different browserWhen xdg-open uses open_generic it tries out different browsers by simply checking if the previous execution failed.
usually this is fine, but what I find annoying is, that it also happens when I for some reason kill the web-browser at s...When xdg-open uses open_generic it tries out different browsers by simply checking if the previous execution failed.
usually this is fine, but what I find annoying is, that it also happens when I for some reason kill the web-browser at some point. E.g. it opens firefox and after a day (i.e. I ssh into my computer and need to free some memory - so I kill firefox) I kill it -then xdg-open assumes that firefox is not the right application and tries the next possible browser.
I would prefer if a form of time out exists. Meaning if the application tried crashed after e.g. more then 60 seconds don't assume it failed to pick the right application but accept that an actual crash of some kind happened.
I attached a patch that introduces a 60 seconds time out: [crash_timeout.patch](/uploads/df7ee834938b7787611b0dd976378c40/crash_timeout.patch)https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/194"mkdir: cannot create directory ‘/applications-merged’: Permission denied" on...2023-09-24T21:19:33ZFrederic Bezies"mkdir: cannot create directory ‘/applications-merged’: Permission denied" on some packages with Archlinux.Hello.
I'm maintaining vice-svn PKGBUILD on AUR for Archlinux ( https://aur.archlinux.org/packages/vice-svn/ ), and I noticed it is impossible to manage desktop file generation with xdg-utils from Archlinux. ( https://archlinux.org/pack...Hello.
I'm maintaining vice-svn PKGBUILD on AUR for Archlinux ( https://aur.archlinux.org/packages/vice-svn/ ), and I noticed it is impossible to manage desktop file generation with xdg-utils from Archlinux. ( https://archlinux.org/packages/extra/any/xdg-utils/ )
When I enabled desktop file configuration, I got this error log:
```
make[8]: Entering directory '/build/vice-svn/src/vice-svn/vice/src/arch/gtk3/data/unix'
xdg-desktop-menu install "../../../../../src/arch/gtk3/data/unix/vice-org-vice-org.directory" ../../../../../src/arch/gtk3/data/unix/vice-org-x64sc.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-x64dtv.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-xscpu64.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-x128.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-xvic.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-xplus4.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-xpet.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-xcbm5x0.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-xcbm2.desktop ../../../../../src/arch/gtk3/data/unix/vice-org-vsid.desktop
mkdir: cannot create directory ‘/applications-merged’: Permission denied
xdg-desktop-menu: No writable system menu directory found.
make[8]: *** [Makefile:746: install-data-hook] Error 3
make[8]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src/arch/gtk3/data/unix'
make[7]: *** [Makefile:564: install-data-am] Error 2
make[7]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src/arch/gtk3/data/unix'
make[6]: *** [Makefile:511: install-am] Error 2
make[6]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src/arch/gtk3/data/unix'
make[5]: *** [Makefile:476: install-recursive] Error 1
make[5]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src/arch/gtk3/data'
make[4]: *** [Makefile:845: install-recursive] Error 1
make[4]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src/arch/gtk3'
make[3]: *** [Makefile:475: install-recursive] Error 1
make[3]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src/arch'
make[2]: *** [Makefile:1894: install-recursive] Error 1
make[2]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src'
make[1]: *** [Makefile:2053: install] Error 2
make[1]: Leaving directory '/build/vice-svn/src/vice-svn/vice/src'
make: *** [Makefile:525: install-recursive] Error 1
==> ERROR: A failure occurred in package().
```
I tried with both Fedora 34 and Debian GNU/Linux 11.1 and packaging worked.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/195xdg-mime priorities /usr/share//applications/mimeinfo.cache over $HOME/.confi...2023-09-24T20:19:41Zklenzexdg-mime priorities /usr/share//applications/mimeinfo.cache over $HOME/.config/mimeapps.list$ grep -i application/pdf /usr/share//applications/mimeinfo.cache $HOME/.config/mimeapps.list
/usr/share//applications/mimeinfo.cache:application/pdf=gimp.desktop;inkscape.desktop;calibre-gui.desktop;krita_pdf.desktop;xpdf.desktop;libr...$ grep -i application/pdf /usr/share//applications/mimeinfo.cache $HOME/.config/mimeapps.list
/usr/share//applications/mimeinfo.cache:application/pdf=gimp.desktop;inkscape.desktop;calibre-gui.desktop;krita_pdf.desktop;xpdf.desktop;libreoffice-draw.desktop;okularApplication_pdf.desktop;org.gnome.Evince.desktop;calibre-ebook-viewer.desktop;
/home/username/.config/mimeapps.list:application/pdf=okularApplication_pdf.desktop;
$ Checking /home/username/.config/mimeapps.list
Checking /home/username/.local/share/applications/defaults.list and /home/username/.local/share/applications/mimeinfo.cache
Checking /home/username/.local/share/applications/defaults.list and /home/username/.local/share/applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and /usr/local/share//applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and /usr/local/share//applications/mimeinfo.cache
Checking /usr/share//applications/defaults.list and /usr/share//applications/mimeinfo.cache
gimp.desktop
Afer manually removing the offensive line in /usr/share//applications/mimeinfo.cache
(# for comment does not work):
$ xdg-mime query default application/pdf
okularApplication_pdf.desktop
Aside from the fact that opening pdf files with gimp is about as enlightening as viewing pngs with hexdump (there is a world of a difference between "I can somehow import try to import $format" and "I am a good default choice for $format", which does not seem to be reflected in the *.desktop files?), my main issue here is the the global config file seems to override the user config file, when it should be the other way round. (as mimeopen does).
$ env | grep XDG
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=lightdm-xsession
XDG_SESSION_TYPE=x11
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/username
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_VTNR=7
XDG_SESSION_ID=4
XDG_RUNTIME_DIR=/run/user/1000
$ xdg-mime --version
xdg-mime 1.1.3
I am running Debian 10 buster on x86_64 with wmaker as DE, if any of that is relevant.
As a workaround making $HOME/.local/share/applications/mimeinfo.cache a symlink to $HOME/.config/mimeapps.list does the job, at least until some program helpfully opens the cache with O_TRUNC, so better make a backup first.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/197xdg-tools doesn't comply to standards itself. No error when there is no icon.2021-12-01T10:54:05Zavlapxdg-tools doesn't comply to standards itself. No error when there is no icon.xdg-icon-resource uninstall doesn't give any feedback when the icon does not exist. I know silence is golden, but not when there is a error I would think and you would think that a tool that is designed to make people and distributions f...xdg-icon-resource uninstall doesn't give any feedback when the icon does not exist. I know silence is golden, but not when there is a error I would think and you would think that a tool that is designed to make people and distributions follow rules, would follow normal Unix rules itself.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/198xdg-desktop-menu is not doing it right, or the documentation lacks.2021-12-01T12:04:36Zavlapxdg-desktop-menu is not doing it right, or the documentation lacks. I'm confused by the xdg-tools, like xdg-desktop-menu. It seems to install to /usr/share/applications by default. But sometimes this should be /usr/local/share one would think according to Linux standards.
Then there is also desktop-fil... I'm confused by the xdg-tools, like xdg-desktop-menu. It seems to install to /usr/share/applications by default. But sometimes this should be /usr/local/share one would think according to Linux standards.
Then there is also desktop-file-install, which can specify a DIR. It's not clear why there are two tools and which one to use when. So at least lack of documentation or clarity in the manpages I think.
Due to this, at least Processing and Arduino are now installing *.desktop files to /usr/share/applications, but that should be /usr/local/share I would think.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/204/usr/bin/xdg-mime: line 323: [: too many arguments2023-10-11T20:30:03ZMichael Catanzaro/usr/bin/xdg-mime: line 323: [: too many argumentsUsing xdg-utils-1.1.3-11.fc36:
```
$ xdg-mime query default 'text/plain'
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/x...Using xdg-utils-1.1.3-11.fc36:
```
$ xdg-mime query default 'text/plain'
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
/usr/bin/xdg-mime: line 323: [: too many arguments
/usr/bin/xdg-mime: line 325: [: too many arguments
org.gnome.TextEditor.desktop
```
No clue why it doesn't like this code:
```
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
```https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/205xdg-email does not parse mailto uris properly for thunderbird2023-10-14T12:33:17ZMarco Kühnelxdg-email does not parse mailto uris properly for thunderbirdWhen using thunderbird as mailto handler xdg-email translates mailto uris into an 'thunderbird -compose' argument. While to, cc and bcc values are properly enclosed in single quotes this is not the case for subject or body. This breaks f...When using thunderbird as mailto handler xdg-email translates mailto uris into an 'thunderbird -compose' argument. While to, cc and bcc values are properly enclosed in single quotes this is not the case for subject or body. This breaks functionality and allows to use all thunderbird -compose arguments within a mailto uri, e.g.
<code>xdg-email 'mailto:test@example.com?subject=Test,attachment=~/.thunderbird/profiles.ini,message=/home/test/test.txt'</code>
translates into
<code>thunderbird -compose to='test@example.com,',subject=Test,attachment=~/.thunderbird/profiles.ini,message=/home/test/test.txt</code>
with working attachment and message. (And, yes, ~ expands to the home directory.)
This is different from <a href="https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177">Issue 177</a> where the handling of attachments is intended. Here it is not.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/210The XDG desktop file spec alludes to Directory as a Type of desktop file but ...2023-08-09T01:55:24ZJacob GustafsonThe XDG desktop file spec alludes to Directory as a Type of desktop file but doesn't define a standard for it.I didn't hear back from the mailing list about this:
> . . . The website said discussions about XDG should take place on this mailing list. I hope this is the best place for the technical issue below, since the issue involves the standa...I didn't hear back from the mailing list about this:
> . . . The website said discussions about XDG should take place on this mailing list. I hope this is the best place for the technical issue below, since the issue involves the standard itself rather than the software, which seems to implement the standard as the standard stands, from my tests regarding this issue (using desktop-file-validate).
>
> The standard itself is missing a definition of what key is appropriate for the path where the Type is Directory. In fact, there doesn't seem to be any specification of the Directory type in the XDG standard other than that the extension should be ".directory". In fact, there seems to be no way to construct such a file in a way that desktop-file-validate doesn't show an error.
>
> May I propose "Path" could be the key in this case? It seems intuitive.
This may be helpful since existing software expects "Exec" to be an executable command. However, Type=Directory (or Type=File) might be enough to make Exec's meaning clear if it is not a command.
>
> It may also pave the way for a "File" Type implemented similarly. I suggest adding that.
>
> I have had several uses for such a feature so I implemented these features in an alternative standard called blnk. If XDG implements the features, I would change my program to match the standard. The use cases are as follows:
> - I (and various tech channels on YouTube) often install GNU/Linux systems on old/new computers for relatives to avoid various Windows issues. Such users don't understand symlinks. Even Mac users don't usually understand aliases (which they are called there and made easy to create like on Ubuntu) from what I've seen. They sometimes delete all of the files from one symlinked directory since they think there are two copies of everything. Having a shortcut that goes to the "real" directory is preferable and safer in this case.
> - In another case, the directory shortcut can point to a location that may not always exist. Even some favorite bars or programs simply "forget" (or hide) a subdirectory of an unmounted drive or remote host upon loading. This is not clear to the user what is going on. They may wonder where the shortcut went or what is happening. If there was a complete .directory file standard, then DEs (maybe via xdg-launch or some new xdg command that doesn't depend on mimetype) could launch the file and stderr could say that the Directory is missing or not accessible. The current workaround is to make an Application shortcut to a directory, but this is not always advisable. I've heard recommendations online saying to launch some particular file browser, whereas xdg-launch would be better. If the .directory spec were completed then implemented be DEs, there would be a clear answer to the question and there wouldn't have to be workarounds or handwritten .desktop files.
> - Perhaps DEs could implement following .desktop files in a similar way to symlinks: to traverse folders while inside of a file/directory chooser dialog box even. That feature is implemented on Windows, for example. That would allow people to have shortcuts in an appropriate place instead of an ever-growing "Favorites" bar in their file manager. Also, the favorites bar gets reset to nothing upon changing to a different DE or upon running a different flatpak.
(In other words: Even if both flatpaks use ~/.config/gtk-3.0/bookmarks, the sandboxing makes every program start with its own blank list unless that is worked around by adding that as accessible to the flatpak such as using Flatseal)
> I understand these issues are not the realm of XDG to implement, but having some sort of complete specification for Type=Directory
(and for Type=File as suggested maybe)
> would allow DEs to do whatever they want with it and have a clear way to remain compatible with other DEs in this regard, regardless of whether their implementation involves my wishlist.https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/213xdg-open launches desktop entries in text editor2023-08-11T20:20:50ZAvid Seekerxdg-open launches desktop entries in text editorcat shortcut.desktop:
```
[Desktop Entry]
Comment[en_US]=
Comment=
Exec=/usr/bin/konsole
GenericName[en_US]=
GenericName=
Icon=system-run
MimeType=
Name[en_US]=Link to Application
Name=Link to Application
Path=
StartupNotify=true
Termina...cat shortcut.desktop:
```
[Desktop Entry]
Comment[en_US]=
Comment=
Exec=/usr/bin/konsole
GenericName[en_US]=
GenericName=
Icon=system-run
MimeType=
Name[en_US]=Link to Application
Name=Link to Application
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=
```
Trying `xdg-open shortcut.desktop` results in opening it in default text editor.
Also there isn't any support for type 'Link':
```
[Desktop Entry]
Icon=inode-directory
Name=new
Type=Link
URL[$e]=file:///mnt
```https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/215xdg-desktop-menu.xml does not validate2023-02-21T14:01:58Zkiki Shaoxdg-desktop-menu.xml does not validatewhen I make the file, the following bug is reported, How can I fix it?
(cd html;/opt/homebrew/bin/xmlto html-nochunks ../desc/xdg-desktop-menu.xml)
xmlto: /Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml does not vali...when I make the file, the following bug is reported, How can I fix it?
(cd html;/opt/homebrew/bin/xmlto html-nochunks ../desc/xdg-desktop-menu.xml)
xmlto: /Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml does not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd
/Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml:6: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
]>
^
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd
warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
validity error : Could not load the external subset "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
Document /Users/shaokiki/xdg-utils/scripts/html/../desc/xdg-desktop-menu.xml does not validate
make[1]: *** [html/xdg-desktop-menu.html] Error 13
make: *** [scripts] Error 2https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/216Opening Office files in MS Office (running under Wine) via a double click lea...2023-08-09T10:57:02Zlorn10Opening Office files in MS Office (running under Wine) via a double click leads to a blank documentHi all
Here follows a bug report about a strange behavior in opening Office documents in Linux under Microsoft Office 2010 and Wine.
When a Word, Excel, or whatever Office file (even OpenDocument) is opened via a doubleclick, a blank d...Hi all
Here follows a bug report about a strange behavior in opening Office documents in Linux under Microsoft Office 2010 and Wine.
When a Word, Excel, or whatever Office file (even OpenDocument) is opened via a doubleclick, a blank document is shown.
Interestingly this does not occur when the corresponding file is opened via a right click and "Open With". In that case, the file is displayed correctly.
I have observed that behavior for a long time with MS Office 2010 (and Wine) but until now it was unclear where the problem comes from. After reading the following Linux question on reddit, [docx Files leads to a blank Document in Microsoft Office (Wine)](https://www.reddit.com/r/linuxquestions/comments/qyxkpf/docx_files_leads_to_a_blank_document_in_microsoft/) there exist a high chance that the problem is located in `xdg-open` which is part of `xdg-utils`.
More information can be found also at Wine bug report 54628, [Opening files in Microsoft Word/Excel/Office 2010 results in opening an empty document](https://bugs.winehq.org/show_bug.cgi?id=54628).
### System information
`inxi -b` output:
```
System:
Host: test-iMac Kernel: 5.15.0-78-generic x86_64 bits: 64
Desktop: KDE Plasma 5.24.7 Distro: Ubuntu 22.04.3 LTS (Jammy Jellyfish)
Machine:
Type: Desktop System: Apple product: iMac12,2 v: 1.0
serial: <superuser required>
Mobo: Apple model: Mac-942B59F58194171B v: iMac12,2
serial: <superuser required> UEFI: Apple v: IM121.88Z.0047.B1F.1201241648
date: 01/24/12
CPU:
Info: quad core Intel Core i5-2500S [MCP] speed (MHz): avg: 1596
min/max: 1600/3700
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
driver: i915 v: kernel
Device-2: AMD Whistler [Radeon HD 6730M/6770M/7690M XT] driver: radeon
v: kernel
Device-3: Apple FaceTime HD Camera (Built-in) type: USB driver: uvcvideo
Display: x11 server: X.Org v: 1.21.1.4 driver: X:
loaded: ati,modesetting,radeon unloaded: fbdev,vesa gpu: radeon
resolution: 2560x1440~60Hz
OpenGL: renderer: AMD TURKS (DRM 2.50.0 / 5.15.0-78-generic LLVM 15.0.7)
v: 4.5 Mesa 23.3~git2308080600.475527~oibaf~j (git-4755276 2023-08-08
jammy-oibaf-ppa)
Network:
Device-1: Broadcom NetXtreme BCM57765 Gigabit Ethernet PCIe driver: tg3
Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k
Drives:
Local Storage: total: 931.51 GiB used: 152.75 GiB (16.4%)
Info:
Processes: 223 Uptime: 1d 2h 49m Memory: 7.73 GiB used: 2.32 GiB (30.0%)
Shell: Bash inxi: 3.3.13
```https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/217xdg-settings man page: document how to show all it knows2023-10-09T00:50:43Z積丹尼 Dan Jacobsonxdg-settings man page: document how to show all it knowsOn the xdg-settings man page, perhaps mention
how to dump all that it knows:
```
$ xdg-settings --list|perl -wnle 'print $1 if /^\s+(\S+)/'|xargs -n 1 --verbose xdg-settings get
xdg-settings get default-url-scheme-handler
xdg-settings ge...On the xdg-settings man page, perhaps mention
how to dump all that it knows:
```
$ xdg-settings --list|perl -wnle 'print $1 if /^\s+(\S+)/'|xargs -n 1 --verbose xdg-settings get
xdg-settings get default-url-scheme-handler
xdg-settings get default-web-browser
google-chrome-unstable.desktop
```https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/218xdg-mime man page: show how to query all2023-10-09T00:50:50Z積丹尼 Dan Jacobsonxdg-mime man page: show how to query allThe xdg-mime man page has an example,
`xdg-mime query default image/png`
That great. But also show how to get it to show
all the all the types it knows about. Not just one.
I.e., sure, the telephone company's directory assistance oper...The xdg-mime man page has an example,
`xdg-mime query default image/png`
That great. But also show how to get it to show
all the all the types it knows about. Not just one.
I.e., sure, the telephone company's directory assistance operator will tell you Bill Norbetston's phone number. But I also sometimes want to see the whole phone book please.