Path: utzoo!attcan!uunet!lll-winken!xanth!ukma!tut.cis.ohio-state.edu!bloom-beacon!DSYS.ICST.NBS.GOV!rbj
From: rbj@DSYS.ICST.NBS.GOV (Root Boy Jim)
Newsgroups: comp.windows.x
Subject: xlsfonts does, sort of, xterm doesn't
Message-ID: <8904061829.AA07362@dsys.icst.nbs.gov>
Date: 6 Apr 89 18:29:09 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: National Institute of Standards and Technology
	formerly National Bureau of Standards
Lines: 29

? From: rws@expo.lcs.mit.edu (Bob Scheifler)

? The gurus are all exhausted.

Understandable :-)

?     ? I found that somewhere around 4K (pipe size limit?) was about all I
?     ? could get out of xlsfonts without it dying or being killed.

? We don't see this problem on various OSes here (we don't have SunOS 3.5).  We
? have various bug reports for various OSes saying the server is failing to
? handle their OS's particular braindamaged error return for the write(v) system
? call when various preconceived kernel implementor's notions of how the call
? should work aren't met.  It's hard to believe there are so many different
? semantics applied to this call, and so many weird interpretations placed on
? errors (e.g., returning EWOULDBLOCK is the data is "too big"; geez).  (Now
? add SYSV signals and stir ...)  It's almost enough to make one want to attend a
? POSIX meeting.

Or perhaps an X/Open meeting, or if you're real desparate, OSF :-)

I have more information on what my problem is; UNIX domain sockets.
If I set my DISPLAY to dsys:0 it works fine, but unix:0 dies.
If I use localhost:0 it works too.

Thanks for all the help.

	Catman Rshd <rbj@nav.icst.nbs.gov>
	Author of "The Daemonic Versions"