Description of Problem:
Gnome-terminals started with the --use-factory option and not specifying a
class fail, and are replaced by stand-alone windows that do not inherit the
environment or ssh-agent access of either the caller or the program running
in the factory gnome-terminal.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
gnome-terminal --start-factory-server --tclass left &
gnome-terminal --use-factory --tclass right &
gnome-terminal --use-factory &
# in each window:
The process that starts the third window exits, and another takes its
place. Now job control is gone for that window.
The first 2 windows can connect to the agent, the last can't
The user's environment is not fully propagated into the third window
All windows should act like the first two.
I'm pretty sure this is what's supposed to happen; if you --use-factory, then
gnome-terminal simply asks the existing gnome-terminal process to open a new
window and exits, so obviously the new window will not have the environment,
etc. of the shell where you ran the third gnome-terminal. If you want each
gnome-terminal window to be a standalone process, don't use the --use-factory
If I'm misunderstanding the report, please reopen.
Sorry to reopen, but I do think you misunderstand my point...
1. The program does *both* behaviors. If it did one or the other
consistently, you document it and it technically wouldn't be a
2. ...but it would be a gross design error! Even if dropping the
environment were deliberate, gnome-terminal would be the very first
terminal program or shell ever to do so. You're *supposed* to be
able to set configuration variables and get them inherited, and
ssh-agent doesn't work any other way. However, the new windows get
started with a gnome function whose name indicates its intention to
propagate the environment. It occasionally gets blatted to the
calling terminal as an error, but it isn't there now and I can't
make it do it (see below). *Which* environment (the caller's or
the factory's) should get inherited could get argued either way.
I'd say the caller's, and it's quite possible to arrange it that
way. In fact, when it succeeds, that's how it does it: the initial
gt process communicates its environment to the factory and hangs
around for job control.
But wait, the plot unfortunately thickens. Even though it was 100%
reproducible before, I can no longer reproduce the behavior. I have
changed some preferences, including adding a new terminal class, and
everything works as I expect it to now (except window placement with
--geometry, but that's a bug for another day). I have erased
.gnome/Terminal and tried to get it to happen again with a fresh
config file, but it won't. So, it's intermittent, and probably has
something to do with the preference settings. Under at least one
combination, the absence of --tclass in the command line caused the
behavior. The terminal class is in no way related to whether it
starts in a factory or not, and there is no documentation arguing the
contrary (I refer to the Gnome Terminal User's Guide).
So, unless you can reproduce it, we'll have to leave it at that until
someone discovers the combination of preferences that tickles this
bug. I'm dropping the priority and severity, since it probably won't
hurt many people. You can resolve to a worksforme if you want (I
can't do that).
OK, certainly it shouldn't be inconsistent. I filed the bug upstream here:
Going to close it on the Red Hat level since I don't expect to fix it in Red Hat