Dolphin starts programs with a wrong current directory

[Duncan]

spir posted on Wed, 09 Dec 2009 11:51:11 +0100 as excerpted:

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

I'd disagree.  Maybe it's because I had a /proper/ explanation of where 
stuff goes and why, from reading the books I mentioned in another post, 
but I have a reliable enough understanding of the filesystem that I, for 
instance, don't use the locate service at all, having turned it off and 
uninstalled it years ago.  There's places where stuff /goes/, and I get 
very peeved as a user AND my own sysadmin, if something breaks those 
rules, and puts stuff in unexpected locations (and data or config in a 
bindir would be entirely unexpected).

Core-system config goes under /etc.  That's where boot-time services, 
etc, normally have their config.  Early boot binaries go in /bin for 
executables and /lib (/lib64 in many 64-bit installation, that's the 
standard FHS, file hierarchy standard, location for amd64 aka x86_64, but 
ia64 uses /lib for 64-bit and puts 32-bit elsewhere) for libraries.  
/root is the root user's homedir.  All those are normally on the rootfs, 
because in many cases they're used early enough in the boot that other 
filesystems aren't yet mounted, with /root there so a root login works as 
expected in single-user-mode, again when other filesystems are 
traditionally not mounted.  The rootfs is often mounted read-only in 
normal operation, particularly on more secure installations like public 
internet facing servers (ideally), etc.

System stuff that's not core enough to be needed before filesystems other 
than rootfs come online, lives under /usr.  /usr therefore has its own 
bin and lib dirs, with /usr/share corresponding to /etc, and including a 
documentation subdir /usr/share/doc .  Often, /usr does not live on the 
rootfs and must be mounted during the boot process.  This is the reason 
binaries and config used for early system boot cannot be in /usr.

There's also a /usr/local, generally used for stuff the sysadmin installs 
from source, or that the system's normal package manager doesn't know 
about or manage.  Package managers are supposed to leave this alone, 
unless specifically told otherwise by the sysadmin.  Again, this is often 
a separate partition, for ease of administration.

/mnt is the traditional location for temporary mountpoints, and remains 
the usual location for manually mounted filesystems.  /media is the newer 
location for temporary mountpoints.  It's normally used by/for hal 
assisted auto-mounting, etc.  These will of course exist on the rootfs, 
tho their subdir's contents of course is assumed NOT to be, because 
that's the point, these are the locations for temporarily mounted 
filesystems.

/var (various or variable data) is the system's data dir.  This is where 
print-spools, system mail spools if the system's running its own mail 
system (not just a mail client for each user), the distribution's package 
database, and other similar services, normally keep their data and 
caches.  Again, /var is often on its own filesystem.  

/var/log is of course under /var, for logging, but is often kept as its 
own separate filesystem in ordered to contain the damage should something 
go wrong and the logs start to fill with errors, perhaps many a second.  
A full rootfs or /var can be a bit difficult to recover from and may 
involve other more important data being lost, while a full /var/log is 
much easier to recover from and generally the only thing lost is the logs 
from the point at which it filled up to the point at which a sysadmin 
noticed and corrected the problem.  Of course, professionally managed 
systems normally have a cron job checking the status of the filesystems 
and mailing warnings to the sysadmin well before they entirely fill up, 
but /var/log is still a useful precaution, even more so on systems 
without this level of monitoring and notification.

/dev was traditionally a static dir existing on the rootfs, its contents 
a bunch of special files, device nodes, one for every conceivable device 
a normal system might have, whether they did or not.  These days, on 
Linux, it's generally a tmpfs or similar RAM based filesystem, managed by 
udev in cooperation with the Linux kernel, such that only devices that 
actually exist on the system appear here.

/sys and /proc are similar "virtual" filesystems, at least on Linux, 
setup and managed by the kernel, tho a sysadmin doesn't /have/ to 
actually mount them (but a lot of functionality will be missing if he 
doesn't).  Linux kernel developers may also have a /debug virtual 
filesystem, similarly kernel related, tho that's relatively uncommon and 
of little use for those not doing kernel debugging.

/tmp is where temporary files go.  On today's multi-gig-memory systems, 
/tmp is often not even on-disk, but a tmpfs or other RAM based filesystem.
/dev/shm is the standard location for a normally much smaller tmpfs 
(shmfs being the former name for tmpfs), designed to be used for lock-
files and other very tiny, often very temporary (seconds to minutes), 
files.  A 20 MB max size should be plenty, if you are configuring it in 
your /etc/fstab.  However, while standard, this one's obscure enough not 
all distributions have it, so few apps actually use it, preferring 
something in /tmp or the user's ~/tmp, which are far more certain to 
exist.

/home is of course the standard location for user's homedirs, and 
probably the most common separately mounted system filesystem, as having 
it on its own filesystem makes keeping the user data during system 
upgrades very simple -- just don't mkfs the existing filesystem used for 
/home.

Let's bring up "hidden" files and the parent and current directory 
entries, here.  On *ix, a filename beginning with a dot (.) indicates a 
hidden file that will not normally be listed or displayed in a 
filemanager, unless the option to view hidden files is enabled.  The two 
most common directory entries of that type are "." and "..", the single 
dot referring to "me", that is, the current directory, with the double 
dot referring to the parent dir.  Thus, all directories have a "." (that 
is "me") entry, and with the sole exception of / itself, all directories 
have a ".." entry referring to their parent.  Other .* entries may exist 
as well, but they're deliberately created, either by the user/sysadmin, 
or by a program such as the system package manager while installing a 
package, or the like.  Thus is born the possibility of trying to 
"rm .test", for instance, and accidentally getting an extra space in 
there, so it becomes "rm . test".  By itself that's not too bad, but add 
the recursive switch so it recurses into subdirs, and if you're operating 
on a file in /, **BAD** things can happen!  A variant on the theme is 
"rm .*", forgetting that ".*" includes ".."!  I once did something close 
to that in a script, as a result of a typo in a variable name, such that 
the variable was empty and the script started at / instead of in the 
directory it was supposed to start in, as stored in the (non-typoed) 
variable!  This is one reason you're not supposed to run as root by 
default -- or test your scripts as root!!  Tho a user testing a similar 
script could as easily lose everything in his homedir, which could be 
worse, if it's not backed up as it should be.

That covers the main standard "system" dirs.  The layout of /home/$USER 
(commonly seen as ~/ or $HOME, $ of course referring to an environmental 
variable with $HOME and $USER being standardized) is, unfortunately, not 
as standardized.  However, a user who cares can quickly grasp the general 
layout used by the applications they normally use, and manage them 
appropriately.

As with the system, there's normally a ~/bin for the user's own 
executable scripts and misc. binary executables they may run, having 
built or at least installed them, themselves.  This and a ~/tmp, which 
may simply be a symlink to a user subdir of the system /tmp (especially 
if the system /tmp is tmpfs, thus ensuring that it's wiped clean at every 
boot), are relatively standard.

Depending on the desktop environment, a ~/Desktop is also fairly 
standard.  It contains the files traditionally shown as icons on the 
desktop.

Beyond that, nearly all non-user-created files and subdirs of ~/ are 
hidden.  ~/.config is a standard hidden dir, tho unfortunately a late 
enough standard that far too many applications store their user data in 
hidden files or directories directly under ~/.  .bashrc is probably the 
most common individual config file under ~/, as it's where one sets up 
their own shell environment and does various other user initialization 
tasks, but there's typically dozens of hidden files and dirs in $HOME.

As this is a kde list, it's worth noting that kde's user homedir is 
normally either ~/.kde or ~/.kde<ver>, where <ver> may be 3 or 4 
depending on what you are running.  Under that, there's a few socket 
files that kde uses to communicate between programs, a share directory 
containing most user kde config, and a couple other misc. dirs.

The ~/$KDEDIR/share directory further contains various subdirs, mirroring 
those in /usr/share that store the system config. The two most 
interesting subdirs in terms of config are apps and config.  If your kde 
app uses only a single config file (typically suffixed with rc) or two, 
these files should be named according to the app, and placed in config.  
If your kde app uses more than a couple config files, they should be 
placed in a subdir named after your app, and placed in apps.

Really, there's nothing confusing at all about any of that, once you 
understand why it's done that way, altho that may indeed require being 
actually motivated enough to look and find a proper explanation such as 
this.  It may take some learning initially, and some getting used to 
thinking that way for a few weeks after that, but it quickly becomes 
second nature, and it's relatively easy to find any particular file 
because knowing its purpose, it's almost certainly in one of only a 
couple standard locations, with a quick browse (for the gui folks) or ls 
(for the cli folks) of the filesystem in those locations quickly 
revealing the file of interest.  Autocompletion, using tab at the CLI (at 
least in bash) or assuming your GUI filebrowser is sophisticated enough 
to support such functionality, makes it even easier.

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