Sun-Spots-Request@Rice.edu (William LeFebvre) (09/14/88)
SUN-SPOTS DIGEST Tuesday, 13 September 1988 Volume 6 : Issue 227
Today's Topics:
Re: Interleaf on 4.0
Re: Can someone give me a hand with color canvases
Interpreting ID PROM info
Bad interaction between put-then-get and emacs
*strange* behavior with termcap vb and su
sunos4.0 sendmail & uucp bwr
problem forwarding to program
Silly sendmail Question
Sun uucp @ 19.2k ?
Artecon 8mm tape drive?
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sat, 10 Sep 88 20:43:13 -0400
From: Henry B.J. Krempel <krempel@pacrat.npac.syr.edu>
Subject: Re: Interleaf on 4.0
This in response to Don Mosley's mail regarding packages that don't run on
4.0. Your story about Interleaf is a real horror story. I think we
should all boycott companies with attitudes like that.
Anyway, I have Interleaf (UPS 3.0.18) running on SunOs 4.0. The only snag
I found was in printing files. UPS sets up a number of entries in
/etc/printcap that define the filtering process that the files have to go
through before hitting the printer. Interleaf sets this up so that the
raw files are sent through the network to the remote printer. I found
that in 4.0, these raw Interleaf files weren't reaching the remote
printing station. So, I did the following:
1) deciphered the printcap, looking for the necessary filters. In the
interleaf install these were copied to each client in the local spool area
partition (yes YECHHHH). I looked for the original files, available on
shared NFS partitions (the right way).
2) set up the printcap so that files were translated on the local station
into PostScript before being sent to the remote printer (this also means
that Non SUNS can have printers on them, since you're just sending off
PostScript).
3) There were a few hard coded path names in the Interleaf code, so there
still were certain files that had to be located in each stations local
spool area, so in the end, I ended up with a single shared copy of
printcap (the way I like it, maybe Interleaf doesn't), and to set up all
of the spool areas, I made a tar file of the one station where I had it
set up correctly, and then un-tared it on each of the clients (there's
probably be a better/fancier way with rdist)
Anyway, we're looking at Frame (with the new network server license) maybe
you should.
This solution may only work for the version I have (and may also depend on
having a PostScript printer). Also, due to limitations of lpd, mentioned
here earlier, large PostScript files (over 1M?) must be printed on the
printstation. If anyone wants more details, I'd be happy to sent them off
individually.
Henry B. J. Krempel <krempel@pacrat.npac.syr.edu>
Northeast Parallel Architectures Center (NPAC)
Syracuse University
250 Machinery Hall
Syracuse, N.Y. 13244
------------------------------
Date: Sun, 11 Sep 88 06:31:22 CDT
From: vixen!ronbo@cs.utexas.edu (Ron Hitchens)
Subject: Re: Can someone give me a hand with color canvases
In V6n210 Anne Becker (anne@cvl.umd.edu) described a problem with retained
color canvases not repainting properly. The solution to this is quite
simple, once you understand what's going on.
> Am I overlooking something blatantly obvious?
No, you're overlooking something blatantly obscure.
You're stumbling across a mis-feature of SunView, namely the rather goofy
method it uses to determine how deep to make the backing memory pixrect
for a retained pixwin. So far as I know, this rule was undocumented until
the 4.0 SunView manual. Luckily, someone finally realized this
information may be useful and the following paragraphs appear on page 72
of the 4.0 SunView Programmer's Guide:
Color in Retained Canvases
If the canvas is retained, then the colormap segment must be set
*before* CANVAS_RETAINED is set to TRUE. This is because the canvas
package will determine the depth of the backing pixrect based on the
depth of the colormap segment defined for the WIN_PIXWIN. (If the
colormap segment depth is greater than two, then the full depth of
the display will be used. Otherwise, the backing pixrect depth will
be set to one.)
Since the depth of the backing pixrect is determined when the canvas is
created, you must create the canvas with CANVAS_RETAINED FALSE, then
set the colormap segment, then set CANVAS_RETAINED to TRUE.
Color in Scrollable Canvases
If the canvas has scrollbars, you need to attach the scrollbars to
the canvas *after* the colormap segment has been changed. If the
canvas has already been created with scrollbars attached, you should
change the colormap, then re-attach the scrollbars. This will insure
that the scrollbar pixwin regions use the new colormap segment.
Please note that this does not apply only to 4.0, but to all versions of
SunView, it was simply not documented until 4.0 (unless I missed it in a
post-3.2 manual).
Now, with the above information in mind, let me explain in a little more
detail what's happenning. First of all, you create a retained canvas, and
because you're making it retained at the time it's being created you're
getting a one bit deep backing pixrect. The tool starts up with a default
two entry colormap, even if you set different colors with -Wf and -Wb it
still only has two colors, which can be represented with a one-bit-deep
pixrect. The canvas will inherit either the frame's colormap, or the
default monochrome colormap depending on whether you specified
FRAME_INHERIT_COLORS. Both have only two entries.
So, at this point you have an eight bit deep display window being backed
by a one bit deep memory pixrect. Let's pause here and note that you can
raster-op one bit deep pixels into an eight bit deep pixrect (or pixwin)
but not vice versa, nothing happens. When you draw into a retained
pixwin, the raster operations are performed twice, once into the pixwin
and once into the backing memory pixrect. Then, when the pixwin needs
repainting, the damaged area is raster-op'ed directly from the backing
memory pixrect back into the pixwin.
The problem you're experiencing is not that repainting isn't being done
properly, it is. The probem is that the eight bit deep pixels you wrote
into the pixwin were never written into the backing memory pixrect,
because it's only one bit deep. Eight -> one is not a legal operation.
To further cloud the issue, it's entirely possible that some operations,
such as drawing text, will work. That's because text cells are only one
bit deep, and would make it into both the pixwin and the backing memory
pixrect. But, anything from an eight bit deep source will not have been
saved in the backing pixrect, and so will not be repainted.
Hope that helps. Page 73 of the 4.0 Sunview manual gives an example of
how to create a retained color canvas. I won't type the whole thing in,
it boils down to this:
canvas = window_create (frame, CANVAS,
CANVAS_RETAINED, FALSE,
<other canvas attributes>,
0);
<set the colormap segment for BOTH the WIN_PIXWIN and CANVAS_PIXWIN
of canvas, to keep them in sync (the two pixwins are really the same
as far as color is concerned, colormaps apply to windows, but you want
the two pixwin data structures to be consistent with each other). Use
the same name and colormap for both>
window_set (canvas,
CANVAS_RETAINED, TRUE,
WIN_VERTICAL_SCROLLBAR, scrollbar_create (0),
WIN_HORIZONTAL_SCROLLBAR, scrollbar_create (0),
0);
Ron Hitchens ronbo@vixen.uucp hitchens@cs.utexas.edu
------------------------------
Date: Mon, 12 Sep 88 08:07:08 EDT
From: steve@umiacs.umd.edu (Steven D. Miller)
Subject: Interpreting ID PROM info
Basically, the number you get back from gethostid() is the machine type
(high eight bits) or'ed with the serial number. The high four bits of the
first byte of the address indicate whether you're dealing with a Sun-2 (0)
or a Sun-3 (1). The low four bits of that same byte give more information
on the machine type:
(Sun-3) (Sun-2)
1 - 3/160 1 - 2/120 (or other generic Multibus)
2 - 3/50 2 - 2/50 (or other generic VMEbus)
3 - 3/260
4 - 3/110
7 - 3/60
8 - Eurocard Sun-3
For example, my machine's hostid is 17001343, so it is a Sun-3 of flavor
3/60, serial number 1343.
For future machines and architectures, look in cpu.h in the proper
hardware-specific (i.e., sun2, sun3, or sun4; I don't know about 386i's)
subdirectory of /usr/include. There'll be something there about the
architecture near the top (i.e., SUN3_ARCH is defined to be 0x10, like I
imply above), and the different machines and corresponding types should be
listed below that.
-Steve
Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
------------------------------
Date: 10 Sep 88 21:32:01 GMT
From: phri!roy@philabs.philips.com (Roy Smith)
Subject: Bad interaction between put-then-get and emacs
When you do a put-then-get in suntools which spans multiple lines, the
line separators that get fed to the window are \n's, not \r's. This is
bad if you are trying to put-then-get into emacs. The default bindings
for those two characters (at least in the emacs we use) are:
\n ^R Indent New Line
\r ^R CRLF
The result is that if you stuff more than one line, the second and
following lines are all indented. The usual way we fix it is to just
rebind \n to be "^R CRLF" just like \r, but that looses for people who
really use the functionality of "^R Indent New Line" (like for
auto-indenting in C mode). What I would rather see is to have
put-then-get use \r as the line delimiter, and let the tty driver either
do \r to \n mapping if requested (as it usually is for normal shell
windows) or pass the \r straight through when in RAW mode (like with
emacs).
Is there any way to make suntools do this? Is the current behavior a bug
or simply something which doesn't agree with my personal view of how the
world should be?
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
------------------------------
Date: Sat, 10 Sep 88 01:06:23 EDT
From: stpstn!aad@philabs.philips.com (Anthony A. Datri)
Subject: *strange* behavior with termcap vb and su
I've discovered some rather baffling behavior on a sun 3 running 3.2. I'm
using a DEC gigi terminal, and I've hacked my own termcap entries,
including one with a visible bell (vb) field, *but no explicit bl field*.
If I su, and set filec, the vb field seems to work! I hit escape, and it
does the vb sequence, and it doesn't beep! Several people have told me
that there isn't any way this should be happening, but it happens!
I also notice that here there seem to be a couple of undocumented stty
options -- noflsh, nopost, noisig. All seem to be -'ed, ie., I normally
have -noflsh, -nopost, and -noisig show up in `stty everything`. Can
someone enlighten me on those options? None of them seem to control the
visible bell entirely, but I do notice that if I stty noisig, the vb
sequence takes longer -- the screen changes, stays, then changes back.
I should note that the vb working as noted above seems to work when I su
to *anyone*, not just root.
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
Date: Sun, 11 Sep 88 19:47:39 EDT
From: stpstn!aad@philabs.philips.com (Anthony A. Datri)
Subject: sunos4.0 sendmail & uucp bwr
It seems that Sun has really confused things in their reorganization of
the directory structure in 4.0. Sendmail now looks for sendmail.cf in
/etc, *not* /usr/lib. Okay, so I look at the man page, and *it* says
/etc/sendmail.cf. So the manual says that too, but it took me two weeks
to figure this out. The templates are still kept in /usr/lib. The
sendmail executable contains both the strings /etc/sendmail.cf and
/usr/lib/sendmail.cf close to each other -- I suspect that it'll check for
the latter in the absence of the former.
So on that I can't *really* blame Sun. I should have R'd TFM. The reason
why I didn't RTFM is that TFM is now a mishmash of 3.x and 4.0 isms, at
least in the various uucp and sendmail documents, and I figured "They're
confused as far as documentation, I'll just go by what the files say".
Here's where I didn't catch the move of sendmail.cf, even though it now
proves to have been documented. This move does make sense to me now,
since under 3.2 I wasn't real happy that diskless machines shared the
server's configuration files (like sendmail.cf, crontab). For example,
page 377, Chapter 15 of the "System & Networking Administration" says that
domains are defined with DD and CD, which seems to be the 3.x style, while
the 4.0 sendmail.cf file uses Dm. There is also a mixture of old-style
/usr filenames and new-style /var filenames, inconsistent. So be verwy
verwy kwaaaaarfyl when reading these documents.
So, in summary, I should kick myself for not seeing the move, but I felt
obligated to help others avoid the same mistake.
Mail to sun!hotline has met with no response. I'd call them up about the
documentation errors, but I can imagine the runaround I'd get. Maybe I'll
fill out a DEC spr form and send it to them.
Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
------------------------------
Date: Sat, 10 Sep 88 20:51:12 -0400
From: Henry B.J. Krempel <krempel@pacrat.npac.syr.edu>
Subject: problem forwarding to program
In SunOs 4.0 we've been having a problem forwarding mail through a program
(like vacation). I've looked through the man page on vacation over and
iver, but what I get when the .forward is set up is a piece of return
mail with the error message:
cannot stat .
[[ Remember that a program such as vacation that is started by sendmail
will run as the user who sent the mail if that user is local, otherwise it
will run as "daemon". Perhaps the permissions on the recipient's home
directory are too restrictive? --wnl ]]
Henry B. J. Krempel <krempel@pacrat.npac.syr.edu>
Northeast Parallel Architectures Center (NPAC)
Syracuse University
250 Machinery Hall
Syracuse, N.Y. 13244
------------------------------
Date: Sun, 11 Sep 88 13:58:39 CDT
From: Frank W Peters <PETERS@MSSTATE.BITNET>
Subject: Silly sendmail Question
Hello,
I am new to the world of Suns and am having a problem. We have a 3/160
(running SunOS 4.0) that we would like to act as a mail drop for several
PCs on our network. We have been able to arrange (using MX domain records
and mailhost entries in /etc/hosts) to have all mail for the PCs sent to
the sun. Now, how do we arrange for the sun to NOT attempt to deliver the
mail?
In other words, what I'd like is for the sun to take any incomming mail
for peters@petersPC.msstate.edu and deliver it to local user peters. I
have made a few efforts to accomplish this with aliases but have not met
with stellar success.
Any help is appreciated. Please reply to me directly (I receive this list
in digested form only...and SLOWLY) and I will post replys to the list if
anyone is interested.
Thanks
Frank Peters
Bitnet: PETERS@MSSTATE.BITNET
Internet: PETERS%MSSTATE.BITNET@cunyvm.cuny.edu
------------------------------
Date: 9 Sep 88 15:37:01 GMT
From: sundc!tfd!kent@sun.com (Kent Hauser)
Subject: Sun uucp @ 19.2k ?
In trying to hook up a TrailBlazer+ modem to my Sun 3/60 (SunOS 3.5), I
found that Sun's uucico does not support 19200 baud operation. (Fastest
is 9600). Attempts to use 19.2k result in
ASSERT ERROR (uucico) BAD SPEED (-1)
Is there a way around this problem?
--
Kent Hauser UUCP: sun!sundc!tfd!kent
Twenty-First Designs Voice 202 872-1081
------------------------------
Date: Sun, 11 Sep 88 10:29:07 -0200
From: Joel Isaacson <joel@WISDOM.BITNET>
Subject: Artecon 8mm tape drive?
I would like some information on the Artecon 8mm tape system.
1.) Which 8mm tape drive is used.
2.) Does it work with a standard Sun Scsi driver?
3.) I would like to hear from users of this system.
Thank You
Joel Isaacson
joel@wisdom.bitnet
------------------------------
End of SUN-Spots Digest
***********************