Bug 55064
| Summary: | gnome-terminal factory failures | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Joe Harrington <jhmail> |
| Component: | gnome-core | Assignee: | Havoc Pennington <hp> |
| Status: | CLOSED WONTFIX | QA Contact: | Aaron Brown <abrown> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.2 | CC: | jhmail |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-10-25 19:21:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Joe Harrington
2001-10-25 00:38:54 UTC
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. |