Bug 183534 - KRunner uses ~/Documents as the working directory rather than ~
Summary: KRunner uses ~/Documents as the working directory rather than ~
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 4.9.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 201072 226070 (view as bug list)
Depends on:
Blocks: 302903
  Show dependency treegraph
 
Reported: 2009-02-07 09:08 UTC by Stephan Sokolow
Modified: 2012-10-06 13:53 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Sokolow 2009-02-07 09:08:56 UTC
Version:           unknown (using 4.2.00 (KDE 4.2.0), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.25-gentoo-r7-20080501

On my system, KRunner's Command Line plugin uses ~/Documents as the working directory rather than ~. Thankfully, I habitually prefix all my home-relative paths with ~/, so I only noticed when I was double-checking my facts to file a feature request.

It'd probably be best to add a field in the preferences dialog for the Command Line plugin where the user can set any working directory they want and to have it default to "~".
Comment 1 Jon Nelson 2009-05-29 14:52:13 UTC
confirmed.  openSUSE 11.1 and KDE 4.2.3.
Comment 2 Jacopo De Simoi 2010-01-09 12:23:54 UTC
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
Comment 3 Stephan Sokolow 2010-01-09 23:56:46 UTC
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)
Comment 4 Jacopo De Simoi 2010-01-12 18:42:17 UTC
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.
Comment 5 David Faure 2010-01-12 19:31:42 UTC
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
Comment 6 Stephan Sokolow 2010-01-13 01:16:12 UTC
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.)
Comment 7 EgLe 2010-08-07 23:01:43 UTC
Hello,

i have install Kubuntu Maverick Alpha3 with Krusader 2.2.0beta1 and here i have the Same problem.
Comment 8 Philipp A. 2011-07-06 20:15:46 UTC
i can confirm that. i commented on a similar bug (related to the kde paths), but i can’t find it now.
Comment 9 Jon Nelson 2011-07-25 22:26:02 UTC
Still a problem as of KDE 4.7rc2.
Comment 10 Jonathan Thomas 2011-10-11 12:40:40 UTC
*** Bug 226070 has been marked as a duplicate of this bug. ***
Comment 11 j20111130 2011-11-26 13:18:43 UTC
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.
Comment 12 vontrapp 2012-07-25 23:50:14 UTC
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.
Comment 13 Vamp898 2012-08-13 18:19:00 UTC
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.
Comment 14 Myriam Schweingruber 2012-09-08 08:58:58 UTC
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.
Comment 15 Andrea Scarpino 2012-09-08 09:12:37 UTC
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
Comment 16 Christoph Feck 2012-09-08 10:21:41 UTC
Setting status.
Comment 17 Graeme Hewson 2012-09-14 16:50:23 UTC
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.
Comment 18 synfl4g 2012-09-19 14:24:46 UTC
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
Comment 19 synfl4g 2012-09-25 14:26:38 UTC
duplicate bug of https://bugs.kde.org/show_bug.cgi?id=302903
Comment 20 Yichao Zhou 2012-09-25 14:48:04 UTC
This bug is introduced by a "FIX" in Bug 108510.  Who has permission to revert this kind of "FIX"?
Comment 21 David Faure 2012-10-05 10:05:54 UTC
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
Comment 22 Jekyll Wu 2012-10-06 13:53:57 UTC
*** Bug 201072 has been marked as a duplicate of this bug. ***