On Wed, Sep 29, 1999 at 08:54:11PM -0400, Salman Ahmed wrote: > >>>>> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes: > Ben> Compilation was for i386 so it would run on more than just > Ben> pentiums. > > You mean for the initial install off of the CDs (or whatever) ?
No I mean when the actual binaries are compiled. > But where is this env. var being set from ? Currently, it is not > valid for my system since I am running a Celeron. This is not > much of an issue for me but it can cause confusion say for > makefiles that are used to build targets for different platforms. Most likely by the shell. No they wont mess up Makefiles since they should be using uname or better yet autoconf. > I would think that the make-kpkg scripts would update this > variable depending on how the kernel was configured. I mean the > scripts are intelligent enough!! make-kpkg does not do anything of the sort and shouldn't. > Ben> unix:0.0 means it's using a Unix Domain Socket, IIRC. UDS is for > Ben> local connections. > > Does Debian set the DISPLAY variable differently for a networked > machine ? I mean in a networked env, to allow remote X clients > to display to the local X server, the DISPLAY var would have to be > set to sth like $HOSTNAME:0.0 or $HOSTNAME:0. Ok, you aren't understanding this. X set's the DISPLAY var on a local startup. Other programs that login in remotely to other systems can send this over (ssh is a good example of one that automatically sets DISPLAY on logins to remote systems). You don't need to handle this manually. > Ben> /etc/environment is a good place. > > If I wanted to set the DISPLAY var to allow remote X clients to > display locally, would I set the DISPLAY var in /etc/environment > or in the users startup files eg .cshrc/.tcshrc/ ? You don't set the local DISPLAY in order to affect remote clients. It must be set on the remote client (again, using ssh to login to this remote system takes care of that). Ben
