GNOME Bugzilla – Bug 95205
--working-directory option not working
Last modified: 2004-12-22 21:47:04 UTC
For some reason --working-directory does nothing, with or without --disable-factory. Reported as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75446
Some info: Without --disable-factory, the new terminal always opens up in the users home directory. With disable-factory, it always opens up in the current working directory of the terminal where it was launched. This is version 2.0.1, BTW.
*** Bug 96077 has been marked as a duplicate of this bug. ***
Apologies for the spam- I'm removing 'bugsquad' from some keywords via the web interface. This is a one-time only thing before I re-add bugsquad via the SQL interface, which will generate no mail. Apologies again.
Follows a patch to solve this, zso that gnome-terminal always starts with its current directory as the working directory of the shells it spawns (unless told otherwise, of course) It adds a --default-working-directory option which gives the working directory for all tabs (in all windows described in the command line; having this setting act independently for each window is overkill, IMO) The idea for that is that now, when invoking the factory, we make g-t add the --default-working-directory option set to the cwd of the invoking g-t to the command line to be forwarded, so that the factory can set the wd as needed. Note that we do need a new option because when we parse the cmd line options, --working-directory creates a new tab if none exists so far, and applies only to the most recently created one if tabs do exist (this cannot be changed, because users have those things in their session files, and we don't want to break that). [The patch also fixes a harmless type error which was making gcc complain (a TerminalWindow* which should have been a TerminalScreen*), and changes a getcwd to glib's g_get_current_dir. Not worth opening a bug for that..] I don't know why this bug blocks bug 89029; I have a completely orthogonal fix for that one... Oh well.
Created attachment 17672 [details] [review] patch to fix current-working directory for factory invocations
Does this patch change whether --working-directory works, or does it resolve the second problem mentioned in a comment which is really a separate bug (that --disable-factory affects the default working dir, I guess) i.e. does --working-directory now work? Are you sure you don't want to sign up for a CVS account so you can commit patches yourself (once they are reviewed)? ;-)
--working-directory is working in cvs, and as far as I can remember, was working already as early as 2.0.2... So, hopefully, the patch does not change the behaviour of that option The patch was intended to solve the problem mentioned in the second comment. I have another patch which also solves it, a bit less agressively: instead of adding a command line option (which was rather an ugly (hence bad) idea...), it just packs the working directory as the first argument in the call to the factory. That way the only code affected is the code directly dealing with the factory stuff. And it does not expose one more `internal use' command line options. This does change the format of the args for the new_terminal Bonobo event in a non-backward compatible way, though, and would break every app which uses the gnome-terminal factory... [A third option would be make the parsing of cmd line options depend on whether one is processing a real command line or a factory call.]
Created attachment 17697 [details] [review] the 2nd option, which changed the format of the factory call
I prefer the --default-working-directory patch I think. There will be various weirdnesses caused by breaking the corba interface, and maybe --default-working-directory is useful for manually created launchers anyhow.
Just out of curiosity, is there anyone using terminals through the corba interface? I'd expect the current standard way of starting a terminal would be by querying gconf:/desktop/applications/terminal and exec'ing that (This is sanctified by gnome_execute_terminal_shell and its siblings in libgnome (btw, reading libgnome's code, it appears that gnome_execute_terminal_shell returns the pid of the terminal it execs, but in factory-mode, the process executed by libgnome will have died, so its pid has only historic interest... That's a bug, I guess, in libgnome)
Commited to HEAD.