Bug 6867

Summary:	rxvt incorrectly(?) sets DISPLAY variable
Product:	[Retired] Red Hat Linux	Reporter:	grtllama
Component:	rxvt	Assignee:	Preston Brown <pbrown>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	6.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-01-14 02:48:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description grtllama 1999-11-10 00:49:50 UTC

I'm not sure if this is a bug or just an annoyance, but at
any rate...
rxvt sets the DISPLAY environment variable to unix:0.0
rather than just the local :0.0
It does this when no -display option is given to it.
I was using rxvt-2.6.1-1 from RedHat 6.1, and the same
problem seems to be present in rxvt-2.6.1-2 from Raw Hide.
Again, this may be some sort of intended behavior that just
seems odd to me, but I thought you should probably be
informed.

Thanks in advance,
Matt

Comment 1 Preston Brown 2000-01-14 02:48:59 UTC

unix:0.0 is a synonym for :0.0.  Trust us.

Comment 2 arr 2000-02-25 18:43:59 UTC

It *is* a bug, in particular the behaviour is inconsistent with the man page.
Note that if DISPLAY is set to :0.1 when rxvt is invoked, the rxvt window
still appears on Screen 0; to get reasonable behaviour, you need to use
rxvt -d $DISPLAY

Comment 3 grtllama 2000-03-01 13:35:59 UTC

The annoyance I found, although I was incorrect to blame rxvt, *is* still in
existance.  I suppose I could/should start a new bug, but if someone at redhat
is watching this...
Some (GTK) applications have trouble with the unix:0.0 DISPLAY variable.  I get
"can't resolve hostname unix!"  from a lot of GTK apps.  The workaround was to
undefine the compile-time option from rxvt (or just use -d, or ...) and I
assumed it was just an rxvt problem.
Next time I have an opportunity to reproduce this I'll send specifics.