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): gnome-core-1.4.0.4-38 How Reproducible: entirely Steps to Reproduce: gnome-terminal --start-factory-server --tclass left & gnome-terminal --use-factory --tclass right & gnome-terminal --use-factory & # in each window: ssh-add -l printenv Actual Results: 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 Expected Results: All windows should act like the first two. Additional Information:
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 option. 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 bug... 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). --jh--
OK, certainly it shouldn't be inconsistent. I filed the bug upstream here: http://bugzilla.gnome.org/show_bug.cgi?id=63030 Going to close it on the Red Hat level since I don't expect to fix it in Red Hat specific patches.