Re: Environment Variable weirdness
On Wed, Sep 29, 1999 at 08:54:11PM -0400, Salman Ahmed wrote:
> >>>>> "Ben" == Ben Collins <bcollins@debian.org> 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
Reply to: