jerryp@cmx.npac.syr.edu (Jerry Peek) (12/12/88)
One thing bugs me about "rlogin": the only environment variable it'll pass to the remote machine is TERM. I want to pass more. I've thought about a hack to do the job. I'd write a shell script named rlogin. It would check the remote host name in a table -- if my account on the remote host was set up to understand this hack, the rlogin script would pack a bunch of envariables into TERM, with a special VARSET: flag at the start, like this: TERM="VARSET:REAL_BAUD=2400:SUNVIEW=no:LOGIN=quick:TERM=sun-cmd" The .cshrc (.login?) file on my remote account would test TERM. If TERM started with the flag (VARSET:), it'd parse the string and eval the envariables into the remote shell and reset TERM to a sensible value. Anybody found a better way? Problems? How many characters can I squeeze into the TERM string? (I'm on BSD-type systems: Sun, VAX/ULTRIX, Multimax, Alliant.) Thanks. --Jerry Peek, Northeast Parallel Architectures Center, Syracuse, NY jerryp@cmx.npac.syr.edu +1 315 443-1722
dce@mips.COM (David Elliott) (12/14/88)
In article <899@cmx.npac.syr.edu> jerryp@cmx.npac.syr.edu (Jerry Peek) writes: >One thing bugs me about "rlogin": the only environment variable it'll pass >to the remote machine is TERM. I want to pass more. {common, useful solution to problem deleted} >Anybody found a better way? Problems? How many characters can I squeeze into >the TERM string? (I'm on BSD-type systems: Sun, VAX/ULTRIX, Multimax, Alliant.) You can generally only put 64 characters, since that's how large term[] is in login on BSD. I sent a proposal for an extension to the rlogin protocol to Berkeley a month or two ago, but they've been to busy to answer. The data field sent to contain the terminal type and line speed may optionally end with a /, and login ignores the trailing information. So, my idea was to follow this / with a magic cookie. If the login command understands this cookie, it sends back another cookie as its first output, and rlogin, seeing this reply, sends across a set of resource/value pairs. The most common resource/value pair would be environment variables, but other things, such as limits or nice value (not allowing a user to raise such values, of course), could be sent. The advantage to such a system is that it doesn't break when used with old versions of rlogin and login. If rlogin doesn't send the cookie, login won't reply. If login doesn't understand the cookie, it won't reply, and so rlogin won't send the extra data down the line. In addition, my proposal said that the magic cookie value would contain a protocol version number, which, if the inventor(s) of rlogin had done in the first place, this (admittedly a hack) solution would be unnecessary. -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce "Did you see his eyes? Did you see his crazy eyes?" -- Iggy (who else?)
norm@oglvee.UUCP (Norman Joseph) (12/15/88)
From article <899@cmx.npac.syr.edu>, by jerryp@cmx.npac.syr.edu (Jerry Peek): > One thing bugs me about "rlogin": the only environment variable it'll pass > to the remote machine is TERM. I want to pass more. > ... like this: > > TERM="VARSET:REAL_BAUD=2400:SUNVIEW=no:LOGIN=quick:TERM=sun-cmd" > > --Jerry Peek, Northeast Parallel Architectures Center, Syracuse, NY > jerryp@cmx.npac.syr.edu > +1 315 443-1722 At the last company I worked for, we ran into a similar situation with rlogin between VAXen running Ultrix and HP3000s running HP-UX. This was the solution we came up with also (almost to the letter!). If memory serves, the length of the TERM variable varied between machines, and I believe we could not count on a length of more than 16-20 chars to get through rlogin. Of course some simple experimentation should give the answer in your situation. If you're stuck with a short string, you'll have to come up with some kind of encoding that both sides will understand. This may create dependencies that you may not want or need. Good luck. Norm \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\*////////////////////////////////////// Norm Joseph | UUCP: ...!{pitt,cgh}!amanue!oglvee!norm Oglevee Computer System, Inc. | "Everything's written in stone, until the Connellsville, PA 15425 | next guy with a sledgehammer comes along." /////////////////////////////////////*\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
rsm@amethyst.ma.arizona.edu (Robert Maier) (12/18/88)
In article <899@cmx.npac.syr.edu> jerryp@cmx.npac.syr.edu (Jerry Peek) writes: > One thing bugs me about "rlogin": the only environment variable it'll pass > to the remote machine is TERM. I want to pass more. > ... like this: > > TERM="VARSET:REAL_BAUD=2400:SUNVIEW=no:LOGIN=quick:TERM=sun-cmd" > The undocumented RLOGIN protocol apparently made (makes?) some provision for this. After rlogin opens the connection to the rlogin daemon, the first bytes sent across to the daemon are: \0 remote_username\0 local_username\0 terminal_info\0 i.e., a null followed by three null-terminated strings. The terminal_info string is of the form terminal_type[/speed][/something] i.e. the desired TERM variable, optionally followed by a literal slash and the line speed, optionally followed by a literal slash and some further string of characters. In the BSD4.3 rlogind.c the terminal_info string is stored in a 64-byte buffer. So there's lots of room left for the "something". But whatever it is, it's ignored. And the BSD4.3 rlogin.c doesn't send the optional "/something" at all. Is it possible that "/something" was put into the protocol as a way of propagating more terminal characteristics? Comments, anyone? -- Robert S. Maier SNAIL: Dept. of Math.; Univ. of Arizona; Tucson, AZ 85721; USA VOICE: +1 602 621 6893 / +1 602 621 2617 UUCP: ..{allegra,cmcl2,hao!noao}!arizona!amethyst!rsm BITNET: maier@arizrvax INTERNET: rsm@amethyst.ma.arizona.edu