That rings a bell, like maybe I did it sometime in the past. I do think I once had this working.
To answer Matt's question: nope, same behavior. Based on what John said, that's what I'd expect. Thanks, both. On Wed, Mar 4, 2015 at 1:23 PM, Gibson, John <[email protected]> wrote: > Michael, > > The easiest way to fix the issue is to modify the startprefix script to > keep the DISPLAY variable. > > The changes will look something like this: > diff -wu startprefix.orig startprefix > --- startprefix.orig 2015-03-04 14:20:28.000000000 -0500 > +++ startprefix 2015-03-04 14:20:39.000000000 -0500 > @@ -39,7 +39,7 @@ > # start the login shell, clean the entire environment but what's needed > # PROFILEREAD is necessary on SUSE not to wipe the env on shell start > [[ -n ${PROFILEREAD} ]] && DOPROFILEREAD="PROFILEREAD=${PROFILEREAD}" > -env -i HOME=$HOME TERM=$TERM USER=$USER SHELL=$SHELL $DOPROFILEREAD > $SHELL -l > +env -i HOME=$HOME TERM=$TERM USER=$USER SHELL=$SHELL DISPLAY=$DISPLAY > $DOPROFILEREAD $SHELL -l > # and leave a message when we exit... the shell might return non-zero > # without having real problems, so don't send alarming messages about > # that > > > John > > On Mar 4, 2015, at 2:18 PM, Matt Hull <[email protected]> wrote: > > I have not used prefix on OSX in several years. Does it help to start > an X app from the OSX X11Terminal ? I though I had to do that. But then > the question is should that be the correct way or should a prefix X server > or client be used ? > > matt > > On Wed, Mar 4, 2015 at 1:10 PM, Michael Jinks <[email protected]> > wrote: > >> File this under "problems I'll probably fix myself the moment I hit >> 'send' on an email"... >> >> I'm using prefix on my OSX laptop, typically by starting an xterm and >> running startprefix. But when I do that, my $DISPLAY isn't inherited, so X >> apps obviously don't run. In cases like that, my usual hack is to ssh in >> with X11 forwarding (-Y), but my laptop isn't running sshd. More to the >> point, that seems like the wrong way to address this issue; why have all >> that overhead encrypting a connection to localhost? If memory serves, ssh >> used to support an option for cipher "none", but I don't find that in any >> manpages now. >> >> There has to be a better way...? >> >> Thanks. >> >> > >
