Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!samsung!olivea!bu.edu!nntp-read!jc From: jc@raven.bu.edu (James Cameron) Newsgroups: comp.windows.x Subject: Re: Problems rsh'ing Message-ID: Date: 11 May 91 03:58:08 GMT References: Sender: news@bu.edu.bu.edu Distribution: comp Organization: What do you mean 'That *can't* be done????' Lines: 45 In-reply-to: jc@raven.bu.edu's message of 10 May 91 22:05:37 GMT I foolishly posted the following message without first reading TFM. The problem did not actually seem to be caused by 'rsh' so I guess that is why I didn't look. *8-) >>>>> On 10 May 91 22:05:37 GMT, jc@raven.bu.edu (James Cameron) said: |> Systems: Both are SunOS 4.1.1 |> Problem: What I would like to do is rsh into another machine and startup |> xbiff on this display. Now, this is what happens when I execute |> the rsh command: |> -jc- [formant: ~] % rsh raven "setenv DISPLAY formant:0;xbiff" & |> [1] 3383 |> -jc- [formant: ~] % |> [1] + Stopped (tty input) rsh raven setenv DISPLAY formant:0;xbiff |> -jc- [formant: ~] % fg |> rsh raven setenv DISPLAY formant:0;xbiff From rsh(1C): OPTIONS -n Redirect the input of rsh to /dev/null. You sometimes need this option to avoid unfortunate interactions between rsh and the shell which invokes it. Sorry for wasting the bandwith. jc -- -- James Cameron (jc@raven.bu.edu) Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 ------------------------------------------------------------------------------ "But to risk we must, for the greatest hazard in life is to risk nothing. For the man or woman who risks nothing, has nothing, does nothing, is nothing." (Quote from the eulogy for the late Christa McAuliffe.)