Dolphin starts programs with a wrong current directory

[spir]

Duncan <1i5t5.duncan at cox.net> dixit:

> 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.
> 

Great explaination of one thing I guess unix/linux/bsd/etc... have wrong!
To even a power user, linux filesystem is just a huge chaotic mess, unexplicable, unmanageable, random-like organisation. It's simply impossible to guess or remember where things are supposed to live. Two seemingly identical install cases will actually not produce same install locations, and locations even change with versions.

The root of the whole issue lies far back in time when unix was a system designed for sysadmins, and users were seen *only* as potential sources of calamities for the system --and for the sysadmin. The admin had all power and the user none. The user had to ask the admin for every tiny change. Users had to share a system and an admin. Remember that working posts long were only terminals in the plain sense of the word, not independant computers.

Today in common cases, not only there is a single (main) user per computer, not only there is no sysadmin to manage the mess, but users have to be their own admin. Linux *demands* the users a lot of knowledge, work, and implication, but does not give them the means to even have a chance to be able to master it. This is a kind of "paradoxal injonction" (not sure of the proper idiom in english)! It makes lot of mental harm ("I'm too stupid for that") and drives loads of good-willing people away, that would else use FLOSS, if only for moral reasons.

The situation has completely changed, but the system hasn't at all on this regard; the issue is the source of the problems are deep rooted in the core of the system and diffuse in the whole of it; even up to everyday use situations such as changing a config or renaming a file.

In my opinion, there is a deep need for a totally different free OS. Designed from the root to be used, managed, mastered by users with ordinary competence; but willing to get involved in the common free-software effort. This system would not need be extraordinary sophiscated; a well-designed command-line interface may be a wonderful tool.

Denis
________________________________

la vita e estrany

http://spir.wikidot.com/
___________________________________________________
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.