GNOME Bugzilla – Bug 575184
gnome-terminal fails to get current working directory on Solaris
Last modified: 2012-06-04 21:00:28 UTC
Starting with GNOME 2.25, I have noticed that when you open a new tab in gnome-terminal, it doesn't inherit the current working directory of the active tab. In other words, when I run gnome-terminal and run "cd /tmp", then create a new tab, the new tab has my $HOME directory as the active directory instead of /tmp. Digging into the code, I notice that this is because the function terminal_screen_get_current_dir has this line: /* Get the foreground process ID */ fgpid = tcgetpgrp (priv->pty_fd); if (fgpid == -1) return priv->initial_working_directory; On Solaris fgpid is always -1. Checking "errno", I notice it is ENOTTY. According to the Solaris tcgetpgrp manpage this will happen if the calling process does not have a controlling terminal, or the file is not the controlling terminal. I notice that gnome-terminal 2.24 did not call tcgetpgrp, so this new feature in gnome-terminal doesn't seem to work on Solaris. I am unsure why, and am hoping the maintainers can give me some pointers to help track this down further, or suggest ways to possibly fix this issue. I also noticed a separate issue with VTE 0.19.4 (see bug #575183) which I thought might be the culprit. However, after reverting the pass_fd function to the older 0.17.4 version of the function I was able to work around that issue and it didn't improve this problem at all.
priv->pty_fd is a valid FD, the same as observed with VTE_DEBUG=pty (after taking care of bug 575183) ? We used to use priv->child_pid directly here to get the cwd from; maybe we should fall back to that when fgpid == -1. (The idea behind this change was to do the right thing e.g. when you do "jhbuild shell", then in this new shell you cd /some/where, then open a new new-tab; in this case the new tab should open in /some/where and not in whatever cwd we were before the "jhbuild shell".)
Fallback makes sense.
I'll add the fallback then. I'd still be interested in figuring out the cause of this failure, however; am I using this API incorrectly somehow, relying on some extension that's only available on linux/gnu?
Well, apparently the fd in question if *not* the controlling tty for the g-t process, so I wonder how this ever works. The man page on Linux suggests it should not: The function tcgetpgrp() returns the process group ID of the foreground process group on the terminal associated to fd, which must be the controlling terminal of the calling process.
If there is anything I can do to help track down what the problem might be, please let me know. I'd be happy to provide any further debug information to help track down this problem.
I just tested this with the latest version of gnome-terminal 2.26.1 and the latest VTE 0.20.0, and the problem has disappeared. I'm guessing that the fallback code added fixed the problem?
The fallback code is just that, a fallback. It'd still be intersting to know if there's a way on solaris to get the PID of the foreground process associated with the PTY.
See bug 585047 for a related issue that applies to Linux as well.
Closing this as it's obsolete since the code this failed in was removed as fix for bug 585047. Bug 675987 will fix this in a more robust way.