I recently walked a friend through installing dunc-2.1 on a slackware box (from the debian package). The first thing we both noticed was how easy it is to install debian software on non-debian systems[1]. The second thing we noticed was the the version of dialog (although the upstream version was in sync with the debian dependency's) was incompatable -- it core dumped every time we ran it. So we got the debian dialog package and installed it and all was fine. Then we noticed (to my embarassment) that the program never created the BASEDIR directory and failed to run. We also noticed that the "dppp --help" was useless as the screen cleared before you could read the text.
The good news was the we manually created the BASEDIR driectory and dunc ran very well. He hit enter a few times, typed in his username and password, hit enter a few more times and was up and running. His ISP provides PAP and CHAT style connections and both methods tested fine. The RCFILE needed some cleaning up after the BASEDIR was finally made though. The problem is that the dunc script checks for duplicate connection definition files in $BASEDIR, but assumes $BASEDIR exists. If it doesn't, then $RCFILE will get updated with the connection information, but the write to $BASEDIR/<connection name>.ctn will fail. The next time you try to set up a connection, the name will be valid in $RCFILE but not in $BASEDIR, thus allowing you to recreate the same connection (i.e. use the same name.) This lead to the first (empty) case block of the connection name in $RCFILE being initialized and causing more confusion during future program runs. The only solution was to edit $RCFILE. The RCFILE was structured to allow one to recover lost connections, or duplicate them, from the RCFILE. This feature was not implemented, however. I haven't been able to come up with a way to easily integrate this behavior into the script as is. but I read Sven's post about rewriting dinstall in C, and I think it would much easier to deal with a lot of the stuff dunc attempts to do in C. Unless there are any serious objections, the next version of dunc will deal with the above situation better, and it will be modeled after dinstall in C(+giggle?). There are two questions I have: 1) what would be the best way to deal with broken $RCFILEs as a result of the previously mentioned scenerio? 2) Is there anyone knowledgeable in PPP who could stay subscribed to the PPP list(s) and help out with the dunc implementation? I'm willing to remain the maintainer, but I think the package could use some help, especially moving forward with the latest PPP. I'd also be willing to turn the package over to someone who could do a better job with it. I'm unable to subscribe to the lists and have little time to spend on development. (one of the other things we noticed was the there is no way in dunc to specify a longer timeout. The ISP defaulted to PAP, and must have had a list of protocols to try -- chat being last. Sometime it was OK, but sometimes it wasn't). [1] This is actually a very good selling point for the package format. Perhaps debian-publicity should start marketing the format based on its strength (not comparing it to any other format, of course), and ease of use. That is, assuming we're not dumping it for a commercial format ;) Thanks Richard G. Roberto [EMAIL PROTECTED] 011-81-3-3437-7967 - Tokyo, Japan -- ******************************************************************************* Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. ******************************************************************************* -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
