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.
This is nearly fixed with 2c655ce
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.
Created attachment 3673
stops exo-open from open popups
Stops exo-open from open opening popups if it fails to parse a URI correctly.
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 $?
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);
exo_argv, NULL, G_SPAWN_SEARCH_PATH,
xfrun_spawn_child_setup, 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.)
Turns out: gdk_spawn_on_screen ignores the exit code completely
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 .
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.
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
For convenience I pushed the patch to github:
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.
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.
Think to original problem is resolved with the commits in git.