Dolphin starts programs with a wrong current directory

[Duncan]

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.