Sun-Spots-Request@Rice.edu (William LeFebvre) (10/24/88)
SUN-SPOTS DIGEST Sunday, 23 October 1988 Volume 6 : Issue 271 Today's Topics: Administrivia: Volume 6 index now split into two files Re: failed login requests Re: Nfs mounted /usr/spool/mail Re: MX sendmail for Sun OS 3.5 Re: wanted: more interesting screen saver `bmx' - Bitmap Conversion Utility ALM2's and modems: Sun patch exists selection_svc in SunView Selection library error YP file in SUNOS4.0 Suntool background screens Problems with 'pw_line()' under 4.0 Problem with Textsw windows Over-eager uucp callback? IBM 3180 terminals on Suns? When will sun have ANSI-ish C compilers? 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: Fri, 21 Oct 88 16:56:15 CDT From: William LeFebvre <phil@Rice.edu> Subject: Administrivia: Volume 6 index now split into two files Because of the overwhelming size of the Volume 6 index, I have also made it available as two separate files. All three files are available in the archives under "sun-spots". Here is a current list (the sizes are sure to increase on a regular basis): 133721 Oct 19 12:44 v6.index 65477 Oct 19 13:18 v6.index.a-m 68244 Oct 19 13:18 v6.index.n-z The second file contains subjects that start with the letters A through M (case insignificant). Similarly for the third file (N through Z). William LeFebvre ------------------------------ Date: Tue, 18 Oct 88 17:28:53 EDT From: rang@cpsin3.cps.msu.edu (Anton Rang) Subject: Re: failed login requests We maintain a log of failed logins using a modified /bin/login (we got the source from somewhere, no idea where). If you can find the source, that's the easiest thing to do. I don't think there's any other way. Anton Rang rang@cpswh.cps.msu.edu ------------------------------ Date: Tue, 18 Oct 88 20:07:09 CDT From: thompson@umn-ai.cs.umn.edu (William B. Thompson) Subject: Re: Nfs mounted /usr/spool/mail Sharing /usr/spool/mail is a bit more complicated than it might first appear. (There was an extensive discussion of this problem in SunSpots a year or so back.) One set of problems has to do with getting file locking to work correctly. A second set of problems has to do with getting "local" mail delivered correctly. A recently posted proposal suggests replacing the "local" mailer defined in sendmail.cf with a "relay" mailer that forwards the local mail to some central place. > # Instead of calling local mailer, call gateway mailer and pass to > # gateway machine: > #R$+ $#local $:$1 local names > R$+ $#$M $@$R $:$1 local names This works rather well, except that the full name of the sender disappears from the "from" field!. It turns out that /usr/lib/sendmail uses a truly bizzard method for determining whether or not to define the full-name macro that sendmail.cf stuffs into the from field. The short story is that any address specifying a user but no system must parse to a mailer with a name spelled "l-o-c-a-l". Thus, to get the desired effect you must redefine the local mailer, not just call a different mailer. William B. Thompson University of Minnesota ------------------------------ Date: 18 Oct 88 14:00:31 PDT (Tuesday) From: "Lennart_Lovstrand.EuroPARC"@xerox.com Subject: Re: MX sendmail for Sun OS 3.5 Randall, The "precompiled sendmail" for Sun-3/SunOS 3.5 was made using Berkeley's sendmail 5.59 with the IDA Enhancements added and linked with bind 4.8's libresolv.a and Sun's syslog.c (recompiled with bind's include files). Note that this will result in a different executable than the one Sun supplies, so IDA's sendmail is not directly compatible with Sun's -- eg, it does not support the $%x and ${...$} YP macros, but has a slightly different YP lookup scheme using the $(...$) construct with defaulting. Source for sendmail 5.59 and bind 4.8 is available in ~ftp/4.3 on ucbarpa.berkeley.edu; the IDA patches &c are available from arisia.xerox.com in ~ftp/pub1. Enjoy! --Lennart ------------------------------ Date: Wed, 19 Oct 88 18:28:49 EDT From: bunny!rhb6@harvard.harvard.edu (Robert H. Barkan) Subject: Re: wanted: more interesting screen saver I use a combination of overview(1), and Jim Wang's "crabs" (from net.sources in '86) in black background mode. In normal suntools: overview -Wg -Wb 0 0 0 -Wf 1 1 1 crabs -g5 or simpler, in inverted mode (suntools -i): overview crabs -g5 I also wrote a screen blank driver program. It's similar to screenblank(1), in that it'll run a screen blanker after a specified mouse/kbd idle time. But unlike screenblank, you can activate/deactivate it from the suntools menu. In addition, you can tell it what blanker to run. If anyone's interested, I'll post it. Bob Barkan rhb6%bunny@harvard.harvard.edu GTE Laboratories rhb6@gte.com 40 Sylvan Rd Waltham, MA 02254 ------------------------------ Date: Tue, 18 Oct 88 12:07:07 PDT From: gandalf@csli.stanford.edu (Juergen Wagner) Subject: `bmx' - Bitmap Conversion Utility Finally, `bmx' has been submitted to comp.sources.unix. `bmx' is a bitmap conversion tool which supports 20 format families, and which allows easy extension. TIFF and FAX formats are about to be ready. `bmx' is also available via anonymous ftp from csli.stanford.edu (#36.9.0.46) from pub/Gandalf. In exceptional cases, I am willing to mail a copy. Juergen "Gandalf" Wagner, gandalf@csli.stanford.edu Center for the Study of Language and Information (CSLI), Stanford CA ------------------------------ Date: Tue, 18 Oct 88 21:17:01 PDT From: Mathew Atkins <hqpyr1!oracle!matkins@hplabs.hp.com> Subject: ALM2's and modems: Sun patch exists A couple of days ago I posted a request for help regarding the fact that I couldnt get either a microcom or a trailblazer to work propperly on our sun4 running 4.0. I received a few replies. Thank you. They are appreciated. As it turns out....The solution to my quagmire was applying a patch for the ALM2 supplied by sun. The moral: If your trying to attach modems to ALM2 based ports, GET THE SUN PATCH. Thanks again for the help. -Mat matkins%oracle.uucp@hplabs.hp.com ------------------------------ Date: Tue, 18 Oct 88 15:45:28 CDT From: feuerman@symcom.math.uiuc.edu (Ken Feuerman) Subject: selection_svc in SunView We've been experiencing an annoyance since upgrading to OS 4.0. In SunView, when executing some commands (such as delivering mail from the mail tool), a message appears in the CONSOLE window: Selection service couldn't open selection file: Permission denied filename: "/tmp/textsw_shelf" The problem stems from the fact that with SunView, the selection_svc is run under the user id of whomever happens to run SunView first on a particular machine after booting (it is never halted upon exiting SunView). Someone else comes along, runs SunView, and suddenly the message starts appearing (because the new user owns /tmp/textsw_shelf, and its protection is -rw-r-----). Has anyone found a reasonably secure (i.e., NOT setuid=root) fix for this? --Ken. (feuerman@symcom.uiuc.math.edu) ------------------------------ Date: 19 Oct 88 17:42:03 GMT From: bob@ack.cgrg.ohio-state.edu (Bob Marshall) Subject: Selection library error Since upgrading to 4.0, we get this message when selecting text with the mouse: Couldn't get current holder from service: RPC: Timed out Selection library internal error: Service wouldn't let us acquire selection requested 5; result: 0 The timeout period is about 10 seconds? Any ideas? Bob Marshall bob@ack.cgrg.ohio-state.edu ------------------------------ Date: Tue, 18 Oct 88 15:54:31 CDT From: drl@vuse.vanderbilt.edu (David R. Linn) Subject: YP file in SUNOS4.0 I vaguely remember that, under SUNOS 4.0, there is a reserved file descriptor for YP. One reference claimed that it was fd #4 (which I hope was an off-by-one mistake). I am trying to get the ksh-i (from 6/3/86) built for 4.0 and wonder what changes are needed above and beyond those needed for 3.X. David ------------------------------ Date: Tue, 18 Oct 88 18:06:08 EDT From: Michael Nora <mwn@mike.ufnet.ufl.edu> Subject: Suntool background screens Does anybody keep a collection of suntool background screens that are available via anonymous ftp? We only have 5 different ones and they're getting rather boring. E-mail replies so as not to clog up the newsgroup. Thanx. Michael Nora mwn@mike.ufnet.ufl.edu ------------------------------ Date: 18 Oct 88 22:01 +0800 From: James Uhl <juhl%csr.UVic.cdn@relay.ubc.ca> Subject: Problems with 'pw_line()' under 4.0 There seem to be major problems with the textured line drawing routines (pw_line(), pw_polyline(), pr_line()) under 4.0. Under 3.X, using these functions involved simply declaring two structures: a 'Pr_brush' and a 'Pr_texture'. Before using them, it was necessary to initialize the width field of the brush structure to the desired width and set the pattern field of the texture structure to one of the pr_tex_* arrays defined in <pixrect/pr_line.h>. Then, passing pointers to these two structures to one of the above named routines would draw the desired line type. Also, by passing in NULL for the Pr_texture structure resulted in a solid line of the desired width (see example at the end of this message). Under 4.0(EXPORT), however, the call to pw_line above only works properly if MyTexturePtr is NULL (and with a large enough width, even that will crash!). However, passing in a pointer to a Pr_texture initialized as above does one of several things: 1. Bus error - when this happens, dbxtool returns the following: attempt to read stack failed - bad frame pointer signal BUS (bus error) in pr_texvec at 0xecd92aa 0xecd92aa: rts 2. a solid line is drawn - but at about a third the speed of when passing NULL in for the Pr_texture pointer 3. if the line is horizontal (or vertical), the width is large (say, 64), and the pattern field has points to the pr_tex_dashdotdotted array, the program goes into a state of "deep thought", very slowly drawing horizontal (or vertical) lines. Compiling with -Bstatic (after a little library cleanup - as noted, we are running the dreaded EXPORT version of 4.0), gives one unresolved external, and a huge executable (larger than under 3.X!) that works properly after doing a chmod. Jim Uhl (juhl@csr.UVic.{ca|cdn}) ------------------------- pw_line.shar - cut here ------------------------- #!/bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #!/bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # makefile # pw_line.c # This archive created: Tue Oct 18 14:12:30 1988 export PATH; PATH=/bin:$PATH if test -f 'makefile' then echo cshar: over-writing existing file "'makefile'" fi sed 's/^X//' << \SHAR_EOF > 'makefile' Xpw_line: pw_line.o X cc -o pw_line pw_line.o -Bstatic -lsuntool -lsunwindow -lpixrect X Xpw_line.o: pw_line.c X cc -c pw_line.c SHAR_EOF if test 124 -ne "`wc -c 'makefile'`" then echo cshar: error transmitting "'makefile'" '(should have been 124 characters)' fi if test -f 'pw_line.c' then echo cshar: over-writing existing file "'pw_line.c'" fi sed 's/^X//' << \SHAR_EOF > 'pw_line.c' X#include <suntool/sunview.h> X#include <suntool/canvas.h> X#include <pixrect/pr_line.h> X XPixwin *pw; XPr_texture tex, *texptr; XPr_brush br, *brptr = &br; X Xstatic void draw_lines(texture) Xshort *texture; X{ X static int j = 40; X int i, w; X X if (texture == NULL) texptr = NULL; X else { X tex.pattern = texture; X texptr = &tex; X } X X for (i = 0, w=1; i < 6; i++, w <<= 1) { X br.width = w; X pw_line(pw, 20 + i*100, j, 90 + i*100, j, brptr, texptr, X ((PIX_SRC^PIX_DST)^PIX_COLOR(1))); X } X j += 60; X} X Xmain() X{ X Frame frame; X Canvas canvas; X X frame = window_create(NULL, FRAME, 0); X canvas = window_create(frame, CANVAS, 0); X pw = canvas_pixwin(canvas); X X draw_lines(NULL); X draw_lines(pr_tex_dotted); X draw_lines(pr_tex_dashed); X draw_lines(pr_tex_dashdot); X draw_lines(pr_tex_dashdotdotted); X draw_lines(pr_tex_longdashed); X X window_main_loop(frame); X exit(0); X} SHAR_EOF if test 860 -ne "`wc -c 'pw_line.c'`" then echo cshar: error transmitting "'pw_line.c'" '(should have been 860 characters)' fi # End of shell archive exit 0 ------------------------------ Date: Tue, 18 Oct 88 20:17:16 EDT From: robert%shangri-la@gatech.edu (Robert Viduya) Subject: Problem with Textsw windows I'm writing a news reader application in suntools (SunOS 3.5) and I'm having problems displaying the articles to the user. I'm using a Textsw window and whenever I need to display an article, I do the following: /* delete the old article out of the text window */ textsw_erase (ar_text, 0L, TESTSW_INFINITY); /* insert the new article, cp points to the last char in buf + 1 */ textsw_insert (ar_text, buf, (cp - &buf[0])); This is into a text window with the following attributes: TEXTSW_AGAIN_RECORDING, FALSE, TEXTSW_BROWSING, TRUE, TEXTSW_CHECKPOINT_FREQUENCY, 0, TEXTSW_DISABLE_CD, TRUE, TEXTSW_DISABLE_LOAD, TRUE, TEXTSW_HISTORY_LIMIT, 0, TEXTSW_IGNORE_LIMIT, TEXTSW_INFINITY, TEXTSW_LINE_BREAK_ACTION, TEXTSW_WRAP_AT_CHAR, TEXTSW_SCROLLBAR, ar_scroll, WIN_COLUMNS, 80, WIN_ROWS, 40, WIN_RIGHT_MARGIN, barwidth + 4, This all works, at least for the first few articles displayed. However, it eventually runs into a memory limit trying to insert an article. Specifically, a tiny window pops up with the message "Insertion failed - memory full (Click any button to remove msg.)". Since nothing in my code generates the little window, I assume that the textsw_* routines are doing it. My questions are "Why?" and "What can I do about it?". I assume the problem is in textsw_erase in that it's not freeing up the allocated space assigned to the characters it's supposed to erase (not having source to the suntools libraries makes it difficult to tell). Any help would be appreciated. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275 ------------------------------ Date: 18 Oct 88 21:13:17 GMT From: igor!drk@uunet.uu.net (David R. Kaelbling) Subject: Over-eager uucp callback? I've set up our uucp (as distibuted with SunOS 3.5, running on a 3/260) to do callback. This seems to work, except that the immediate attempt to call a system back almost always fails with either "LOST LINE" or "DIAL FAILED". My naive interpretation of this is that, although the LCK..cua0 file is gone, the modem isn't quite ready to handle another call. Can anyone suggest a work-around for this problem? I tried adding delays to the chat script, but that didn't help. The modem is a TrailBlazer Plus attached to /dev/ttyb (now called /dev/cua0 and /dev/ttyd0), configured pretty much as described in the posting here a while ago: interface speed locked at 19200; do a soft reset when DTR is dropped. David Kaelbling (drk@igor.uu.net) David Kaelbling (408) 496-3600 c/o Rational; 3320 Scott Boulevard; Santa Clara, CA 95054-3197 email: drk@rational.com, drk@igor.uu.net, or ....!uunet!igor!drk ------------------------------ Date: Wed, 19 Oct 88 13:22:10 EDT From: msf@tab13.larc.nasa.gov (Mike Fischbein) Subject: IBM 3180 terminals on Suns? We have a group that is moving a database project from a heavily loaded 4381 to a Sun network. They have several 3180 terminals and would like to use them rather than buying new ones. They are getting SunLink 3270 to communicate back with the mainframe. Is it possible to use the 3180 terminals with the Sun system? What additions would be required in hardware or software? Email, please; I'll summarize. mike __ Michael Fischbein msf@prandtl.nas.nasa.gov ...!seismo!decuac!csmunix!icase!msf ------------------------------ Date: Wed, 19 Oct 88 22:56:00 PDT From: Dave Yost <grand!day@uunet.uu.net> Subject: When will sun have ANSI-ish C compilers? Anyone know? --dave yost ------------------------------ End of SUN-Spots Digest ***********************