Nikos Chantziaras wrote:
> 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.
>
(bottom line)^2 is that this (KDE) is a GUI. A GUI does not work the
same as the underlying OS. MS-Windows is the same. It looks for user
files in MyDocuments. I don't have MS-Windows so I don't know if it
uses MyDocuments for the "cd" or not.
And, as I said, if an executable needs access to data, it should keep
it/look for it in the proper place and not rely on it being (improperly)
stored in the /bin directory with the executable. On *NIX, it is not
proper to store data in a /bin directory as was common practice with
PC-DOS. You don't seem to be getting that.
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
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.
