Dolphin starts programs with a wrong current directory

Nikos Chantziaras realnc at
Thu Dec 10 09:02:08 GMT 2009

On 12/10/2009 12:16 AM, James Tyrer wrote:
> Nikos Chantziaras wrote:
>> On 12/09/2009 01:21 AM, Duncan wrote:
>>> Nikos Chantziaras posted on Tue, 08 Dec 2009 19:19:30 +0200 as
>>> excerpted:
>>>> It's a program I wrote myself (University assignment) and the
>>>> files in question are an SSL certificate file and a private key
>>>> file.  It usually works on every other file manager, except for
>>>> Dolphin, which lend me to believe that Dolphin is doing it wrong.
>>>> Common sense dictates that the current directory should always be
>>>> the directory "you are in"; if you are in it in the CLI or a file
>>>> manager shouldn't matter.  The current directory should always be
>>>> "where you are now".
>>> You're thinking the MSWormOS way, not the Unix/POSIX/Linux way.  In
>>> *ix, the PWD (present working directory or print working directory,
>>> see the shell builtin of the same name) is usually[...]
>> Thanks for the lengthy explanation, though unneeded in my case.  I
>> use Unix systems and program for them for 15 years now and pretty
>> much know what PWD is.
>> In any event, and IMO, "current directory" is the current directory
>> (duh).  So to ask in another way, if I go to /usr/local in Dolphin,
>> Dolphin has no reason to consider the current directory as being
>> $HOME while I'm actually in /usr/local.
>> Don't take me wrong.  All your points are perfectly valid and reflect
>>   accepted (some de-facto, some real) standards.  But you missed the
>> point that there's also a de-facto standard of having "current
>> directory" being the directory "you are in right now."  Dolphin
>> breaks that "standard."
> The Dolphin file manager part is a GUI.  You can't expect that the GUI
> will operate like the CLI.  Normally, GUI applications are started from
> a menu or icon and there isn't really a $PWD so a default directory is
> used.  In KDE4 this is the Documents path, or you can select a different
> working directory by setting it in the *.desktop file.  It is probably
> misusing a GUI file manager to open a /bin directory and click on the
> icon for an executable -- although it will work.
> If you do this properly, it will work on either the GUI or a CLI.
> IAC, you should have your executable file in a /bin directory.  System
> wide in /usr/bin or /usr/local/bin directory.  Data should not be stored
> in these directories.  This means that the executable needs to know
> where the date is.  System wide data would go in the
> /usr/share/<app_name>  or /usr/local/share/<app_name>  directory.  Private
> user data has previously gone in a $HOME/.<app_name>  directory but the
> new XDG standard suggests $HOME/.local/share/<app_name>  for the directory.
> If you follow the above, there is no need for the executable to know the
> $PWD to look for data files because they will always be in the proper
> place and it will not matter how you start the program.

Or Dolphin could simply set the working directory correctly, like every 
other file manager.

Sorry, in everything you wrote, there's no good reason whatsoever of why 
Dolphin can't set the working directory correctly.  It seems we're 
talking about two different things.  I'm asking about the working 
directory, and you reply with explanations about where to place data 
files.  Yes, data files should go in the appropriate places.  But *why* 
can't Dolphin set the working directory to the one I'm viewing in it? 
What would that break?  Why would it be wrong?

If I send someone a tar with a directory in it, a script and a few 
files, why shouldn't the person receiving it be able to simply double 
click the script instead of opening a CLI, going to the directory and 
start the script from the CLI?  Why should he have to "install" the data 
files first only to remove them again later?  Only because of Dolphin?

IMO you are simply missing the point.

This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list