Date: Thu, 2 Feb 1995 08:37:48 -0800 (PST) From: longyear@netcom.com (Al Longyear) To: jkh@FreeBSD.org (Jordan K. Hubbard) Cc: ponds!rivers@dg-rtp.dg.com, freebsd-hackers@wcarchive.cdrom.com, longyear@netcom.com Subject: Re: chat(8) improvements for SL/IP dialout. Message-ID: <199502021637.IAA00170@olympus.tr.sii.com> In-Reply-To: <10218.791694833@time.cdrom.com> from "Jordan K. Hubbard" at Feb 1, 95 07:13:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The following changes to chat.c (and the chat.8 man page) add two > > options: > > -c <command> > > -s <speed> > > > > I'd like to, but your patch for chat.8 is bogus - it's not to -current > sources! > > Can you re-send me your patch against current, at least for chat.8? The > chat.c changes went in without any problem.. I thank you for the patches. If I may contribute a small couple of items however. 1. I wrote the man page because I could not find any man page which documented chat. 2. I added some options to chat to allow it to handle the escape sequences used by uucp and some other variations. 3. People suggested the addition of a '-f' option to it to allow for the script to be in a file. I was even sent the patch which I tweaked slightly and put it. Those were the limit to my changes. The chat program, as it is included in the pppd code, will be changed again to remove the '-l' option. It should never have had the code to do any locks in it in the first place. A lock mechanism should have been performed by the called prior to configuring the tty device. That included changing the transmission rates. In addition, when you start to consider that other systems do no not implement locks using lock files then the concept of a lock file seems extraneous and non-portable. AIX is one such system. Given that AIX code is in the version 2.2 of the pppd program, and that chat is distributed with that code, it was decided to remove the lock option from chat. (If you still want a lock file approach then there is a very nice lockfile manager in the procmail code distribution.) I will pass these changes along to the rest of the pppd porting group. In addition, there is also an active discussion about adding regular expressions to the chat program's matching code. I will say, what I said to the people who want regular expressions, that I do not believe that the existing chat program should need to be augmented beyond what it currently does. (This is a very personal opinion.) I am not against people doing that. It is not my program to say one way or another. However, if you are going to augment the program then please do one thing. Put your own name as the target for bug reports for the version. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Even I, who made the last set of changes, submit them to Paul Mackerras who has the pppd distribution. Perhaps it should be he to whom you should send the changes. I put my name on the package because I was the last one to fiddle with it and it was not right that any bug reports be sent to Karl about my changes. Just move my name down on the list of people who have changed it in the past as I did with Karl Fox's name who originally wrote the package. If you are going to add these changes to the code, and I would not stop you even if I could, then you should be aware of the other changes and coordinate with the other people who are changing the exact same code file. In this way you won't confuse the issue and there will only be one version. I stated that I would not do any changes to chat to the ppp-ports list. I do not feel that it is a good idea (other than to remove the lock code). I do not know who is planning to do the regex code. The person who seems to be advocating it is Philippe-Andre Prindeville <philipp@res.enst.fr>. You should contact him directly. It is my personal opinion that chat follows the goals of UNIX; small, simple, tools which are connect-able to build bigger more complicated systems. Chat is designed to do one thing. That is to do a uucp automated script with its stdin/stdout file. It is expected that the caller will have set the stdin/stdout file to point to the proper location and configured the files for the proper rate and all other aspects. (In short, I am definitely against creeping featurism.) If you need to go beyond the simple uucp sequence of fixed strings then you should consider other packages for doing this. The tcl and expect code is excellent. It is a rather large but very programmable system for doing scripts. Perl is also good for doing this type of work. -- Al Longyear longyear@netcom.com longyear@sii.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502021637.IAA00170>