gs26@prism.gatech.EDU (Glenn R. Stone) (08/12/90)
In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: > What I was thinking of doing was passing the magic-cookie [DISPLAY variable] >to the remote-end through another Telnet option. Has anyone else thought >about/done this (I didn't find a RFC)? Does any one have any comments >on the good/badness of this? This smells more like what rlogin does... Telnet doesn't need to be passing environment variables, since I might (and do, occasionally) be telnetting to a VMS machine, or (angels and ministers of grace defend us) a CYBER... Rlogin's Bugs section in TFM already says it should propogate more of the environment... how much more is open to debate, but it already says that rows and columns are supported on some systems.... hmmm.. p'raps there is a need for xrlogin, to propogate such neat things as color, stty settings, etc? I don't think all this info needs to be in the standard package, simply because the vast majority of what's going on out there is still being done on damn-3a's and Real PC's with a serial port out the back. (you wouldn't believe the number of old 4.77mHz boxes still being pounded on every day on this campus... but I digress.) If the env-variable passing is already there, it shouldn't be too hard to extend rlogin into xrlogin, and drop One More File into ..../contrib... -- Glenn R. Stone gs26@prism.gatech.edu
bob@MorningStar.Com (Bob Sutterfield) (08/13/90)
In article <12461@hydra.gatech.EDU> gs26@prism.gatech.EDU (Glenn R. Stone) writes: In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: What I was thinking of doing was passing the magic-cookie [DISPLAY variable] to the remote-end through another Telnet option. Has anyone else thought about/done this (I didn't find a RFC)? This smells more like what rlogin does... Telnet doesn't need to be passing environment variables, since I might be telnetting to a VMS machine, or a CYBER... Please don't use rlogin, which is a BSD-centric UNIXism, as a basis for anything. Instead, look at RFC1091 terminal type negotiation. The client might look at the environment to decide how to negotiate, but it shouldn't assume that the server knows or cares what an environment is. Clients on "environment"less machines should know other ways to find out what terminal types they're to claim to support.