Dolphin starts programs with a wrong current directory

[Torsten Frey]

Am Samstag, 12. Dezember 2009 01:35:46 schrieb Nikos Chantziaras:
> On 12/11/2009 11:56 PM, James Tyrer wrote:
> > Nikos Chantziaras wrote:
> >> 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.
> >
> > Sorry that I didn't make my point clear.  When I start an application in
> > a GUI, I want the $PWD set to where I store my data, not where the code
> > is.  So, doing it your way would break that way that most users do it.
>
> Why?  $PWD is not the Documents directory.  The Documents directory is
> the... Documents directory.  The $PWD is the $PWD.
>
> Now the above sounded pretty dump, but really obvious things tend to do
> that.  So why does Dolphin think that ~/Documents is the $PWD?  Those
> two are *not* the same thing.  And after the lengthy explanations given
> in this thread, this approach even contradicts previous statements about
> how things are supposed to work on Unix systems.
>
> Bottom line, if an app wants access to the ~/Documents directory, it
> should *say so*.  From how I see it, relying that $PWD is ~/Documents is
> a broken design too for the reasons you wrote previously :)  Sorry, you
> can't have it both ways.
>

Hi Nikos,

I do not know if I understood your problem correctly. But I found this and you 
might check if this is relevant. 

system settings -> tab "General" -> group "Personal" -> "about 
me" -> "Paths" -> change the location important files are stored

e.g path to Desktop, Documents, Downloads, ...

Perhaps dolphin (as a KDE-application) uses these paths and other file 
managers probably not. 

Regards, Torsten
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.