km@emory.UUCP (06/05/87)
Most of the communications programs on Berkeley Unix (tip, rlogin, cu)
are split into two two processes on the local side, a reader and
writer. This makes sense to me in a System V environment with no
"select" system call. But why the extra process in tip and rlogin,
which are relatively recent and written just for BSD?
--
Ken Mandelberg | {akgua,sb1,gatech}!emory!km USENET
Emory University | km@emory CSNET,BITNET
Dept of Math and CS | km.emory@csnet-relay ARPANET
Atlanta, Ga 30322 | Phone: (404) 727-7963chris@mimsy.UUCP (06/06/87)
In article <2071@emory.UUCP>, km@emory.UUCP (Ken Mandelberg) writes: >... why the extra process in tip and rlogin, which are relatively >recent and written just for BSD? I cannot speak for tip, never having used it, but rlogin supports a `partially stopped' mode (via ~^Y, or whatever your delayed suspend character is) in which output from the remote system is still displayed. For this to work rlogin must fork. Given that, it might as well do it immediately. (There may also be less overhead that way, as the two processes can just sit in read() and write(); a successful select() would require at least one more system call.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
ndd@duke.UUCP (06/06/87)
In article <2071@emory.UUCP> km@emory.UUCP (Ken Mandelberg) writes: >Most of the communications programs on Berkeley Unix (tip, rlogin, cu) >are split into two two processes on the local side, a reader and >writer. This makes sense to me in a System V environment with no >"select" system call. But why the extra process in tip and rlogin, >which are relatively recent and written just for BSD? >-- >Ken Mandelberg | {akgua,sb1,gatech}!emory!km USENET >Emory University | km@emory CSNET,BITNET >Dept of Math and CS | km.emory@csnet-relay ARPANET >Atlanta, Ga 30322 | Phone: (404) 727-7963 Tip is not relatively recent: it was certainly available around 1980 on the V7 system I was using at the time. Perhaps no one has rewritten it since. And, depending on what you are using, tip may not involve just two processes. I remember installing a security feature for tip that I got from the net. The problem was that tip made a lock file in /usr/spool/uucp, and then forked once to do the communicating. Unfortunately, you had to leave tip running as uucp so it could remove the lock, which meant that a user who did a shell escape would have uucp privileges. The hack was to fork two processes: one for the read and one for the write; they would reset to the user's id, and the parent would wait until they terminated, and then remove the lock. In retrospect, it seems as if this could have been handled without the extra process, but I thought it was a neat trick at the time. Ned Danieley Basic Arrhythmia Laboratory Duke University Medical Center
m5@bobkat.UUCP (06/08/87)
In article <6947@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >I cannot speak for tip, never having used it, . . . >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) What?!?!? Chris has **never used tip**??? I would have bet that not only had he *used* it, but had re-written it as TeX and emacs macros. Geez. -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
chris@mimsy.UUCP (Chris Torek) (06/09/87)
>In article <6947@mimsy.UUCP> I mentioned: >>I cannot speak for tip, never having used it, . . . In article <1075@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally) writes: >What?!?!? Chris has **never used tip**??? ... Well, in fact, I once borrowed someone else's tip session. I discovered that ^A acted as a caps-lock, and that one had to type ^P twice to send one. It was obvious that ^P was being used as an escape character (it *is* DLE, Data Link Escape, after all). I considered this obnoxious enough that I never used it again. I had been using Fred Blonder's `x' program; I now use instead my own `c' (usage: c -l link [-s speed] [-p par] [-e esc]), except when I need features like transcription. (`C' has almost no features, hence nothing to go wrong.) >I would have bet that not only had he *used* it, but had re-written >it as TeX and emacs macros. Geez. Well, I did once write a set of Emacs macros to run rogue in an Emacs window, but the result was too slow to be of any real use. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
paul@vixie.UUCP (Paul Vixie Esq) (06/09/87)
In article <6969@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >[...] I once borrowed someone else's tip session. I >discovered that ^A acted as a caps-lock, and that one had to type >^P twice to send one. It was obvious that ^P was being used as an >escape character (it *is* DLE, Data Link Escape, after all). I >considered this obnoxious enough that I never used it again. [...] This seems to have been added in 4.3; at least, I never noticed this in the 4.2 version. I was sufficiently disgusted with the ^A and ^P behaviour that I hacked tip to have two new variables: 'set noforce' (or :nf: in the /etc/remote file) means: don't do the ^P stuff, just treat ^P as a normal character 'set noraise' (or :nr: in remote) means: don't do the ^A/CAPSLOCK stuff, normal character, etc. The changes were simple, and I could post diffs. The man page doesn't mention many of the variables in the source, and the man page for remote(5) doesn't mention a different set of things. I thought of updating the man pages, but the task overwhelmed me. I'd like to post the whole thing. Is this BSD-only code? What are the licensing hassles if it is? Obviously if it's ATT-derived, I can only post diffs, but what about BSD-pure stuff? Chris? You answered the last question about BSD policies -- got a quick answer to this one? -- Paul A Vixie Esq 329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov CA 94116 paul@vixie.UUCP (415) 864-7013
dhesi@bsu-cs.UUCP (Rahul Dhesi) (06/10/87)
In article <651@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >I'd like to post the whole thing. Is this BSD-only code? What are the >licensing hassles if it is? Obviously if it's ATT-derived, I can only >post diffs, but what about BSD-pure stuff? Somebody, give a general answer to this. Our 4.3BSD license agreement says we can't redistribute anything to those who do not have an AT&T source license. This doesn't make sense to me, since a lot of code in 4.3BSD has nothing to do with AT&T. For that matter, I have a nagging feeling that roughly 100% of the kernel itself is independent of AT&T. So why this overly restrictive license agreement? Why is it OK for others to distribute uuencode and uudecode, but not us? Why can some people freely distribute sendmail, but not others? Finally, what about some of the games, which are exclusive to BSD? Why does AT&T care whether we give them away to others? If AT&T doesn't care, why does Berkeley say that AT&T cares? Have you ever wondered about the proprietary of government funding of the development of a terrific operating system, accompanied by the restriction that only licensees of a certain private corporation may take advantage of the fruits of that government funding? 4.3BSD OUGHT TO BE IN THE PUBLIC DOMAIN. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
guy@gorodish.UUCP (06/11/87)
> Our 4.3BSD license agreement says we can't redistribute anything > to those who do not have an AT&T source license. This doesn't > make sense to me, since a lot of code in 4.3BSD has nothing to do > with AT&T. I believe this was done because the people at UC Berkeley didn't have the resource to figure out, in detail, what code was and what code wasn't independent of AT&T code, and they took the safe way out. I can't entirely say I blame them. > For that matter, I have a nagging feeling that roughly 100% of the kernel > itself is independent of AT&T. Well, I suggest you tell that feeling to stop being such a kvetch; it's simply not true. There's plenty of recognizable AT&T code left in the 4.[23]BSD kernel. > Have you ever wondered about the proprietary of government funding > of the development of a terrific operating system, accompanied by > the restriction that only licensees of a certain private corporation > may take advantage of the fruits of that government funding? No, not really, since the government didn't fund the whole thing. They just funded the stuff Berkeley added. They didn't fund the development of UNIX/32V, from which 4BSD sprang, or the development of V7, V6, ... from which UNIX/32V sprang. > 4.3BSD OUGHT TO BE IN THE PUBLIC DOMAIN. No, it oughtn't. It contains code developed by AT&T and licensed by AT&T, and they have a right to require a licensing fee to use that code. If you want a public domain UNIX, go write one - put your time where your mouth is. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
sverre@fesk.UUCP (06/11/87)
in article <651@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) says: > ... I was sufficiently disgusted with the ^A and ^P > behaviour that I hacked tip to have two new variables: > > 'set noforce' (or :nf: in the /etc/remote file) > means: don't do the ^P stuff, just treat ^P as a normal character > > 'set noraise' (or :nr: in remote) > means: don't do the ^A/CAPSLOCK stuff, normal character, etc. Isn't this an overkill. A .tiprc file containing the two lines force= raisechar= has the same effect. -- Sverre Froyen UUCP: boulder!fesk!sverre, sunpeaks!seri!fesk!sverre ARPA: froyen@nmfecc.arpa BITNET: froyen@csugold.bitnet
paul@vixie.UUCP (06/12/87)
In article <140@fesk.UUCP> sverre@fesk.UUCP (Sverre Froyen) writes:
#in article <651@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) says:
#> ... I was sufficiently disgusted with the ^A and ^P
#> behaviour that I hacked tip to have two new variables:
#Isn't this an overkill. A .tiprc file containing the two lines
# force=
# raisechar=
#has the same effect.
Hmmm, I hadn't thought of that. I would probably have done it that way,
since adding variables to TIP is kind of a pain in the posterior. Having
done it, though, I can see an advantage to having it in the /etc/remote
file, since I can put :nf:nr: into the entry that all the other entries
:tc=: to, and have ^A/^P totally gone from my TIP. A bonus if I want to
be able to run TIP from a customer's logon, or from root, or from some-
where else that I've forgotten (or never had reason) to give a .tiprc.
The real issues for me are: (1) why was ^A/^P added at all? It's useless!
(2) should I post the diffs? (3) can I post the whole thing?
--
Paul A Vixie Esq
329 Noe Street {ptsfa, crash, hoptoad, ucat}!vixie!paul
San Francisco ptsfa!vixie!paul@ames.ames.arc.nasa.gov
CA 94116 paul@vixie.UUCP (415) 864-7013amos@instable.UUCP (06/12/87)
There's another mis-feature of ^A in tip (4.2 version, at least): in
addition to being the default raisechar, it is also tip's mark for
its own internal escape sequences, used for %take. We discovered it
here the hard way, when trying to move files using a tip within a tip -
the upstream tip swallowed the ^A's meant for the downstream tip's echo
command, so that the latter didnt know when the file ended and got stuck,
and to top that, when we finally managed to kill it, the former had put us
in upper-case mode - on a line that wasn't expecting that!
(If you know how tip works internally, you can figure out what happened,
otherwise, don't bother trying).
--
Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. (972)52-522261
amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 Nshannon@sun.UUCP (06/15/87)
In article <655@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes: > The real issues for me are: (1) why was ^A/^P added at all? It's useless! I put ^A and ^P in the original version of tip I wrote many, many years ago. ^A is there because I used tip to talk to a system that required all uppercase commands, but would let me edit files with mixed case, and the terminal I used didn't have a case lock. ^P was there so I could send things like ^A through to the other end; extremely useful when cascading tip's. Bill Shannon
chris@mimsy.UUCP (06/16/87)
In article <651@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >I'd like to post the whole [new version of tip]. Is this BSD-only >code? I think so. Was it in 32V? >What are the licensing hassles if it is? Obviously if it's ATT-derived, >I can only post diffs, And maybe not even those. >but what about BSD-pure stuff? It is my impression (note key word) that Berkeley does not care how much their stuff gets redistributed as long as it stays marked `this neat software is by Berkeley, and if you fund us, we will write code for your machine too' :-) . In general, I myself do not hesitate to post context diffs (-c2) to anything on the 4.3BSD tapes. Anything more than that (e.g., the UDA50 driver) requires more thought. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
rbj@icst-cmr.arpa (Root Boy Jim) (06/17/87)
In article <6969@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >[...] I once borrowed someone else's tip session. I >discovered that ^A acted as a caps-lock, and that one had to type >^P twice to send one. It was obvious that ^P was being used as an >escape character (it *is* DLE, Data Link Escape, after all). I >considered this obnoxious enough that I never used it again. [...] Gee, Chris, RTFM. It's not rlogin, you know. Just because you want to run a remote emacs doesn't mean it's no good. Rlogin has escapes too! This seems to have been added in 4.3; at least, I never noticed this in the 4.2 version. I was sufficiently disgusted with the ^A and ^P behaviour that I hacked tip to have two new variables: Nope. `Twas there in 4.2. Paul, you had better RTFM too! I'd like to post the whole thing. Is this BSD-only code? What are the licensing hassles if it is? Obviously if it's ATT-derived, I can only post diffs, but what about BSD-pure stuff? Chris? You answered the last question about BSD policies -- got a quick answer to this one? Nobody minds if you post diffs, as long as you don't reveal enuf of the source to make any difference. Context diffs between say, ls and tar are a no-no :-) (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 You should all JUMP UP AND DOWN for TWO HOURS while I decide on a NEW CAREER!! P.S. Henry, are you listening?
ed@mtxinu.UUCP (06/18/87)
>>I'd like to post the whole [new version of tip]. Is this BSD-only >>code? >I think so. Was it in 32V? Nope. It wasn't even in 4.1BSD. >>What are the licensing hassles if it is? Obviously if it's ATT-derived, >>I can only post diffs, >And maybe not even those. >>but what about BSD-pure stuff? >It is my impression (note key word) that Berkeley does not care >how much their stuff gets redistributed as long as it stays marked >`this neat software is by Berkeley, and if you fund us, we will >write code for your machine too' :-) . The license between the Regents of the University of California and the party to which they supply a 4BSD distribution does not distinguish anything as to its origin. The UC license states that the licensee will treat *all* of the material received under that license *as if* it had been received from AT&T, under the terms of the licensee's AT&T source license. Redistributing it without sufficient care is a violation of one or both of those licenses. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
dhesi@bsu-cs.UUCP (06/19/87)
In article <447@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >The license between the Regents of the University of California and >the party to which they supply a 4BSD distribution does not distinguish >anything as to its origin. The UC license states that the licensee >will treat *all* of the material received under that license *as if* >it had been received from AT&T, under the terms of the licensee's >AT&T source license. Redistributing it without sufficient care is a >violation of one or both of those licenses. Right. And this is why I think the BSD license agreement cries wolf, thereby undermining its own credibility. Schedule A, which lists the files that may not be distributed without AT&T's permission, includes /usr/src/new/mh/READ-ME. Here is an extract from this file: This version of MH is in the public domain, and as such, there are no real restrictions on its use. The MH source code and documentation have no licensing restrictions what- soever. As a courtesy, the authors ask only that you pro- vide appropriate credit to the Rand Corporation and the University of California for having developed the software. Now we are faced with a choice: Should we believe the BSD license agreement, which says this file is not in the public domain, or should we believe the file itself, which says it and a hundred others ARE in the public domain, except that we should as a courtesy provide proper credit to the Rand Corporation and the University of California? I'm confused. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
per@erix.UUCP (Per Hedeland) (06/23/87)
In article <655@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >In article <140@fesk.UUCP> sverre@fesk.UUCP (Sverre Froyen) writes: >#in article <651@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) says: >#> ... I was sufficiently disgusted with the ^A and ^P >#> behaviour that I hacked tip to have two new variables: >#Isn't this an overkill. A .tiprc file containing the two lines ># force= ># raisechar= >#has the same effect. > >Hmmm, I hadn't thought of that. Hmm-hmm, I *had*, only trouble is, it doesn't work... As the loud screaming from emacs users will make you realize, this will set both of 'force' and 'raisechar' to be ascii NUL! And (of course :-( ) 'raisechar' takes precedence, so you can't even "force" it. This is due to the fact that these variables are of the "character" type, and there isn't really a general way to unset character variables (the above would have worked for string variables). However, there is a workaround (pronounced "kludge"): Using the \ escape, it is possible to set a character variable to a value with bit 7 on, e.g. force=\377 and since bit 7 is stripped on tip's input, it will be effectively disabled. '~[set] all' will incorrectly tell you that ^? (aka DEL) is the current value of these variables, though (just as it will incorrectly tell you that they haven't got one if you try the proposal above...). > I can see an advantage to having it in the /etc/remote >file, since I can put :nf:nr: into the entry that all the other entries >:tc=: to, and have ^A/^P totally gone from my TIP. Among the many other things that remote(5) doesn't mention, is the fact that both 'force' and 'raisechar' may be set from /etc/remote (at least in 4.3BSD - am I violating our license by revealing it...?). The "capability" names are, by pure coincidence, equal to the "abbreviations" listed in tip(1); thus you can put :fo=\377:rc=\377: there to achieve this effect. --Per Hedeland per@erix.se or {mcvax,seismo}!erix!per PS. I *do* like tip, all the same...
dave@lsuc.UUCP (06/30/87)
In article <776@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <447@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: >>The license between the Regents of the University of California and >>the party to which they supply a 4BSD distribution does not distinguish >>anything as to its origin. The UC license states that the licensee >>will treat *all* of the material received under that license *as if* >>it had been received from AT&T, under the terms of the licensee's >>AT&T source license. Redistributing it without sufficient care is a >>violation of one or both of those licenses. > >Right. And this is why I think the BSD license agreement cries wolf, >thereby undermining its own credibility. Schedule A, which lists the >files that may not be distributed without AT&T's permission, includes >/usr/src/new/mh/READ-ME. Here is an extract from this file: > > This version of MH is in the public domain... > >Now we are faced with a choice: Should we believe the BSD license >agreement, which says this file is not in the public domain, or should >we believe the file itself, which says it and a hundred others ARE in >the public domain...? Regardless of whether the file is actually in the public domain, any two parties may agree by contract to treat it as proprietary, for the purposes of the contract. Obviously Berkeley chose not to go to the effort of labelling things as containing AT&T origins or not; it was far simpler to consider all of BSD as containing AT&T origins. Since the BSD license agreement, a binding contract entered into voluntarily by parties who knew what they were signing, says that you must treat all of BSD as proprietary, then you are bound by that agreement if your access to the files comes about as a result of the license. If you obtain a copy of MH, or whatever, through some source that does not involve a BSD license containing that limitation, then you can do with it as you wish. David Sherman (yes, I'm a lawyer, though I profess no particular expertise in this field) The Law Society of Upper Canada Toronto -- { seismo!mnetor cbosgd!utgpu watmath decvax!utcsri ihnp4!utzoo } !lsuc!dave