[Pan-users] Re: Start up error on 0.111

[Duncan]

"Kevin Brammer" <address@hidden> posted
address@hidden, excerpted
below, on  Thu, 07 Sep 2006 18:12:00 -1000:

> Ideas?<br>Whenever I try to start PAN now, I get the
> following:<br><br>bash-3.00$ /opt/pan2/bin/pan<br>pan: fptools.c:455:
> _FP_fgets: Assertion `*buf' failed.<br>Aborted<br><br>It worked this
> morning before I left for work. Now this.&nbsp; :\
> <br><br>Ideas?<br>_______________________________________________
> Pan-users mailing list

If you /must/ use HTML in your posts, please at least don't do it in the
pan groups.  HTML posts are considered by many to be the domain of
spammers and crackers, so there's a reason pan doesn't support them, and
as you can see from the above quote, they aren't pleasant to look at using
pan or other non-HTML clients as well.

To your problem...  assuming you didn't leave a system update going when
you left for work or that your general system isn't otherwise different
now than it was when it worked, you've probably somehow corrupted the pan
database.  You can rename your ~/.pan2 dir (the default location, the .
beginning the filename will hide the dir by default) and pan should work
normally, recreating the directory when it starts, but you'll lose your
configuration, cache, and read message memory.

If losing everything pan had stored is a problem for you (as it
definitely would be for me), you can narrow down the issue to a specific
file by trial and error.  Copy a bit of the original configuration back at
a time, restarting pan to see if it works or not, then quitting pan and
either copying more in or deleting part of what you just copied in, until
you find the problem file.  The files are named fairly descriptively, and
I'd start with copying the preferences and servers files, then the newsrc
files, etc.  Treat the cache dir as a single unit initially.

Once you find the file that's the problem, you can open it in your
favorite text editor and see if you can find the specific problem therein,
or simply delete that file and recreate it from scratch.

I've used this method of troubleshooting many times over the years, on
many different problems and programs, even back on MSWormOS with parts of
the registry.  It works.  One good thing about it is that after you've
done it a few times, you get a feel for where the problem is likely to be,
and can therefore narrow down the problem far faster than the first few
times.  For instance, I run KDE as my desktop of choice, and it's not
unusual that a perfectly working configuration with one version will
partially break after an upgrade.  Having done this a few times, I now
know rather more about the logic of KDE's config layout, and can very
often rename only a single file, and be right with the guess the first
time.  Once that's confirmed, I'll move into the file, zooming in on the
specific config portion that's a problem if possible (that is, if the
program starts but part of it crashes or is corrupt, so I know where to
look in terms of config section), and often end up with only a single
setting to reconfigure.  I can often find, confirm, fix the problem, and
restore the setting to the way I like it of desired, in five or ten
minutes, vs the hour or two it often takes the first time you try it, when
you don't yet know what you are doing or how the app arranges stuff.

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