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 the user's home dir, unless
the program changes it. Configuration and data are normally NOT stored
in the same directory as the executable, since executables have their own
bin/ dirs, libraries their own lib/ dirs, while configuration for primary
system apps (like services started at boot) normally exists in /etc, and
for other package manager installed apps in /usr/share/ (which BTW has a
doc/ subdir as well. Meanwhile, apps installed systemwide by the
sysadmin on their own (not from the distribution package manager)
normally live under /usr/local/, which means the system usually looks in
both /usr and /usr/local locations by default.
Only apps installed by individual users (if the system policy allows it)
to their own home dir might possibly have config and data in the same
place as the executable, and even there, it's very unusual, as config
especially is normally to be found in a directory parallel to that of the
system dir. Thus, as installed by many distributions, kde's system
config is under /usr/share, its libraries under /usr/lib (or /usr/lib64
on many but not all 64-bit native systems), its binaries under /usr/
bin... and the user config is likewise to be found in ~/.kde4/share (/usr/
share/ for the system config, $HOME/.kde4/share aka ~/.kde4/share for the
user config). Data depends a bit more on the app as it's not quite as
standardized, tho it is often stored with the config (but /very/ seldom
with the app, that's the MS way, not the *ix way) and there are efforts
under way to standardize that, as well.
Now individual shells, filemanagers, and other methods of launching an
app, may of course change that default, but it's not normal to do so, and
many sysadmins and the like will object strongly if the usual $HOME pwd
isn't followed, as it's out of expectations and thus can result in
unanticipated administration and/or security issues.
If an app stores its config/data in the same dir as the executable by
default, and the app is the type that every user may have their own
config for, it's near impossible to install as a system app, because then
there's either serious security issues as every user overwrites everyone
else's config (if it's left writable for everyone), or more likely,
nobody (but an admin with root privs) gets to change the config, because
it's locked down and unwritable. Even if it's a system app with only a
single config, the typical installation separates the app from the config
and data, so upgrades and backups are far easier. If an app breaks the
rules and stores the data and/or config with the binary, it just
generates a huge headache for every sysadmin out there, and the app will
very likely either be patched to fix the problem (if open source and
convenient to do so) or an alternative app that DOES follow the rules
will replace it.
I guess that means the answer to your question is this behavior is "by
design." =:^) Which means you better be changing /your/ design, if
you're at all serious about creating an app that's actually usable
outside the university assignment setting.
Meanwhile, launch menus typically have a "working directory" or similar
entry, that you can fill in as necessary. That works for apps launched
from the launch menu, but of course directly clicking on an app to launch
it from a filemanager bypasses that. Typical solutions include a
reasonable default dir such as ~/.config/<appname> for user configs,
often with a system-wide config that's loaded (from /usr/share/app/
<appdir>/ or /usr/share/config/<appfilerc>) as well, so only the user
alterations from the normal config are saved per-user, and sometimes
examining an optional environmental variable, something like <APP>-HOME,
which if set points the app there instead of at the default location.
So that's the sort of thing I'd suggest you use, if it's supposed to be a
reasonably professional project, or simply hard-code the locations in the
app itself, if it's a first-year one-shot project or the like.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
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.
