vix@ubvax.UB.Com (Paul Vixie) (10/28/87)
In article <1886@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: >[...] I have a collection o functions that do just about anything you want >to with a modem. It has a termcap-like collection of routines for accessing >a file /etc/modemcap to get the capabilities, and code to access >/etc/modemtype to get the modem, and a whole dial(3) package to do the rest. > >But then I thought the net already had all this stuff. Am I wrong again? I sent jkh@killer some mail, asking for this to be mailed to me or posted. However, while I wait for this software, I have some questions about it. I know I've seen it around before -- perhaps it was part of BRL or some such; I wasn't entirely concious of which libraries were normal for BSD during the time of my life I seem to remember seeing /etc/modemcap on an 11/750... Has anyone added this to the BSD uucp? It seems to me that, if it's done properly, we could rip out all the dialer drivers and have auto-dial scripts done in /etc/modemcap. Ultrix does something like this, although they call it /etc/acucap there and I doubt if the format is at all similar. Rock Adams, if you are reading this, please let us know if you ever considered adding /etc/modemcap support to UUCP, and if you did (consider it), why you didn't (add it). I am willing to do this work, if it hasn't been done already. I've considered reverse-engineering the Ultrix stuff, but I'd rather use the modemcap(5)/dial(3) stuff if it's available and sufficient to the task. Comments? -- Paul Vixie Consultant Work: 408-562-7798 vix@ubvax.ub.com Ungermann-Bass Home: 415-647-7023 ames!pyramid!ubvax!vix Santa Clara, CA <<I do not speak for Ungermann-Bass>>
chris@mimsy.UUCP (10/28/87)
If someone *does* work on a modem capability database for 4.3BSD, please *stop* using the awful two-letter-keyword format imposed by termcap. The buffer size limits in the termcap-reading code are also problematical. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jfh@killer.UUCP (10/28/87)
In article <9128@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > If someone *does* work on a modem capability database for 4.3BSD, > please *stop* using the awful two-letter-keyword format imposed by > termcap. The buffer size limits in the termcap-reading code are > also problematical. > > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) I hadn't considered the two letter codes to be a problem with termcap. How often do you write termcap files? I just wish someone (Mark? Did he do this to us?) had come up with better abbreviations. Yes, my code uses two letter keywords. I didn't think going to terminfo like descriptions was worth it. As for the buffer size limits, I don't think that will be a problem with modems. - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
chris@mimsy.UUCP (Chris Torek) (10/29/87)
>In article <9128@mimsy.UUCP> I pleaded: >>If someone *does* work on a modem capability database for 4.3BSD, >>please *stop* using the awful two-letter-keyword format imposed by >>termcap. The buffer size limits in the termcap-reading code are >>also problematical. In article <1933@killer.UUCP> jfh@killer.UUCP (The Beach Bum) answers: >I hadn't considered the two letter codes to be a problem with termcap. >How often do you write termcap files? Too often. The abbreviations in terminfo are not all that much better, but (if not for the internal design of terminfo) the *set* of abbreviations could be extended with much less fear of collision. For instance, termcap does not have a way to start and end boldface or blinking modes, both of which are fairly common enhancement modes, much like inverse video (black-on-white characters) and underline. Underlining is started by `us' and ended by `ue'; inverse video is started by `so' and ended by `se'. By rights blinking should be `bs' and `be' or `bl' and be'; boldface should be `bs' and `be' or `bo' and `be'. `bs' is already in use for backspace, and clearly `be' cannot be used for both; I wound up using `bo' and `be' for bold, and `ws' and `we' for blink (`w' for `wink'). >Yes, my code uses two letter keywords. I didn't think going to terminfo >like descriptions was worth it. As for the buffer size limits, I don't >think that will be a problem with modems. (No one ever thinks buffer size limits will be a problem. They always are.) As another example, consider the flexnames (long variable names) code in 4BSD. The 4BSD compilers allow `infinitely long' variable names. In fact, these names are limited to 1023 characters. I claim that because this is a fixed limit, it is automatically too small. Do you agree? (Probably not.) The Berkeley Pascal compiler constructs unique global names for every function by stringing together the names of each outer function, joining them with underscores, so that in program foo; procedure globalproc; procedure localtoglobal; procedure localtolocal; function llfunc(a : integer) : integer; procedure lllproc; procedure llllproc; generates the name globalproc_localtoglobal_localtolocal_llfunc_lllproc_llllproc which is already 61 characters long. We have a group that has written a very large Pascal program in which the internally generated identifiers have been 140 characters long. This is already more than 1/10th of the way to reaching flexnames's idea of infinity. C++ constructs unique names by a set of rules known only to Bjarne Stroustrup. These, too, are often quite long. What will happen when someone writes an automatic programming system and uses it for a project as large as the one that generated to 140 character identifiers? I suspect that in a few years, *someone* will run into that 1023 character limit. Am I going to fix the 1023 character limit? No, or at least, not now. Would I write programs with such a limit? Probably. Is it `right'? No. There are tradeoffs everywhere; some of them involve programming time versus fixed limits. These will probably be resolved in favour of programming time. So it goes. Just remember that Limits Are Wrong, even when they are necessary. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris