Bug 183534

confirmed.  openSUSE 11.1 and KDE 4.2.3.

here with 4.3 running pwd from krunner (checking the option to work in a terminal) prints the correct path to ~
Was this your issue (and hence it got fixed) or is it something else I don't understand?
Thanks

Still unfixed. Put a file named TODO.txt in ~ and another one in ~/Documents with different contents, run `kwrite TODO.txt`, and you'll see the contents of the one in ~/Documents.

However, your test with pwd shows where things get odd. If you don't run in a terminal, the working directory is ~/Documents. If you do, it's ~. (Try "kwrite TODO.txt" in a terminal and it works)

That kind of "smarts" reminds me of Microsoft's Personalized Menus feature. (Well-intentioned, but poorly thought out and counter-intuitive)

As I found out (thanks to dfaure) this behaviour turns out to be consistent with the fact that non-KDE apps need to have ~/Documents as a working dir to behave correctly with respect to kde global settings (see old bug 108510).
In this view, forcing ~ to be the working directory is inconsistent, for instance if you type "oowriter" and "oowriter --some-option" you would end up in two different paths, which makes little sense.

SVN commit 1073715 by dfaure:

Add the possibility to specify a working directory in KRun::runCommand, and make it
default to documentPath for consistency with apps started via kdeinit.
CCBUG: 183534


 M  +20 -1     krun.cpp   [POSSIBLY UNSAFE: KRun::runCommand]
 M  +21 -1     krun.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1073715

Not an ideal solution, but I don't see a much better alternative.

Ideally, I'd prefer to see separate settings for documents directory and default working directory with a selector to choose which one non-KDE apps fall back to... but that's getting a little excessive.

Given that I'm still in the habit of ignoring KRunner and just using xbindkeys+gmrun, this bug isn't really a big problem for me any more. (To be perfectly honest, having more GUI latency on my Athlon64 X2 5000+ than my 2Ghz Celeron (IceWM+PCManFM) after over a year of fixes is really grating on my nerves and souring me on KDE 4 and the only thing that's really been keeping me on KDE since Konqueror started sucking is the open/save dialogs and the effort involved in getting suitable dual-monitor panels out of an alternative WM. Lesser of two pains in the butt and all.)

Hello,

i have install Kubuntu Maverick Alpha3 with Krusader 2.2.0beta1 and here i have the Same problem.

i can confirm that. i commented on a similar bug (related to the kde paths), but i can’t find it now.

Still a problem as of KDE 4.7rc2.

*** Bug 226070 has been marked as a duplicate of this bug. ***

This problem is across all of KDE, and causes grief with interoperability with other desktop environments.
To see for yourself, open a terminal - any terminal program will do, such as xterm.
Maximise it
Enter this command:
john@Boomer:~/Documents$ ls -l /proc/*/cwd | grep $USER

You will see practically everything is running in ~/Documents.

In GNOME, XFCE, LXDE (at least) all the terminal programs are in ~

I guess some place early that KDE does a chdir() to change to the users Documents directory.

I propose that KDE be changed (urgently!) to start in the Documents directory only those applications that should be started there. I am, by the way, not sure that there are any, because any that are will behave differently depending on whether they are started from a men or from s (Konsole) commandline.

fwiw I am on Debian Stable and Fedora 16.

This is a highly annoying bug.. I  confirm that it is across all of KDE as comment 11 says.

No program should assume it will be started from any particular cwd and use that cwd blindly. Also, no program should assume that any cwd that it DOES start in is invalid and should be overridden. Either case violates the principle of least surprise. Either a program should go to some specific directory, hopefully configured and not hardcoded (and ignore cwd altogether), OR the program should graciously use whatever cwd happens to be.

So, that said, the problem is NOT with whatever programs might be doing with the cwd that the parent-of-all KDE is passing on to them. In most cases they ARE doing the correct thing. In the cases where having KDE *not* use ~/Documents as its cwd would break some programs, it is *those* programs that are doing something wrong.

The problem, then, is KDE changing cwd to ~/Documents in the parent process that forks all other gui applications, and changing it back to ~ *should* not pose any damage. If it does, it is a bug in something else.

Some grepping revealed absolutely no textual or otherwise configuration files that determine where KDE changes its cwd to. /usr/bin/kde4-config, however, matches for both DOCUMENTS and Documents.

And no, I do not believe changing DOCUMENTS=Documents in /etc/xdg/user-dirs.defaults is a proper or desirable solution.

Reported:	2009-02-07

still not fixed --> that is a much to long time! I mean, its nothing you can talk about, its defenetly wrong what happens here and it seems to be ease to fix (hopefully ~/Documents wasnt hardcoded in the kdelibs)

So whats the fuzz all about? fix it and fine. I mean, what helps it to create new Plasma Interfaces for Tablets, Netbooks and so on when even starting a simple konsole in ~ does not work as desired.

People dont care if KDE is the most awesome Desktop in world, as soon they started one konsole they will say "wtf?" and logout. Thats the story, those small stupid bugs is what people make think KDE is bad software.

Nobody wants that, neither the user, nor the maintainer.

Well, for a start: the bug doesn't even have a version, so no wonder this is not high on the focus. Which exact KDE version is this about? Please state the most recent KDE version this is reproducible in.

KDE 4.9.1:
Running `pwd` from KRunner, I get ~/Documents
Starting Konsole from both KRunner or from the Application Launcher Menu, starts from ~/Documents

Setting status.

I had problems with Konsole and Akregator assuming ~/Documents. I've now worked around the problem by setting my Documents path through System Settings to be my home directory.

I don't think I should have to work around the problem in this crude way. As far as I'm concerned, Documents are edited with LibreOffice, not Konsole, and I certainly don't download Documents with Akregator.

Same bug on Fedora 18 Alpha KDE spin.
A question, is a bug or is a feature?, because the KDE SIG Fedora say that is a feature for compatibility with apps some Quanta, that no have compatibility with xdg-dirs (kevin kofler of fedora KDE SIG).
I think that is a bug, because if i need alterate the normal path for documents for give me xterm, aterm, eterm, st, etc with start directory on ~/, is a bug. Konsole can fix it modifing the setting of the current profile, but, is not a system-wide solution.

Regards

duplicate bug of https://bugs.kde.org/show_bug.cgi?id=302903

This bug is introduced by a "FIX" in Bug 108510.  Who has permission to revert this kind of "FIX"?

Git commit f659ebf30dde67798926e9ab0a7671a96602174b by David Faure.
Committed on 05/10/2012 at 12:00.
Pushed by dfaure into branch 'KDE/4.9'.

By popular demand, revert the call to chdir(documentPath).

This was an attempt to make the KDE document path work in non-KDE
gui apps (such as openoffice) (#108510). But it makes terminals
start in ~/Documents, which users don't expect.
Related: bug 302903, bug 108510

M  +1    -9    kinit/kinit.cpp
M  +1    -6    kio/kio/krun.cpp

http://commits.kde.org/kdelibs/f659ebf30dde67798926e9ab0a7671a96602174b

*** Bug 201072 has been marked as a duplicate of this bug. ***