After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 95205 - --working-directory option not working
--working-directory option not working
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
unspecified
Other Linux
: Normal major
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 96077 (view as bug list)
Depends on:
Blocks: 89029
 
 
Reported: 2002-10-08 18:41 UTC by Havoc Pennington
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0


Attachments
patch to fix current-working directory for factory invocations (6.31 KB, patch)
2003-06-21 02:42 UTC, Mariano Suárez-Alvarez
none Details | Review
the 2nd option, which changed the format of the factory call (6.32 KB, patch)
2003-06-23 00:43 UTC, Mariano Suárez-Alvarez
none Details | Review

Description Havoc Pennington 2002-10-08 18:41:18 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
Comment 1 Janne 2002-10-17 14:44:53 UTC
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.
Comment 2 Luis Villa 2002-10-24 20:47:49 UTC
*** Bug 96077 has been marked as a duplicate of this bug. ***
Comment 3 Luis Villa 2002-11-07 19:45:15 UTC
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.
Comment 4 Mariano Suárez-Alvarez 2003-06-21 02:40:27 UTC
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.
Comment 5 Mariano Suárez-Alvarez 2003-06-21 02:42:25 UTC
Created attachment 17672 [details] [review]
patch to fix current-working directory for factory invocations
Comment 6 Havoc Pennington 2003-06-21 02:57:18 UTC
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)? ;-)
Comment 7 Mariano Suárez-Alvarez 2003-06-22 00:58:34 UTC
--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.]
Comment 8 Mariano Suárez-Alvarez 2003-06-23 00:43:56 UTC
Created attachment 17697 [details] [review]
the 2nd option, which changed the format of the factory call
Comment 9 Havoc Pennington 2003-07-13 15:46:12 UTC
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.
Comment 10 Mariano Suárez-Alvarez 2003-07-14 00:20:32 UTC
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) 
Comment 11 Mariano Suárez-Alvarez 2003-10-12 00:12:25 UTC
Commited to HEAD.