It’s not meant to be exposed publicly yet (we’re not ready to stabilise
it), but it was incorrectly decorated with `GLIB_AVAILABLE_IN_2_76`.
We can’t remove the decorator and use it that way, as it’s called in
libgio, so we have to expose it using `GLIB_PRIVATE_CALL()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2876
`search_token` cannot be `NULL` at this point (guaranteed by all the
current call sites of `desktop_file_dir_unindexed_search()`), so remove
an unnecessary `NULL` check.
Add an assertion to make the nullability clear.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1502196, #1502193
Substring matches can have too much unwanted results, while prefix
matches is more accurate but cannot handle some special cases, this
commit combines them by adding a match_type member, then sort and group
result with both categories and match types.
For the same category, prefix matched results will be put in the first
group and substring matched results will be put in the second group.
GDesktopAppInfo never failed in the most simple of the cases: when a
desktop file or a command line app info was pointing to an invalid
executable (for the context).
The reason for this is that we're launching all the programs using
gio-launch-desktop which will always exist in a sane GLib installation,
and thus our call to execvp won't ever fail on failure.
This was partially mitigated by not allowing to create a desktop app
icon using a non-existent executable (even if not fully correctly) but
still did not work in case a custom PATH was provided in the launch
context.
To avoid this, use g_find_program_for_path() to find early if a program
that we're about to launch is available, and if it's not the case return
the same error that g_spawn_async_with_fds() would throw in such cases.
While this is slowing a bit our preparation phase, would avoid to leave
to the exec function the job to find where our program is.
Add tests simulating this behavior.
We used to launch applications with terminals using the normal program
finder logic that did not consider the context path nor the desktop file
working dir. Switch to g_find_program_for_path() to find terminals so we
can ensure that both conditions are true.
Update tests to consider this case too.
Introduce support for terminals executing commands without an option,
i.e., the command is passed directly as argument to the terminal emulator.
This is needed for xdg-terminal-exec.
Get rid of multiple conditionals branch by using a loop and storing the
options needed by particular terminal emulators directly in an array.
Remove intermediate variable term_argv as we don't need it.
Advantages:
- simpler logic, less branching
- the terminal emulator list is more readable, by virtue of being
condensed in one array. Launch options to execute a terminal program
are also more explicitly specified
- the logic become independent from the order
- one less allocation
On our GDBus call callback wrapper we were completing the gdbus call but
ignoring the returned value, that was always leaked.
Fix this.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/333
When launching URIs via dbus we may ignore the callback if one was not
provided, however in such case we were also leaking the return value for
the gdbus call.
Unref it properly.
Helps with: https://gitlab.gnome.org/GNOME/glib/-/issues/333
The search_total_results address is always going to be non-zero, so the
check will always evaluate to true, and GCC is kind enough to point this
out to us.
The appropriate fix is checking if the size of the search results array
is larger than zero, and if so, copy them into the total results array.
* Remove an unneeded field from LaunchUrisData and add annotations
* Rename local GError* variables to local_error
* Use g_set_object
* Fix indentation
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).
When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.
When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gio-launch-desktop was removed before checking GIO for potentially
unsafe environment variable references, so reverting its removal brought
this one back. If a setuid program is using GAppInfo then something is
probably already horribly wrong, but let's be careful anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A shell one-liner was enough to set GIO_LAUNCHED_DESKTOP_FILE_PID,
but ideally we also want to do the equivalent of sd_journal_stream_fd()
to set up its standard output and standard error streams.
Ideally we would call sd_journal_stream_fd() in a process that will
exec the real program, otherwise it will report the wrong process ID
in the Journal, but we can't easily do that in a forked child when
using posix_spawn() for subprocesses.
This reverts commit 2b533ca99a.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In some cases (such as in our CI tests) we may not have any dbus session
set after launching, but we always assumed so.
In case we have not a session bus set, we only have to return early.
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
There shouldn’t be any issues here with empty argv arrays since an empty
`Exec=` line is already checked for. Encode that explicitly with an
assertion.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Specs say that on Unix id should be desktop file id from the xdg menu
specification, however, currently code just uses basename of .desktop file.
Fix that by finding the .desktop file in all the desktop_file_dirs and use
basename only as a fallback.
See https://specifications.freedesktop.org/menu-spec/latest/go01.html#term-desktop-file-id
and https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id
"To determine the ID of a desktop file, make its full path relative to the
$XDG_DATA_DIRS component in which the desktop file is installed, remove the
"applications/" prefix, and turn '/' into '-'."
Also, add unit test that verifies Desktop Id is being correctly set
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Emit this when we're about to spawn or DBus activate a GAppInfo. This
allows lauchers to keep the appinfo associated with a startup id.
We use a GVariant to allow for future exansion of the supplied data.
When using g_desktop_app_info_launch_uris_as_manager the "launched"
signal allows to map a desktop-startup-id to a GAppInfo. Make this
possible for DBus activation too.
Since we don't have a PID there we pass a 0. Update the signal
description accordingly.
Instead of calling xterm when it clearly does not exist and causes a silent error,
inform the user that the launch failed so they can take the right action.
On Unix platforms, wait() and friends yield an integer that encodes
how the process exited. Confusingly, this is usually not the same as
the integer passed to exit() or returned from main(): conceptually it's
an integer encoding of this tagged union:
enum { EXITED, SIGNALLED, ... } tag;
union {
int exit_status; /* if EXITED */
struct {
int terminating_signal;
bool core_dumped;
} terminating_signal; /* if SIGNALLED */
...
} detail;
Meanwhile, on Windows, wait statuses and exit statuses are
interchangeable.
I find that it's clearer what is going on if we are consistent about
referring to the result of wait() as a "wait status", and the value
passed to exit() as an "exit status".
GSubprocess already gets this right: g_subprocess_get_status() returns
the wait status, while g_subprocess_get_exit_status() genuinely returns
the exit status. However, the GSpawn family of APIs has tended to
conflate the two.
Confusingly, g_spawn_check_exit_status() has always checked a wait
status, and it would not be correct to pass an exit status to it; so
let's deprecate it in favour of g_spawn_check_wait_status(), which
does the same thing that g_spawn_check_exit_status() always did.
Code that needs backwards-compatibility with older GLib can use:
#if !GLIB_CHECK_VERSION(2, 69, 0)
#define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
#endif
Signed-off-by: Simon McVittie <smcv@collabora.com>
gio/gdesktopappinfo.c: In function ‘g_app_info_get_all’:
gio/gdesktopappinfo.c:4597:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
4597 | for (i = 0; i < desktop_file_dirs->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘g_desktop_app_info_search’:
gio/gdesktopappinfo.c:4517:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
4517 | for (i = 0; i < desktop_file_dirs->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘g_desktop_app_info_get_implementations’:
gio/gdesktopappinfo.c:4451:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
4451 | for (i = 0; i < desktop_file_dirs->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘g_desktop_app_info_get_desktop_ids_for_content_type’:
gio/gdesktopappinfo.c:4154:19: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
4154 | for (j = 0; j < desktop_file_dirs->len; j++)
| ^
gio/gdesktopappinfo.c:4158:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’} [-Werror=sign-compare]
4158 | for (i = 0; i < hits->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘get_list_of_mimetypes’:
gio/gdesktopappinfo.c:4116:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
4116 | for (i = 0; i < array->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘g_desktop_app_info_launch_uris_with_spawn’:
gio/gdesktopappinfo.c:2804:21: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
2804 | for (i = 0; i < G_N_ELEMENTS (wrapper_argv); i++)
| ^
gio/gdesktopappinfo.c: In function ‘desktop_file_dirs_lock’:
gio/gdesktopappinfo.c:1564:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1564 | for (i = 0; i < desktop_file_dirs->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘array_contains’:
gio/gdesktopappinfo.c:1193:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1193 | for (i = 0; i < array->len; i++)
| ^
gio/gdesktopappinfo.c: In function ‘desktop_file_dir_unindexed_setup_search’:
gio/gdesktopappinfo.c:1114:25: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
1114 | for (i = 0; i < G_N_ELEMENTS (desktop_key_match_category); i++)
| ^
Split out XDG_CURRENT_DESKTOP handling to a separate function and make
sure that it drops all the invalid entries properly. Earlier a bad
entry could slip through the checks by sitting just after another bad
entry, like in env being set to `invalid1!:invalid2!`, where
`invalid2!` could slip the checks.
Its components are used to build filenames, so if the value of
`XDG_CURRENT_DESKTOP` comes from an untrusted caller (as can happen in
setuid programs), using it unvalidated may be unsafe.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2168
