"Kevin Brammer" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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. :\ > <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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
