! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Programs that don't exist are sent as URLs to the browser
Very Low


Description xfce 2011-01-29 04:03:21 CET
Since upgrading to 4.8, entering a program name that does not exist in xfrun4 opens whatever I entered in the browser; I assume this is expected behavior. However, this is not useful in the case of a typoed/nonexistent program, and I find myself regularly directed to shady parking sites or porn in the process.

I'd like to request that this behavior be made an option, or that xfrun4 be more intelligent in determining if what I typed could possibly be a URL.
Comment 1 Hubert Hesse 2011-05-15 02:22:03 CEST
This is nearly fixed with 2c655ce

see https://bugzilla.xfce.org/show_bug.cgi?id=7281

However, now there is another gtk-window besides the normal "failed to execute child process" with claims Unable to detect the URI-scheme of "non-existing programm".

And there is message that the program failed to run.
Comment 2 Hubert Hesse 2011-05-15 02:25:05 CEST
Created attachment 3673 
stops exo-open from open popups

Stops exo-open from open opening popups if it fails to parse a URI correctly.
Comment 3 Hubert Hesse 2011-05-15 03:21:35 CEST
In Comment1: There is *no* message that the programm failed to run.

What I don't understand is:

$ exo-open 'foobar'
Unable to detect the URI-scheme of "adasdasd".
$ echo $?

As expected.

However in xfrun-dialog.c ~line 550

//exo_open = g_strconcat("exo-open ", quoted_cmdline, NULL);
exo_open = "exo-open 'foobar'";
/* Don't handle errors, if any we will display the first one */
g_shell_parse_argv(exo_open, &exo_argc, &exo_argv, NULL);
if(exo_argv) {
        exo_argv, NULL, G_SPAWN_SEARCH_PATH,
        xfrun_spawn_child_setup, NULL, NULL,
        NULL)) {
          exo_opened = TRUE; //this line will always be executed.

As a result the program flow is always the same, as if exo-open was successful .

I don't know why gdk_spawn_on_screen is doing this. Ten lines above this, it works in detecting executing "foobar" fails. The call is the same, except that there is an envp and and error set. (Makes no difference, tested it with them.)
Comment 4 Hubert Hesse 2011-05-15 17:19:40 CEST
Turns out: gdk_spawn_on_screen ignores the exit code completely
Comment 5 Hubert Hesse 2011-05-15 19:34:54 CEST
Created attachment 3674 
use g_spawn_command_line_sync instead of g_spawn_on_screen. Removes code duplication

Use g_spawn_command_line_sync instead of g_spawn_on_screen to determine the exit code of exo-open. Also removes redundant code. Please also apply Attachment 3673 .
Comment 6 Nick Schermer editbugs 2011-05-20 09:56:26 CEST
Patches are not very clean but I get your point. Will take a look at this. I'm thinking about a --quiet option to exo-open, because if it is used by a launcher, the warning is preferred.
Comment 7 Hubert Hesse 2011-06-06 21:51:04 CEST
The current masters' code opens a error dialog if
1.!result & in_term 582-592 in the diff
or 2. !result & !in_term && !exo_opened 570-581

where result = gdk_spawn_on_screen(Program)
in_term = Checkbox(Run in Terminal)
exo_opened = Exo_open(Program)

The patchs' code
1. executes exo-open on !result & in_term 
and then decides wether exo-open was unsuccessful and a error should be displayed. 2. (!result && in_terminal) || exo_exit_code != 0)

However the bugfix is to use g_spawn_command_line_sync to get the exit code of exo-open
Comment 8 Hubert Hesse 2011-06-06 22:02:58 CEST
For convenience I pushed the patch to github:
Comment 9 Jannis Pohlmann editbugs 2011-06-16 00:19:54 CEST
This is pretty annoying and AFAIR, Nick and I agreed that it would be better to handle this error differently; its particularly important to notify the user that his/her command could not be executed.
Comment 10 Nick Schermer editbugs 2011-06-17 20:26:14 CEST
I think I've improved most of this. The synced spawn is not used, but only valid uris and stuff are send to exo-open (so it won't fail anymore, only on crapy uris).

The dialog for failed commands is also removed if gtk >= 2.16 and use the entry icons instead + tooltip.
Comment 11 Nick Schermer editbugs 2011-06-17 20:32:56 CEST
Think to original problem is resolved with the commits in git.

Bug #7200

Reported by:
Reported on: 2011-01-29
Last modified on: 2011-06-17


Nick Schermer
CC List:
4 users



Additional information