[Pan-users] Re: Can I add to spellchecker

[Duncan]

Beartooth posted <address@hidden>, excerpted
below,  on Sat, 05 Jun 2004 10:49:57 -0400:

> On Fri, 04 Jun 2004 06:01:57 -0700, Duncan wrote:
> 
>> Beartooth posted :
>>> How do I add them once and for all?
>> 
>> If I were bugged enough about it to try to hunt it down, I'd probably
>> begin with an strace on the file accesses and see where that took me. So
>> far, however, I haven't been.
> 
> Well, I tried googling "strace access" and got a mixture of technobabble
> and (apparently) solid disquisition -- all of both way over my head ...

strace is a program that allows you to system trace (s-trace) the system
calls of an app as it runs.  Back on MSWormOS I used to use a couple
similar utilities, one to trace registry accesses, and another to trace
file accesses.  strace doesn't have the registry to worry about, since it
runs on Linux, but it can trace all sorts of other system calls besides
file accesses.  However, I don't know a lot about the others, but can and
do use it to see what files a program is looking for, to read, or write,
as the case may be.  I have to "man strace" every time I do so, however,
because I can't seem to remember what parameters to put it to make it only
output file activity, so I just referenced it /as/ file activity (or file
accesses) rather than looking up and using the specific command line
parameters for it, something you should be able to do.  (Again, man strace.)

>> I CAN tell you that my custom dictionary is ~/.aspell.en.pws  (Or..
>> actually.. that's a symlink to an unhidden file, located under
>> ~/config/miscfiles/aspell.en.pws .  Maybe KDE doesn't like the symlink?)
> 
> Errr... duhhh... Are you saying Pan is a KDE app rather than a Gnome app?
> Or still just guessing that my Pan does the same thing your KDE apps do?

I'm contrasting the behavior and saying that the reason KDE may not work
here may be due to that symlink.  PAN works, so it apparently has no
problems with symlinking.  The tongue-in-cheek suggestion, therefore, was
to make it a symlink if it's not, in your case, and maybe it would work! 
(IOW, don't take the suggestion seriously, but it's one difference I can
see here, and might be worth trying just for kicks.)

> And does ~/* in this case mean I should be looking for /home/btth/*,
> since my Pan is somewhere in /home/btth?

Yes, assuming btth is your login user and that's the home dir for said
user.  ~/ is common Unix shorthand for the user's home dir, wherever that
may be.

>> There are three other related files, as well, all ~/.aspell.*, one
>> en.prepl, and two english.pws and .prepl, which I'm assuming are stale,
>> from a point when I was experimenting with local settings.
> 
> So I should look in <wherever> for files that are stale? What is the
> test for staleness?

I was just explaining why I had four files instead of what I expect most
folks would have, two.  The extra two files are left over from an
unrelated experiment some months ago, and are therefore 'stale'.

Assuming your locale settings are similar to mine (en-US, English, US),
your files would probably be the .en.* files.  However, it wouldn't hurt
to copy them to .english.* just in case.  If your locale language is other
than English and dialect US, the files would naturally be different,
accordingly.

>> If you have similar files but they are marked user-read-only forsome
>> reason, or belong to some other user, that'd likely be the problem.
>> Other than that, I really can't say.. unless you want to try symlinking
>> them and see if that works, since it does here.  <g>
> 
> Symlink is one of those terms I know exists and can just about manage to
> spell .... <sigh>

This is where I was joking about the symlinking.  <g>  However, I'll take
a bit of time and hopefully explain the concept in an understandable way,
regardless of its usefulness here, because it's such a neat concept!

If you are familiar with MSWormOS, it may help to think of symlinks as
super-powerful shortcuts.  Only the shortcuts in MSWormOS are limited to
menu and launch functionality, while on Unix (including Linux), symlinks
are, as mentioned, SUPER-powerful. Their functionality isn't limited to
launching programs and the like, as they function much like shortcuts to
the real file location for the entire file system (and indeed across file
systems), not just for launching programs and in menus.

Another way to think of them is by using their other name, "soft" links,
and comparing that to "hard" links.  On Unix (therefore on Linux) a file
may have several independent pointers to it.  The most common case of this
is directories, which are listed in their parent dir by name, in
themselves, by the single dot (.) entry (thus the ability to say to use an
executable named configure, for instance, in the current directory, by
using ./configure), and in all direct child dirs by the .. parent entry
notation.  These are normally "hard" links.  That is, they are part of the
file system they are on and don't cross file systems.  Another quality of
hard links is that they are actually another name (aka "alias") for the
same file or directory.  If you delete (unlink) one name for the file, it
will continue to exist as the other name.  Thus, you can delete child
folders, along with their .. link back to the parent, without deleting the
parent folder.

"Soft" links, aka "symbolic" links, aka "symlinks", by contrast, aren't
another name for a file, but actually a separate file that acts as a
"pointer" to the original file.  Thus, while the file hierarchy normally
follows symlinks as if they were the real thing, you can delete the
original file, and the symlink will then be broken, as it will point to
nothing but still exist as its own pointer file just pointing to
something that doesn't exist, or you can delete the symlink and the file
it pointed to isn't affected in any way, just as it wasn't affected by the
creation of the symlink in any way.

Additionally, if you do a detailed listing of a hard link, all you get for
the name is that name of the file, since it's the real file regardless of
any other hard links aka other names it may be known by.

By contrast, if you detail list a symlink, you get something that looks
like this (using a common example)

command: ls  -l /usr/src/linux
output (snipped): /usr/src/linux -> /usr/src/kernel/linux-2.6.7-rc1/

The file /usr/src/linux is a /symlink/ pointing to the directory
/usr/src/kernel/linux-2.6.7-rc1.  This happens to be one of the common
ways symlinks are used, as well.  It allows one to refer to a symlink in a
standard location, here /usr/src/linux, which may point to one of several
kernel sources that may be installed.  I typically have the sources for
two or three old kernels in addition to the current one I am running, all
located under /user/src/kernel/linux-<version>, but /usr/src/linux is
always supposed to point to a copy of the sources for the kernel you have
loaded currently, and I change the symlink to do so, whenever I upgrade to
a new operational kernel, and if it fails to work as expected, I change
the symlink back when I boot the old kernel, so it's (almost) always
pointed at the source tree matching the current kernel, as it's supposed
to be.

Coming over from MSWormOS, I thought (and still think) symlinks were one
of the neatest things since sliced bread!  I can't tell you HOW many times
I could have used such a thing on MSWormOS, before I switched, only they
didn't have such a thing to use!

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin