Bug 242114

If you are talking about the initial working directory in the profile, I think the latest konsole does behave as your expectation.

In my experiment:

1). my home is /home/adaptee
2). a symlink is created for it : ln -s /home/adatpee/ /tmp/adaptee
3). open default profile, and change initial working directory to '/tmp/adaptee'
4). invoke konsole
5). `pwd` tells me I am in '/home/adatee'!

This bug still exists in 10.04 LTS.

(In reply to comment #2)
> This bug still exists in 10.04 LTS.

(K)Ubuntu 10.04 LTS? That means you are probably still using konsole shipped with KDE-4.4.5[1], which is quite outdated when compared with KDE-4.7.0, the latest release.

I would suggest you to check this problem with a recent version of konsole, instead of a outdated version.


[1] - http://packages.ubuntu.com/search?keywords=konsole&searchon=names&suite=lucid-updates&section=all

To be fair, the bug report is over a year old.  It was a recent version at the time.

Either way, sorry about the confusing reply. It had been a while since I filed the bug report and mistook this one for the one I filed with Ubuntu.

I only use this mounting point setup with dual-booting systems I build to sell.  But I can verify whether this has been fixed in a recent version of konsole if you'd like.  I'll get back to you on this.

And yes, you guessed correctly, for those such systems I prefer to use LTS releases of Kubuntu.

(In reply to comment #4)
> 
Ping? Feedback is needed.

I tested several versions, the bug still exists.

KDE 4.7.0 was not stable for me for some reason, but I tried this with both KDE 4.6.2's Konsole 2.6.2, and KDE 4.6.5's Konsole 2.6.4. 

Rereading over your initial post I now realize that you yourself confirmed this bug.  I don't know if I can state it more simply, but Konsole behavior should mimic that of cd/pwd.

Using your test environment, if you were to type "cd /tmp/adaptee; pwd" you'd get:
/tmp/adaptee

However, when you set your initial working directory to "/tmp/adaptee", started Konsole, pwd said:
/home/adaptee

The expected directory is /tmp/adaptee.  This is counter intuitive and confusing. I'd like to refer you to bug 63014 which addresses just this issue, but focuses on Konqueror instead of Konsole.

Here's another example to help you understand the problem.  This is again designed for the test environment you created:
open Dolphin
navigate to /tmp
right click on adaptee and select "Open Terminal Here"

You are now in "/home/adaptee"! You would expect to be in a tmp subdirectory, but you are not. When you "cd .." and "ls", you are expecting files from "/tmp", but you see "/home"'s listing instead.

(In reply to comment #6)
> 
Thanks for that reply. Yeah, I totally misunderstood the problem in the opposite direction.

However, after making some investigation, I think there is no elegant solution for this wish.  Below is a brief description of the involved implementation details.

1). Before the terminal process(in this case, shell) is started, konsole calls QProcess:setWorkingDirectory(dir) to set its initial working directory. In this case, Konsole does pass the 'dir' argument in the form of the symlink itself, instead of the target. 

2). Under Unix, the implementation of QProcess::setworkingdirectory(dir) calls POSIX function chdir(3p) to do its job. According to this page[1], chdir(3p) always resolves symlink into target. So although konsole does pass the symlink itself, the started terminal process uses the taget as its initial working directory.


One possible way is konsole automatically sends 'cd init-cwd-as-symlink' into shell after starting a shell session. But I don't think that is a good idea:

1). It is a hack, not nice solution.
2). Users might be confused or scared by that coming-from-nowhere 'cd init-cwd-as-symlink' command.

If you have some nice solution, please inform me.


Below is a simple program illustrating the behavior of chdir(3p)

#include <unistd.h>
#include <stdio.h>

int main(int argc, char const* argv[])
{
    char cwd[128] = {0,};

    chdir("/path/of/symlink");
    printf("cwd: %s\n", getcwd(cwd, 128) );
    printf("\n");

    return 0;
}

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/chdir.html

I would like to close it as 'CAN'T FIX', but we do not have such an entry. So close it as 'WONTFIX'.

Sorry about the delay but I've been quite busy. I don't agree with CAN'T FIX.

The proper fix here is to set the env variable PWD to the path before executing the shell.  Most shells use this as a hint to figure out where they _should_ be.  If you set PWD to /path/of/symlink bash will check to see if PWD is a symlink to the current directory and start the shell in "/path/of/symlink".

This fix should at least be possible for profiles within konsole itself. It should even be fixable through dolphin if the path is passed as an argument into konsole.  I'm not sure if it's currently done like that or not, but should be possible.

Just a quick follow up. This use of PWD may even be POSIX standard, but a quick googling didn't find docs to back this up. So I tested PWD with bash, dash, zsh, and ksh. It worked for them all.

I looked at the latest code on git and I think KPty should keep track of the initial directory. Since Pty uses KPty it also seems like an acceptable location for the change, but less so.

Ideally we'd override setWorkingDirectory, but it's not virtual. So I propose a new function, setInitialDirectory, to be called in the place of setWorkingDirectory in Session.cpp (the only place setWorkingDirectory is called on a Pty). It would use setenv if a member of KPty, or addEnvironmentVariables if a member of Pty, to set PWD to the path passed in as a QString.

It's such a small fix, but I could provide a patch if it would make a difference. I have KDE 4.6.5 installed in a Gentoo distro and could easily provide a patch against that version of Konsole. It's a simple change but I don't know how much the code has changed since then. I could also provide an untested patch against the latest source. (As I mentioned before, 4.7 is not stable for me.)

(In reply to comment #11)
> 

I am still in doubt with setting up $PWD because my experiment does not give expected result and seemingly cause regression in other aspect.

Yeah, patch is always welcome even if it seems trival. A patch against 4.6.5 should be OK.

Created attachment 63759 [details]
proposed PWD fix

I wrote and test a patch (and attached it without comment). It fixes the profile directory not matching the symlink and it also fixes the Dolphin "open here" problem I spoke of earlier without any changes needed in Dolphin.

It doesn't use 'addEnvironmentVariables' because I would be taking "PWD", appending "=", and then the path to it. Then splitting it into a list, and then passing it in to be broken back down.  Using 'setenv' was much more readable.  KProcess has a 'setEnv' which uses QStrings, but I didn't look into since 'addEnvironmentVariables' does it with 'setenv'.

It doesn't fix the tab at the bottom, or the title, which both still show the raw working directory.  Nonetheless, this is much better than before.  What are the regressions you are worried about?  I didn't notice any new bugs, but I was just testing what came to mind.

OK, I tested your patch. It did its job. But based upon my observation I have a few concerns about the $PWD trick:

1. $PWD and the pwd builtin provided by shell reports 'symlink', while the command /bin/pwd reports 'target'. That applies for both bash and zsh(and maybe other shells).

2. /proc/<pid>/cwd still refers to the target. That means %D or %d in the tab title will say 'initial pwd is target' while the shell prompt and builtin will say 'initial pwd is symlink'. Yes, you mentioned that.

So the main problem is the inconsistency, which might confuse users. 

> Nonetheless, this is much better than before.
Well, the current behavior is confusing, but the new behavior is also confusing.  I'm not sure which one is better or less confusing: consistently wrong, or inconsistently wrong?

Anyway, I am not against this patch myself.  Kurt, would you like to give some comments ?

Thanks for looking at the patch. I'd like to point out a couple of things.

1. Both with and without this patch, if you "cd /to/some/symlink" the title bar and tab are inconsistent and show the wrong path. While they will show the /proc/<pid>/cwd path, the shell itself will show "/to/some/symlink".

2. This fixes not only the starting path manually set within the profile, but the action "Open terminal here" within dolphin and konqueror.

3. I'd hesitate to call PWD a trick. This is exactly how shells communicate directory information. It's why you can start any shell within another without losing your path. This isn't just zsh and bash, it's every shell I could think to test. If it isn't an official standard, it's as good as one.

OK, I am convinced and will commit the patch later. Thanks for you help !

Git commit 790e835c6fab58a5c4bfe00559d3a4ee97b84e38 by Jekyll Wu.
Committed on 30/09/2011 at 17:47.
Pushed by jekyllwu into branch 'master'.

Do not resolve the symlink for initial working directory.

The patch is from Danny Daemonic <DannyDaemonic@gmail.com>

FEATURE: 242114
FIXED-IN: 4.8

M  +6    -0    src/Pty.cpp
M  +5    -0    src/Pty.h
M  +2    -2    src/Session.cpp

http://commits.kde.org/konsole/790e835c6fab58a5c4bfe00559d3a4ee97b84e38

Doesn't appear to work with sh and tclsh.  This is fine as long as it doesn't make anything worse/more confusing.

I'm glad you approve.  I installed and tested tclsh and you're right about that one, but sh works for me.

For Debian and Ubuntu, sh is a symlink to dash. Some distros such as Gentoo symlink sh to bash.  I'm surprised your sh doesn't point to one or the other. I'm pretty sure not following this rule will break sh scripts which expect symlink paths to be preserved.  If you want the actual physical path in a POSIX sh shell you are suppose to use `pwd -P`:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pwd.html

Mind if I ask what your system runs as sh and what distro you are using?

#20 you are correct - all except tclsh appear to work.

It would be very nice to get the tabs %d and %D to have the 'correct' path.