Re: [kde] Dolphin starts programs with a wrong current directory

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: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Relevant Pages