GNOME Bugzilla – Bug 502146
--working-directory option has bugs
Last modified: 2019-05-09 14:38:13 UTC
Please describe the problem: A. "Open in New Terminal" (Nautilus extension) doesn't work when another terminal window is already open. B. --working-directory doesn't work when the path starts with ~ C. also, --working-directory=/path/to/symlink opens the symlink TARGET rather than the symlink itself. Steps to reproduce: as above Actual results: as above Expected results: as above Does this happen every time? yes Other information:
A. does not seem like a gnome-terminal bug, must be a problem with the nautilus extension. B. the ~ expansion is done by the shell. For it to work you have to use some syntax the shell would understand, probably you need to omit the "=" after --working-directory. It won't work if you don't launch gnome-terminal from a shell, but this is expected. It's not correct for apps to do shell expansion. C. how would you change directory to a symlink and not its target? (surely gnome-terminal just calls chdir())
Re C, I think it's about what g-t shows in the title. There's no way to fix it. The reason you see the symlink name when you cd into such a directory in shell is that your shell is being smart, remembering how you got into this directory, otherwise, technically there's no way to tell.
(In reply to comment #2) (In reply to comment #1) I see. Well, could it not be possible to allow a option where the symlink's original path was retained? Eg. by passing $(pwd) to the new instance of gnome-terminal which then automatically does cd /; cd $(pwd); before displaying a console to the user?
No, g-t can only do chdir() syscalls. And to that function, the symlink is not a different location.
*** Bug 524654 has been marked as a duplicate of this bug. ***
Dear all, I'm the reporter of https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/263637: "This happens all the time to me, because in my job I write a lot of research papers, all of them being in a Subversion repository. Since I like to use a different hierarchy than the other people I'm working with, I've got a separate directory with many symbolic links, organized in a different way (I store them by year). Each time I open a new tab, I'm back in the SVN repository. That's quite annoying." I read it's impossible to fix it, but Pedro Villavicencio on Launchpad says that this doesn't happen with xterm nor with terminator. Doesn't that mean that there should be a solution to this problem? I don't want to be mistaken on that point, you surely know the problem better than me, but that's really annoying on an everyday basis for me. Isn't it possible to make the shell execute multiple cd's commands when starting it, instead of changing the directory before starting it?
Ok, I see... Basically, if you are running a 'gnome-terminal' command from inside another terminal, yes, this can be improved very easily: Just use $PWD if set. However, when opening a new tab/window from an existing g-t, it's not as easy, as the $PWD of the process running inside the current terminal is what it was when the process was launched. And that's useless. So, to summarize: it's still impossible to do better when you open new tab/window. It can be improved when you run a new gnome-terminal command though. But then having these two cases behave differently can be even more confusing.
(In reply to comment #7) > Ok, I see... Basically, if you are running a 'gnome-terminal' command from > inside another terminal, yes, this can be improved very easily: Just use $PWD > if set. > > However, when opening a new tab/window from an existing g-t, it's not as easy, > as the $PWD of the process running inside the current terminal is what it was > when the process was launched. And that's useless. Can't you "ask" the current terminal to execute a command, like echoing $PWD to some temp file before opening the new shell? > So, to summarize: it's still impossible to do better when you open new > tab/window. It can be improved when you run a new gnome-terminal command > though. But then having these two cases behave differently can be even more > confusing. Actually, still considering my example, when I run a new gnome-terminal from another one (by typing 'gnome-terminal'), the new instance is in my own directory, not in the SVN repo.
(In reply to comment #8) > (In reply to comment #7) > > Ok, I see... Basically, if you are running a 'gnome-terminal' command from > > inside another terminal, yes, this can be improved very easily: Just use $PWD > > if set. > > > > However, when opening a new tab/window from an existing g-t, it's not as easy, > > as the $PWD of the process running inside the current terminal is what it was > > when the process was launched. And that's useless. > > Can't you "ask" the current terminal to execute a command, like echoing $PWD to > some temp file before opening the new shell? No, of course not. > > So, to summarize: it's still impossible to do better when you open new > > tab/window. It can be improved when you run a new gnome-terminal command > > though. But then having these two cases behave differently can be even more > > confusing. > > Actually, still considering my example, when I run a new gnome-terminal from > another one (by typing 'gnome-terminal'), the new instance is in my own > directory, not in the SVN repo. I said it's easy to fix that case. I didn't said it works that way right now.
The https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/263637 affects me too, my usual working directory is a symlink and everytime I open a new tab I am back in the symlink target directory. It's a lot of typing to get to related directories around that symlink. It would be great if this one would go away.
*** Bug 564510 has been marked as a duplicate of this bug. ***
*** Bug 616163 has been marked as a duplicate of this bug. ***
*** Bug 639789 has been marked as a duplicate of this bug. ***
If we really wanted to fix this we could poke around the environment of the child process of the current terminal. I have a vague memory that we had something like this but it caused semi-random behavior, as in, when you were running "find /" and opened new tab, you ended up in random directories because 'find' is chdir()ing all the time. We can only look into the env of the first child of the terminal, but that has its own problems.
*** Bug 651298 has been marked as a duplicate of this bug. ***
Can something finally be done about this bug? I'm in a world of pain because of it. (In reply to comment #2) > Re C, I think it's about what g-t shows in the title. There's no way to fix > it. The reason you see the symlink name when you cd into such a directory in > shell is that your shell is being smart, remembering how you got into this > directory, otherwise, technically there's no way to tell. How about checking PWD variable of foreground process? At least bash sets it to the correct, unexpanded path. "The current working directory as set by the cd command", according to man. So I propose the following: get cwd using current method and compare it with PWD. If they both point to same directory, then use PWD. Sounds like a pretty safe way to fix this bug. What do you think? I'm willing to write a patch if you're ok with it.
This is fixed on git master. Bug 675987 will fix the same problem for opening new tabs/windows from within g-t.
*** Bug 686623 has been marked as a duplicate of this bug. ***