lin@cs.wmich.edu (Lite Lin) (11/18/89)
I have a simple question. I understand that if I 'rlogin' to another host,
certain environment variables, such as TERM and maybe something else, will
be copied over to the new host, but I'm wondering whether I can pass on
other information to the new host as well, such as an environment variable
defined by myself. Any response will be appreciated. Thanks in advance.
Lite
--
We hold these truths to be self-evident, that all men are created
equal, that they are endowed by their Creator with certain unalienable
Rights, that among these are Life, Liberty and the pursuit of Happiness.
-- Declaration of Independencejik@athena.mit.edu (Jonathan I. Kamens) (11/21/89)
In article <696@cs.wmich.edu> lin@cs.wmich.edu (Lite Lin) writes: >I have a simple question. I understand that if I 'rlogin' to another host, >certain environment variables, such as TERM and maybe something else, will >be copied over to the new host, but I'm wondering whether I can pass on >other information to the new host as well, such as an environment variable >defined by myself. Any response will be appreciated. Thanks in advance. I don't believe there's any way to do this with the standard rlogin. However, there are a couple hacks you can do to make this possible. A couple people here at Athena have an rlogin shell script that sets the TERM variable to the name of the X display on which they are working before running the real rlogin. At the other end, their .cshrc or .login file checks to see if the TERM variable contains the name of a display instead of a terminal type, and if it does, DISPLAY is set to that type and TERM is set to xterm. If the variables you want to be able to pass are pretty constant, you can use this hack on any variable and do the "unparsing" of TERM in your .cshrc (or .profile, whatever :-) or .login at the other end. However, you have to keep in mind that rlogin only transfers a limited number of characters in TERM to the other side (64 characters, I think), so really long TERM values won't get transferred in their entirety. People have been talking about writing an rlogin that transfers arbitrary environment variables over the connection for a long time now. I wonder when it'll happen :-) Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
dce@smsc.sony.com (David Elliott) (11/21/89)
In article <1989Nov21.040936.10463@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > People have been talking about writing an rlogin that transfers >arbitrary environment variables over the connection for a long time >now. I wonder when it'll happen :-) SMOP = Small Matter Of Programming SMOC = Small Matter Of Commitment At a previous job, I modified rlogin and login to pass all kinds of data in both directions (all we used it for was to pass DISPLAY, and it never got further than a couple of machines). My modifications were such that both the modified rlogin and the modified login were completely compatible with unmodified versions. I posted a description of my changes to comp.unix.wizards and sent the description to the folks at Berkeley, but I never heard from a single soul. The basic problem is that the change involves login, since login destroys its environment at startup time. To get such a change out into the world would require the work of some influential group of people, and I'm not a member of any such group. For example, if Sun or AT&T put such a change into SVR4, it would be used. If Berkeley made these changes an "official" patch to 4.3BSD, as they did with setenv() and ADO's table-driven ctime stuff, it would be used. In fact, if MIT made this a standard part of the X release, it might well get used. In other words, it's a SMOP that requires a SMOC. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "It's bigger than a breadbox, and smaller than the planet Jupiter."
skwu@boulder.Colorado.EDU (WU SHI-KUEI) (11/22/89)
Once more already yet again, Jonathan is wroooong!!! System V (and even never made available Release 4 before it) 'login' allows setting environmental variables on the command line. MORAL: the world is more than just BSD, thank goodness.
dce@smsc.sony.com (David Elliott) (11/22/89)
In article <14137@boulder.Colorado.EDU> skwu@boulder.Colorado.EDU (WU SHI-KUEI) writes: >Once more already yet again, Jonathan is wroooong!!! System V (and even >never made available Release 4 before it) 'login' allows setting >environmental variables on the command line. I'm confused. Are we talking about the same thing? I don't even see 'login' mentioned in Jonathon's article. Maybe you could explain how having a version of login that allows setting of environment variables on the command line relates to the problem with rlogin not passing them. Maybe the real moral is that the world is not all System V? -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "It's bigger than a breadbox, and smaller than the planet Jupiter."
chris@mimsy.umd.edu (Chris Torek) (11/22/89)
In article <14137@boulder.Colorado.EDU> skwu@boulder.Colorado.EDU (WU SHI-KUEI) writes: >Once more already yet again, Jonathan is wroooong!!! System V (and even >never made available Release 4 before it) 'login' allows setting >environmental variables on the command line. And in the process, opens a number of security holes. >MORAL: the world is more than just BSD, thank goodness. Right: how else could we have something to compare against that makes us look so good? :-) (Actually, under 4.3BSD, `login -p' preserves the environment. As always, it must be used with care.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
merlyn@iwarp.intel.com (Randal Schwartz) (11/23/89)
In article <1989Nov21.040936.10463@athena.mit.edu>, jik@athena (Jonathan I. Kamens) writes: | I don't believe there's any way to do this with the standard rlogin. [describes a couple of hacks...] | People have been talking about writing an rlogin that transfers | arbitrary environment variables over the connection for a long time | now. I wonder when it'll happen :-) Of course, if the source and target machines have shared NFS-mounted home directories, you can do something like: ( printenv | sed 's/\(.*\)=\(.*\)/setenv \1 \2/' >~/.$$ setenv TERM ~/.$$ rlogin foosys ) and in .login, have: switch ($TERM) case /*: set x=$TERM; source $x; rm -f $x breaksw endsw Of course, I've glossed over: (1) metachars in the ~.$$ file (2) not passing *all* the environment (3) this untested code not working but you can see the general idea. Just another multiple system hacker, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/