Sun-Spots Digest, v6n59

William LeFebvre Sun-Spots-Request at RICE.EDU
Wed Apr 20 08:22:10 AEST 1988


SUN-SPOTS DIGEST          Tuesday, 19 April 1988       Volume 6 : Issue 59

Today's Topics:
                   Re: NEC Silentwriter LC-890 "RS-232"
                          newtool - a csh alias
              newtool - man page problems:  nroff & vt100's
                        Re: newtool - a csh alias 
                          My favorite shell file
                     possible 5.0DNI(tm) Serious Bug?
                         Re: Sun 4 status? (long)

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at 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 at rice.edu" or mail the word "help" to the same address
for more information.

----------------------------------------------------------------------

Date:    Tue, 12 Apr 88 09:12:24 EDT
From:    Mike Jipping <jipping at frodo.cs.hope.edu>
Subject: Re: NEC Silentwriter LC-890 "RS-232"
Reference: v6n50

We got our NEC SilentWriter a couple of months ago (Feb).  We've had NONE
of the problems you've mentioned.  We ordered the Transcript distribution
from Sun and everythine works fine.  We receive debug info, can print long
jobs (e.g., 20 + pages), and have been error free (except for one paper
jam).  We are running it off of a Sun 3/50 -- with locally wired cable
(although the Sun-supplied cable was fine, too).

Because we are running nigh-unto-perfect with such a vanilla installation,
I'm surprised you are having such problems.

One thing I thought of --> Is the setting of "SOFTWARE INTF" set to
"POSTSCRIPT BATCH"?  It should be.

The only problem we had with NEC was SLOW SLOW SLOW delivery.  Our printer
was delivered 3 months after a promised date.  Oh, well...

                                             -- Mike
Mike Jipping
Hope College
Department of Computer Science
jipping at cs.hope.edu

------------------------------

Date:    Tue, 12 Apr 88 18:34:05 -0400
From:    mesard at bbn.com
Subject: newtool - a csh alias

I've written a little (well, big, actually) alias called "newtool" that
might be of use to other readers.

Some SunView applications are invoked by long command lines in
~/.suntools.  If one of these windows get trashed, it can be a royal pain
to fire up a new one with the right program, options and attributes.

Newtool takes care of this.  It takes as an argument line a regular
expression.  Lines in ~/.suntools that match the r.e. will be run in the
background of the invoking shell.

The definition (suitable for entry to in ~/.cshrc or an interactive shell)
is:

alias newtool 'eval `sed -n -e /"\!*"/s/^/\\\\/ -e /"\!*"/s/\$/\\\&/p < ~/.suntools`'

Examples:

	% newtool shell  - restart your shelltools.
	% newtool -Wi    - restart the tool(s) which start out closed.
	% newtool .      - execute all the lines in ~/.suntools.


Because I take myself too seriously, I whipped up a man page for this baby
which is included below.

Have fun.  Comments appreciated.

MESARD at BBN.COM
BBN Labs, Cambridge, MA

--------------------CUT-HERE--------------------
.TH NEWTOOL 7L "9 April 1988" " " " "
.ds ~ \v'0.25m'\fB~\fP\v'-0.25m'
.ds ^ \v'0.25m'\s+2^\s0\v'-0.25m'
.ds ' \(fm
.de ES
.RS
.sp
.nf
..
.de EE
.fi
.sp
.RE
..
.SH NAME
newtool \- invoke an application with it's stored attributes
.SH SYNOPSIS
.B newtool
.I reg-exp
.SH DESCRIPTION
.B newtool
is a C-Shell alias that allows a user to restart a SunView tool with
the attributes, program and program options specified in
.IR \*~/.suntools .  

.I reg-exp 
is a 
.IR sed (1) 
regular expression that matches one
or more lines in
.I \*~/.suntools.  
The contents of all matching lines will be run as background jobs in the current shell.

The following will execute each of the lines in 
.I \*~/.suntools 
containing the word "shell":
.ES
% \fBnewtool shell\fP
.EE
The next example will start new invocations of all the tools that have a
stored background or foreground attribute with a red component of 255:
.ES
% \fBnewtool \-W[bf] [ ]*255\fP
.EE
More complex (and contrived) examples are possible, but these are left
as an exercise for the reader.

To install 
.BR newtool , 
place the following single line in your 
.I \*~/.cshrc 
file exactly as it appears here:
.ES
.\" WARNING: the line below has troff commands in it.  The raw line looks like:
.\" alias newtool 'eval `sed -n -e /"\!*"/s/^/\\\\/ -e /"\!*"/s/\$/\\\&/p < ~/.suntools`'
alias newtool \*'eval \`sed \-n \-e /"\\!*"/s/\*^/\\\\\\\\/ \-e /"\\!*"/s/\\$/\\\\\\&/p < \*~/.suntools\`\*'
.EE
.SH "IMPLEMENTATION NOTES"
The first 
.IR sed (1) 
script above puts a backslash (\|\fB\\\fP\|) at the start of each
matching line in case the specified command itself is aliased (as, for
example,
.B shelltool 
often is).  The second script places an ampersand (\|&\|) at
the end of matching lines so that when they are
.BR eval ed 
by the shell, they will run in the background.

This is, of course, absurdly complicated.  But (like most absurdly
complicated UNIX things) it is not unnecessarily so.  The current form
of this alias evolved directly from the much simpler (and less powerful)
form:
.ES
alias newtool \*'eval \`grep \\!* \*~/.suntools\` &\*'
.EE
.SH FILES
.nf
\*~/.cshrc
\*~/.suntools	
.fi

.SH "SEE ALSO"
suntools(1), csh(1), tcsh(1), sed(1), ed(1)

.SH DIAGNOSTICS
For each matching line, the shell will report the job number and process
id of the new tool.

.SH BUGS
The regular expression start-of-line symbol (\|\fB\*^\fP\|) won't
work as expected.  Since the first script sticks a backslash at the
beginning of each line, the second script won't match the same way that
the first one did.  So instead of
.ES
% \fBnewtool \*^shell\fP
.EE
one must say
.ES
% \fBnewtool \*^[\\]*shell\fP
.EE
With all the quoting and what-not going on in this alias definition,
some versions of the shell may complain.  The form specified above works
with the C-Shell from Sun Release 3.2 and 3.4, and with 
.I tcsh 
version 5.4, patch level 0.  Please send mail to the address below if
you encounter any problems using
.BR newtool .

.SH AUTHOR
Wayne Mesard, mesard at BBN.COM

------------------------------

Date:    Wed, 13 Apr 88 09:12:18 -0400
From:    mesard at bbn.com
Subject: newtool - man page problems:  nroff & vt100's

Apparently, there was a bug in the man page contained in my last message.
The symptom is that when nroff'ed (i.e. man'ed) on vt100's the cursor
homes immediately after printing a tilde (~).  The culprit is the \(ap
symbol in the .ds command on line 2.

In my defense, I offer the fact that csh(1)'s man page has the same .ds
and (fortunately) it has the same problem.

If anyone can explain this behavior to me, I would be interested and
appreciative (in that order).  Is it nroff? termcap?  

At any rate, please apply the enclosed diff to the file included in my
last message.

[[ The patch has already been applied to the manual page that appears in
this issue.  --wnl ]]

Wayne();

------------------------------

Date:    Wed, 13 Apr 88 09:05:03 -0400
From:    malis at cc5.bbn.com
Subject: Re: newtool - a csh alias 

I use an alternative method to accomplish the same goal.  All of the lines
in my .suntools file are replicated in a "Restore defaults" submenu in my
.rootmenu file.  For example, the following line in .suntools:

clock      -Wp   68   0 -Ws 218  39 -WP   68   0 -Wi -s -d wmd

is matched by the following in .rootmenu:

  "Clock"               clock      -Wp   68   0 -Ws 218  39 -WP   68   0 -Wi -s -d wmd

and so on.

Andy

------------------------------

Date:    Sat, 16 Apr 88 19:58:12 CDT
From:    William LeFebvre <phil at Rice.edu>
Subject: My favorite shell file

Since Mr. Mesard submitted his favorite alias, I would like to give you my
favorite shell file.  I always thought it was silly to have to tie up a
local shelltool/commandtool to rlogin to another machine.  So I have a
shell file that automatically pops up a new tool that does nothing but
rlogin to another host.  And the really neat thing about it is, when you
log out, the window goes away.  Another nice feature is that it gets its
host name from argv[0].  Just put it in your bin directory and give it the
name of your favorite host.  Need to connect to more than one host?
That's easy, just create separate (hard) links to the file each with the
appropriate host name.  Mine has about 15 separate links to it, each link
is the name of a host I might want to connect to.  Here's the file:
____________________

#!/bin/csh -f
set h = `/usr/bin/basename $0`
shelltool -Wl " rlogin $h" -WL "$h" rlogin $h $* -8 &
____________________

Works great!  And you can even give "-l" arguments to it.  But you have to
be running suntools to use it!

------------------------------

Date:    Tue, 12 Apr 88 19:35:26 PDT
From:    Steve Blair <ascway.UUCP!scb at spar-20.spar.slb.com>
Subject: possible 5.0DNI(tm) Serious Bug?

In the 5.0 version of Sunlink/DNI there appears to be a weird almost
poltergeistic bug there:

using dnalogin outside of a 'te100tool' causes the
'/usr/sunlink/dna/dnalogind' to terminate.  This to my recolection does
not appear in DNA4.0, so's here an easy fix one of my users came up with:

environment:
we share a 'cshrc & login'; we source a shared one in '/usr/local/etc' and
in the '.login',  we source '/usr/local/etc/std.login'.  So install the
following in a .login-preferrably shared so you don't have to do this fix
for everyone!!):

ps ax | grep 'dnalogind' | grep -w 'grep'
	if ($status) /usr/local/bin/startdnalogind &

all one has to put into the startdnalogind file is:
/usr/sunlink/dna/dnalogind

This cures the major flaw; however there's one other workaround:

*buy their te100 product. It doesn't have this annoying habit. However,
this is expensive and some folks may not have the money so ftp the public-
domain one!

I think that a shared '.login & .cshrc' can have a lot of benefits. Some
folks are insistant on having their "own", but using a common one will
help in a lot of ways:

1) ease of admin for YOU
2) NFS(tm) can make a sharable database such as this truly portable from node
   to node.
3) new users have an environment that they've probably already seen their
   peers using.
4) users can customize to their hearts' content and you can not worry about
   some parts of the environment.

Good Luck

Steve Blair
Sun Administrator
Schlumberger Technology Corporation
Austin, Texas
uucp:{backbone}!sun!decwrl!spar!ascway!blair

------------------------------

Date:    13 Apr 88 10:02:40 GMT
From:    hedrick at athos.rutgers.edu (Charles Hedrick)
Subject: Re: Sun 4 status? (long)
Reference: v6n46

[[ This message is rather long, so I have placed it last in the digest.
But I encourage everyone who is even remotely interested in the Sun 4 to
read at least the first paragraph.  --wnl ]]

There seems to be some confusion about the state of the operating system
for the Sun 4.  Our honored editor said that he thought it was version 4,
and Byers said he had heard it wasn't available at all.  In fact, Sun 4's
run SunOS 3.2.  Early machines ran 3.2-L, also known as Sys4Gamma.  The
name Sys4Gamma may have led some people to think it was a prerelease of
SunOS 4.  In fact it is a version of 3.2 with the changes needed to
support the Sun 4.  There is now a thing that is being called simply 3.2.
We are still running the gamma release, since it works fine and putting in
the local changes would be a pain.  However I've taken a few things from
the 3.2 tape (mainly compilers and their libraries).  I have found the 4
to be remarkably good for a new machine.  Anybody remember all the
problems with the first Sun 3's?  You had to run on a prerelease of SunOS
3.0, and the window software was broken?  I think we've seen a couple of
crashes and/or hangs, but they have been very rare (we have several
machines).

[[ Or how about all the problems with the first Sun 2's?  Or Sun 1's?
But Sun does get them ironed out eventually.  Please forgive my ignorance
regarding the Sun 4---we don't have one here (yet).  --wnl ]]

We did have some infant mortality on the hardware, including both CPU
cards and memory.  However they seem to be only startup problems.  I.e.
once fixed the machines are reliable.  The very earliest machines (ones
designated gamma) had a bug in the floating point chip, but people outside
the gamma program shouldn't be seeing that.

We've found the weak point in the compilers to be Fortran.  We did see
some Fortran problems, primarily due to the FPA chip problem.  And some
people think Fortran performance isn't very good.  Our VMS people think it
is equivalent to 4 VAX MIP's on integer stuff.  (We generally consider the
machine to be 8 VAX MIP's.)  We just got the "real" Fortran, version 1.05.
This is the one with the VMS extensions (turns Fortran into Ada).  This
compiler is supposed to fix the known compiler problems, though we think
it still won't make the thing 8 times a VAX.

I don't recall having seen any C compiler bugs, and we've ported a good
deal of stuff.  We have a Pascal compiler for it (somebody said they
didn't think it was available), but again I think it's a "gamma" compiler.
We have TeX running, so it can't be entirely broken, but we don't do much
else with Pascal.  Thus I can't say how good it is.  Most other software
we've looked for we've found.  Some of it involved twisting people's arms.
We have Prolog (from Quintus -- probably the first commercial vendor to
deliver on its Sun 4 promise -- Quintus really had things ready when the
machines started shipping), another major AI language (which I am
contractually prohibited from saying any more about), Scribe (which really
does run somewhat faster than a VAX 8650), Mathlab, and various other
software.  Our main software problem is that we couldn't get source.  So
whenever we needed to modify a module, we used the Sun 3 version of 3.2
and ported it to the Sun 4.  Our kernel is a real hack, with a combination
of their binaries, things built from Sun 3 source, and patches inserted by
Emacs-ing the binaries.  Yuck.  We still haven't gotten the Van Jacobson
version of TCP up, because Sun 3 IP and TCP modules won't work on the 4's,
and we don't know what has to be done to fix them up.  Fortunately, our
Arpanet mail is handled by a Sun 3.  (However RUTGERS.EDU is about to
change from a Sun 3 into a Sun 4.  It does a lot of net traffic.  I'm not
sure what is going to happen when it goes from Jacobson TCP back to Sun
3.2.  Is anybody at Sun worried that a major Usenet relay site is going to
start losing because of problems with SunOS?)

In summary: yes, it's a new machine.  There are implications to buying a
new machine, and anybody who says their aren't is crazy.  But compared to
other new machines we've seen (both Sun and elsewhere), it has gone very
well.  We have no hesitation about using them in production.

About the specific questions in Sun-Spots:

>1) The ports on the SUN 4 do not conform to specification. They will
>   not drive a printer.

Dunno.  We drove a Postscript printer off of one for a while.  Had
slightly flaky behavior, but it's not clear to us whether it was hardware,
software, or the printer.  It's not the only Postscript printer we have
that hangs now and then.  If there's a problem, it's subtle.

> 2) Sun has not released an operating system for the SUN 4.  The SUN 3 
>   operating system is not fully operational on a Sun 4.  (A Sun 4
>   operating system is scheduled to be available next June.)

False.  All Sun 4's have been shipped with an operating system (would be
sort of useless without, right?)  Currently it's SunOS 3.2.  Early ones
were 3.2 gamma.  I think this rumor is due to Sun's attempt to be honest.
They said that 3.2 gamma wasn't a real release, and this could easily turn
into "the OS isn't released".  Their main concern with the gamma version
seemed to be with support of diskless clients, which generally wasn't an
issue to early customers anyway, since they didn't ship diskless
configurations at that point.

> 3) A Sun 4 can not be a diskless client of a SUN 3 server, but a SUN 3
>   can be a diskless client of a Sun 4 server.

Diskless support changed between 3.2 gamma and the "real" 3.2.  I'm fairly
sure a 4 can serve a 3 now.  I don't know about the reverse.  Certainly a
4 can mount a disk from a 3 via NFS.  However there are some performance
issues (generally you have to reduce the number of biod's on the 4 to
avoid overrunning the 3).

[[ I believe you encounter similar problems when you try to make a 2 serve
a 3.  The client is just too fast for the server.  --wnl ]]

------------------------------

End of SUN-Spots Digest
***********************



More information about the Comp.sys.sun mailing list