GNOME Bugzilla – Bug 707899
Using --disable-factory flag does not start new process when starting gnome-terminal.
Last modified: 2018-07-02 14:40:39 UTC
Overview: There is no visible difference in behaviour of gnome-terminal when starting it with or without --disable-factory flag. Steps to Reproduce: 1) run any terminal 2) enter command: gnome-terminal --disable-factory Actual Results: Factory is not disabled, i.e., no new process for gnome-terminal is spawned. Expected Results: The terminal where gnome-terminal is started should not return to prompt and new process should be spawned in the system. Build Date & Platform: gnome-terminal 3.8.3 on Debian 7.1 gnome-terminal 3.8.4 on Gentoo
There's no bug here; this option is simply not supported anymore. I've changed the client on master and 3-10 to abort when presented with --disable-factory instead of silently using the existing server.
(In reply to comment #1) > There's no bug here; this option is simply not supported anymore. > > I've changed the client on master and 3-10 to abort when presented with > --disable-factory instead of silently using the existing server. I see, but: is there any equivalent of this option in new version of gnome-terminal or is it just no more possible to run terminal in separate process?
There is [see https://wiki.gnome.org/Apps/Terminal/Debugging] but it's only intended for debugging and development of gnome-terminal itself, not for regular use, and there's no guarantee it'll be available in the future.
The initial bug doesn't give a use case, but there *is* one beyond debugging: programs which launch a terminal with text editor or other program, and wait for it to exit. I've seen several reports of programs with this behavior where gnome-terminal can't be used anymore.
(In reply to Matthew Miller from comment #4) > The initial bug doesn't give a use case, but there *is* one beyond > debugging: programs which launch a terminal with text editor or other > program, and wait for it to exit. I've seen several reports of programs with > this behavior where gnome-terminal can't be used anymore. Just for others that end up here for this exact reason, I've worked around this by wrapping gnome-terminal in a script that launches tmux first: https://github.com/jlebon/files/blob/master/bin/gnome-terminal-wrapper Seems cleaner than spawning your own server. I'm sure there are other good solutions out there.
(In reply to Matthew Miller from comment #4) > The initial bug doesn't give a use case, but there *is* one beyond > debugging: programs which launch a terminal with text editor or other > program, and wait for it to exit. I've seen several reports of programs with > this behavior where gnome-terminal can't be used anymore. (In reply to Jonathan Lebon from comment #5) > (In reply to Matthew Miller from comment #4) > > The initial bug doesn't give a use case, but there *is* one beyond > > debugging: programs which launch a terminal with text editor or other > > program, and wait for it to exit. I've seen several reports of programs with > > this behavior where gnome-terminal can't be used anymore. > > Just for others that end up here for this exact reason, I've worked around > this by wrapping gnome-terminal in a script that launches tmux first: > > https://github.com/jlebon/files/blob/master/bin/gnome-terminal-wrapper > > Seems cleaner than spawning your own server. I'm sure there are other good > solutions out there. Since GNOME 3.28 (ie. Fedora 28 and such) gnome-terminal has a --wait option that, I think, does what you want: $ gnome-terminal --wait ... $ gnome-terminal --wait -- emacs -nw ... $