GNOME Bugzilla – Bug 586825
metacity working directory is /
Last modified: 2011-07-13 13:43:35 UTC
Please describe the problem: Metacity's pwd appears to be /. This means starting an application from the shortcut system (e.g. gnome-terminal) will start in / instead of ~, which seems like a better idea. Steps to reproduce: 1. Go into keyboard shortcuts 2. Assign a new command 'gnome-terminal' and bind it to a shortcut key 3. Run the shortcut Actual results: Gnome terminal starts in / Expected results: Gnome terminal starts in ~ Does this happen every time? Yes Other information: Running a command like 'bash -c 'env>~/envout'' also shows that the PWD variable is set to /
Actually metacity chdir()s to $HOME in main (bug 113755). Does xterm also start in / if started via keybinding? g-t has some extra complications that may make it start in / .
Yes, xterm also starts in / I wrote a quick program: #include <glib.h> #include <stdio.h> void main() { FILE *fp = fopen("/tmp/homedetails", "w"); fprintf(fp, "home dir: %s\n", g_get_home_dir ()); fprintf(fp,"current dir: %s\n", g_get_current_dir ()); fclose(fp); } and it writes output: home dir: /home/alastair current dir: /
Created attachment 166939 [details] [review] Call g_spawn_async() with g_get_home_dir()
Actually, the program that starts such commands is gnome-settings-daemon. On start, it chdir("/") while dæmonizing. In addition, in plugins/keybindings/gsd-keybindings-manager.c, function keybindings_filter(), the external command is started using GSD's current directory because g_spawn_async() is given NULL for its first argument. As a result, external commands have a working directory of /. The attached trivial patch corrects that. (made against openSUSE's version of g-s-d 2.30.1) A quick grep for "g_spawn" doesn't show anything that need correcting in this respect (gsd-media-keys-manager.c:execute() already call g_get_homedir, the other uses are for internal utilities). Since (AIUI, I may be wrong) g-s-d is started early, it does not inherit the environment from the rest of GNOME. In particular, $SSH_AUTH_SOCK is not set. So, doing this covers only one part of the underlining issue: the entire environment should be copied.
(In reply to comment #4) > Actually, the program that starts such commands is gnome-settings-daemon. g-s-d listens for the hot key and spawns gnome-terminal? What makes you say that? I'm pretty sure it's done by handle_run_command() in src/core/keybindings.c. Also, if this is a patch against g-s-d, this bug should be reassigned to g-s-d, so its maintainers can review it.
> g-s-d listens for the hot key and spawns gnome-terminal? What makes you say that? The following experiment : apply the attached patch to gnome-settings-daemon, (compile, log out and back in), stick the following in $HOME/bin/showenv: #!/bin/sh zenity --info --text="`env|sort` " Then start gnome-keybindings-property, attach a key to $HOME/bin/showenv, and press it. Here, I see (amongst the rest of the environment variables) PWD=/ and CALLED_FROM=gsd-keybindings-manager. > Also, if this is a patch against g-s-d, this bug should be reassigned to g-s-d, so its maintainers can review it. Surely; I don't know how to do that. Can you do it if that's the right thing? (and also bump the version number of the affected product, and the "UNCONFIRMED" status).
Created attachment 167062 [details] [review] Add environment variables for tracing
Reassigning to g-s-d, then.
I hit this too. See: https://bugzilla.redhat.com/682881 The fact that the shell isn't getting $SSH_AUTH_SOCK from gnome-keyring-daemon is what alerted me to it
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 582436 ***