HDTenEightyP/NetNews huggingface dataset:
From: serini@ghost.dsi.unimi.it (Piero Serini)
Subject: setgroups() - bug ?
Organization: Computer Science Dep. - Milan University
Date: Sun, 20 Dec 1992 23:08:59 GMT

HI all.

I suspect there's a bug in setgrupos() call :

from /etc/passwd: foo::1000:1000: ...
from /etc/group:  foo:*:1000:

Now, user foo is of group foo and no other groups.
If foo does an 'id' he gets:
uid=1000(foo) gid=1000(foo) groups=1000(foo)

The question is: if a user belongs to one group only,
is it correct that id shows a 'groups' entry, or should
it be better to omit this ?
I personally think that a 'normal' id, that is with just
one group, should show no 'groups' entry, as it's obvious
I belong to groups foo if my gid is foo ...
In fact, if foo belongs to groups 'foo2' too, the id would
show:
uid=1000(foo) gid=1000(foo) groups=1000(foo), 1001(foo2)

while I think better:
uid=1000(foo) gid=1000(foo) groups=1001(foo2)

This is the way other Unixes act, say HP-UX for example.

Let me know what you think
Bye
Piero

------------------------------------------ Piero Serini -----------------
Piero Serini	                  E-mail: serini@ghost.dsi.unimi.it   
Computer Science Dept.            or: piero@strider.st.dsi.unimi.it
Univ. Statale - Milano - ITALY      ** mail me your .signature **
-------------------------------------------------------------------------

Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Occasional system hangs
Organization: Weber State University  (Ogden, UT)
Date: Sat, 12 Dec 92 07:00:38 GMT

In article <andrewh.724059111@bruce.cs.monash.edu.au> andrewh@cs.monash.edu.au (Andrew Herbert) writes:
>My system, with 16 MB RAM and 32 MB swap, hangs in a similar way.  Existing
>processes such as INN processing incoming news and nntplinks sending outgoing
>news usually keep ticking away for quite some time (i.e. disk is unaffected),
>but it looks a whole lot like anything requiring a fork(), such as programs
>are run from the shell just hangs.  Eventually all processes grind to a halt,
>but the system can still be pinged.  The VM problem sounds quite a likely
>cause, alas.  gcc 2.3.1 is particularly good at bringing about this problem,
>while X8514 and friends rarely lasts more than 12 hours without hanging 386bsd
>and requiring a reboot.
>
>Time for more RAM I guess!

I have a box with 16M of RAM and the initial 5M swap that install likes to
give you.

	hecate 11 % uptime
	 1:03am  up 7 days, 13:31,  1 user,  load average: 0.00, 0.00, 0.00
	hecate 12 %

Of course nothing much is going on now, but I have been using it pretty
heavily lately.  The last reboot was intentional on my part to apply one
of the recently posted kernel patches (one of Julians, I think).

I can still crash it by "ping -f"'ing another computer for 30 minutes or
so, but I believe this is related more to my ethernet driver (I haven't
updated to the latest one of the AT&T STARLan cards yet) than any kernel
problems.  It's been highly stable for more than a month now.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: karl@NeoSoft.com (Karl Lehenbauer)
Subject: [386BSD] unofficial patch to get rint(3) created in libm
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Tue, 15 Dec 1992 08:19:16 GMT

There is a manpage for the rint(3) function but it is not present in
libm.  The following patch to /usr/src/lib/libm/common_source/floor.c
allows the C version to be compiled in.  

After applying the patch, cd to /usr/src/lib/libm, do a "make" and
"make install", then maybe a "make clean".  libm will then contain
the rint function.

*** floor.c.pre-neosoft	Tue Dec 15 02:16:30 1992
--- floor.c	Tue Dec 15 02:18:51 1992
***************
*** 98,104 ****
  	}
  }
  
- #ifndef national			/* rint() is in ./NATIONAL/support.s */
  /*
   * algorithm for rint(x) in pseudo-pascal form ...
   *
--- 98,103 ----
***************
*** 137,140 ****
  	t = x + s;				/* x+s rounded to integer */
  	return (t - s);
  }
- #endif	/* not national */
--- 136,138 ----
-- 
-- Email info@NeoSoft.com for info on getting interactive Internet access.
"Turn on your hot tub by email now.  Ask me how."
From: reink@hpuamsa.neth.hp.com (Reinier Kleipool)
Date: Sun, 20 Dec 1992 14:14:53 GMT
Subject: Re: HELP mread (again)
Organization: HP-Sales Office-The Netherlands
Newsgroups: comp.unix.bsd

/ hpuamsa:comp.unix.bsd / irviner@yvax.byu.edu /  4:53 am  Dec 19, 1992 /
Hello,

  The error you get is:

        Probably not a MSDOS floppy
        cannot initialize

And so my question is: Did you copy the bin01.xx onto msdos formatted
floppies? There are known problems with reading 720k dos floppies.
Try 1.2MB or 1.44MB...

Also have a look at the mread manpage to check that the device for a:
is the correct one..

Hope this helps,
Reinier kleipool.
From: keung@olisc.gnct.com (Tang Tat Keung)
Newsgroups: comp.unix.bsd
Subject: [386bsd] Keyboard Hang
Date: 20 Dec 92 00:48:25 GMT
Organization: OLI Student Center, HK.


Have anyone experience 386BSD will hang when press num lock or caps lock?
I have met this problem. I can solve it when switch the AT<->XT mode on the 
keyboard but it is not always workable.
Is 386bsd bug or hardware compatibly problem? This is very inconvenience.

keung
email: keung@gnct.com

Newsgroups: comp.unix.bsd,comp.os.linux
From: mike@inftec.be (Mike Aerts)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Organization: Information Technologies, Wemmel, Belgium.
Date: Sat, 19 Dec 92 13:25:45 GMT

In article <1992Dec18.043033.14254@midway.uchicago.edu> goer@midway.uchicago.edu writes:
>One of the big criticism leveled at US Engineers is that they are either
>too dumb or lazy to build into their software support for non-Western
I think a good programmer is lazy by definition :-)
>
>Incidentally, although it's true that US Engineers often have really
>terrible language skills, this is due more to geographical isolation
>than to organic stupidity.  There's just no need for multilingualism
>here in the states, the way there is in Europe, esp. in the low coun-
>tries and Scandinavia.
I'm from the low countries and hate those stupid signs on top of those
letters, if you need to remember these for different languages it's
a pain in the ass, but wait until you see some Vietnamese they are 
the champions I think.
I think we ( the Belgians ) are champions too, we have 3 official
languages for 10M people.
I don't think it's a matter of isolation but size, the language
skills of my French and German neighbors are IMHO not that impressive
too.

mike.

-- 
------------------------------------------------------------------------
E-mail : mike@inftec.BE     | I think that it's extraordinarly important
tel    : +32 2 460.46.11    | that we in computer science keep fun in
Fax    : +32 2 460.56.50    | computing. ....               A.J. Perlis
Newsgroups: comp.unix.bsd
From: Petri.Wessman@hut.fi (Petri Wessman)
Subject: [386BSD] Comm software?
Reply-To: Petri.Wessman@hut.fi
Organization: La Gata Encantada
Distribution: comp
Date: 18 Dec 92 10:49:35

Has anyone ported a comm program to 386BSD? Except tip, that is :-) I
compiled pcomm-2.0 (or was it 2.1?) yesterday, but it doesn't manage
to actually send anything to the com port, and panics the kernel (!)
when I interrupt a dial attempt -- I'm using the new multiport com
driver with a plain vanilla 2-port I/O card. I also tried a program
called 'xc', but it's crawling with SysV-isms and would require a bit
of hacking to compile. Don't tell me everyone's still using tip!

//Petri
Newsgroups: comp.unix.bsd,comp.os.linux
From: peter@ferranti.com (peter da silva)
Subject: Re: 386BSD + LINIX + GNU + X11R5 on CDROM - let us know what you want!
Organization: Xenix Support, FICC
Date: Mon, 14 Dec 1992 18:15:37 GMT

In article <1992Dec11.225241.1941@nb.rockwell.com> wade@nb.rockwell.com (Wade Guthrie) writes:
> The Linux cd-rom drivers may support this already, but if you don't already
> HAVE Linux up and running on your system, the point is moot.  I would not
> like to see the Rockridge extensions, 'cause then I wouldn't be able to 
> load Linux from the CD on a system that currently has only DOS.

I don't see that this follows. Aren't they supposed to be backwards compatible
with 9960?
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Encryption of passwords
Organization: University of Utah Computer Center
Distribution: na
Date: Tue, 15 Dec 92 04:05:16 GMT

In article <1992Dec14.220949.26824@newshost.lanl.gov>, rgt@beta.lanl.gov (Richard Thomsen) writes:
|> I was told that there is a patch to 386bsd to allow the passwords to be
|> encrypted, but I have not found this in unofficial.  Where do I get the
|> patches to do this?  Or what files in unofficial are they in?

DES software is on the munitions list, and therefore not distributable from
the US to other countries, even if it came from outside the US in the first
place:

	"DES Hotel -- DES checks in, but it doesn't check out"

There are pointers in the installation notes to the sites (outside the US)
that DES can be ftp'ed from, as well as in the source area for the fake
"libcrypt".  There are sites in the US where it can be gotten (such as
gatekeeper.dec.com); installation is pretty straight forward.

As long as you don't let out your root password, the shadow file will keep
your machine secure (and if you let out your root password, DES won't keep
your machine secure).


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: weingart@inf.ethz.ch (Tobias Weingartner)
Subject: Need help making up my mind.
Followup-To: poster
Keywords: mind, boggled, help
Reply-To: weingart@inf.ethz.ch
Organization: ETH - Switzerland
Date: Thu, 17 Dec 1992 11:58:08 GMT

Hello all!

Ok, I have this fundamental problem.  You see, a while back
I got hooked on this neat OS called DOS.  Ok, save your flames.
What was so neat, was that there was lots of software to go
with it.  Anyways, a little while later, I got hooked on a
even better drug, called UNIX.  Wow, multiple procs, public
domain software, great compilers, everything you could want.

In the mean time, I have been making some money, and have
decided that now would be a good time to buy a machine, that
would keep me busy for the next couple of years.  Of course,
this baby will have to run UNIX.  4.3 or 4.4 BSD if I can get
it.  Source code would be cool, and a full load of X11R5, GNU,
etc, etc...

The problem now becomes this:
Which machine should I buy?  Now, like everybody else, I want
something fast, cheap, good quality, etc.  I basically have
two choices.  I can buy a sparc 2, get no source to the OS,
basically be broke when I have it.  Or I can buy somehting like
a 486-50MHz, EISA, 1742a, S3-801, 19" monitor, and come out to
roughly the same price. (Do these devices work?  EISA work?)

The question now becomes:  How does the above 486 running 386BSD
or Linux compare to a Sparc2 running 4.1.3?  I have heard good
things about the X server, but does anybody have any figures,
experiences, etc?

NOTE:
I don't mind the machine crashing now an then, and putting up with
some bugs.

Any and all suggestions are welcome.

-- 
Tobias Weingartner  *    PGP2.0 Public Key available at     *
 +41'41'33'25'40    *   'finger weingart@tau.inf.ethz.ch'   *
SYSTEM-F-ANARCHISM, the operating system has been overthrown
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: AT&T StarLAN NIC driver?
Organization: University of Utah Computer Center
Date: Fri, 18 Dec 92 02:32:48 GMT

In article <1992Dec13.172327.26903@dsuvax.dsu.edu>, ghelmer@dsuvax.dsu.edu (Guy Helmer) writes:
|> I thought I remembered seeing an AT&T StarLAN driver go by a while ago,
|> but I didn't keep it and now I can't seem to find it on any of the 386bsd
|> ftp sites.  If it exists, could someone please send it to me?  Thanks.

Contact:
	Garrett Wollman
	wollman@emba.uvm.edu
	University of Vermont, EMBA Computer Facility


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd,comp.os.linux
From: russed@rebecca.its.rpi.edu (Daniel Russell)
Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
Date: Sat, 19 Dec 1992 03:17:26 GMT

goer@kimbark.uchicago.edu (Richard L. Goerwitz) writes:
[...]
>  NT will be a welcome departure from the past, if in fact
>it offers true multilingual support.  We'll see.

	As a (kind of) side note, I have heard that the NeXT has *excellent*
foreign language support.

 dan

>   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
>   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer

Newsgroups: comp.unix.bsd
From: wcn@cs.brown.edu (Wen-Chun Ni)
Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
Organization: Brown University Department of Computer Science
Date: Wed, 16 Dec 1992 10:25:24 GMT

In article <AWB.92Dec16072619@otter.uk.ac.ed.aisb> awb@ed.ac.uk (Alan W Black) writes:
   <stuff deleted>
>
>Mule supports Japanese (output and input).  Input is through Wnn
>a kana/kanji convertor (which accepts romaji or kana input).  It
>the input method is (I am told) compatible with ATOK which is
>used on a large number of word processors.  Mule also has support 
>for Chinese (with a large variety of input methods) offering
>both Mandarin and Taiwanese fonts.  Also there is good support for
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Korean.  Other languages that are supported in Mule are all
>the major European languages, including Greek, and Russian.  There
>is also alpha support for Vietnamese, Hebrew and Thai.


Just for clarification. There is no such thing like Mandarin or
Taiwanese font. The official characters used in People's Replublic of
China are basically "reduced" and simplified characters of the
conventional ones. Taiwan as well as Hong Kong are still using the
conventional characters.  Thanx!



Newsgroups: comp.unix.bsd
From: kaleb@jpl-devvax.jpl.nasa.gov (Kaleb Keithley)
Subject: Re: Solaris 2: how do I get rid of -lucb ?
Keywords: SVR4, shared libraries, Solaris 2
Organization: Jet Propulsion Laboratory (NASA)
Date: Fri, 18 Dec 1992 16:49:09 GMT

In article db@sunbim.be writes:
>I am using Solaris 2.* on my SPARC, and many of the home-brew applications
>I have compiled on it (with Motif, Xt, and Xlib libraries) have the habit
>of trying to load libucb at run time.
>
>When after linking I use "ldd" on the executable, it will tell me that the
>UCB library is linked in. E.g.
>	whitney!db 90 % ldd phone
>		libXm.so =>      /usr/lib/libXm.so
>       [...]
>-->		libucb.so.1 =>   /usr/ucblib/libucb.so.1
>       [...]

I'd guess that it's caused by the widespread usage of functions *like* 
bcopy and it's kin that are rooted firmly in Berkeley-based systems.

Seems like the easiest way to find out would be to do a symbol table dump 
of the static libucb, and then grep through your source for those names;
and then replace them with the SysV equivalents.  Sounds like a lot of
work to me, actually.  I'm also not sure that non-system call functions
like the bcopy family are worth the effort to excise from the application
source.  But, if you're really intent on eliminating libucb from your
system, then maybe it is.

Also, what about using Sun's migration tool to analyze the "home brew"
source?  Or doesn't that work as well as Sun's marketing hype says it
does? :-)

-- 

Kaleb Keithley                               kaleb@jpl-devvax.jpl.nasa.gov

Newsgroups: comp.unix.solaris,comp.windows.x,comp.unix.programmer
From: dana@dino.bellcore.com (Dana Chee)
Subject: Re: Solaris 2: how do I get rid of -lucb ?
Keywords: SVR4, shared libraries, Solaris 2
Reply-To: dana@thumper.bellcore.com
Organization: Packet Communications Research Group (Bellcore)
Date: Fri, 18 Dec 92 13:38:18 GMT

In article <1992Dec18.094738.15038@sunbim.be>, db@sunbim.be (Danny Backx) writes:
|> Hi,
|> 
|> I am using Solaris 2.* on my SPARC, and many of the home-brew applications
|> I have compiled on it (with Motif, Xt, and Xlib libraries) have the habit
|> of trying to load libucb at run time.
|> 
|> What happens in fact is I compile the applications with commands like this :
|> 	cc -o prog *.o -lXm -lXt -lX11
|> without any references to /usr/ucbinclude or /usr/ucblib around. That is, I
|> do NOT have an LD_LIBRARY_PATH or an LD_RUN_PATH set, and none of the sources
|> require /usr/ucbinclude.
|> 
|> When after linking I use "ldd" on the executable, it will tell me that the
|> UCB library is linked in. E.g.
|> 	whitney!db 90 % ldd phone

...

|> 		libelf.so.1 =>   /usr/lib/libelf.so.1
|> -->		libucb.so.1 =>   /usr/ucblib/libucb.so.1
|> 		libdl.so.1 =>    /usr/lib/libdl.so.1
|>

...

|> How can I find out exactly what is causing this ? I would like to know how
|> to generate applications that can run without the binary compatibility
|> package.
|> 
|> Thanks,
|> 	Danny
|> --

Danny,
	What compiler are you using?  If its the one in /usr/ucb/cc,
then you are getting the expected behaviour.  /usr/ucb/cc is a shell
script that adds -lucb -lsocket -lnsl -lelf -laio to your load path
and /usr/ucbinclude to your include path.  What you probably want to
do is get gcc, this will remove any of the above.  (I've not tried
running /usr/ucb/cc without doing the above, since its designed to
compile things in compatability mode).  The Cygnus distribution is
available anon ftp from uunet, or you can get the source and build it
yourself.

--
+*************************************************************************+
*  Dana Chee				(201) 829-4488			  *
*  Bellcore								  *
*  Room 2P-298								  *
*  445 South Street			ARPA: dana@bellcore.com		  *
*  Morristown,  NJ  07960-1910		UUCP: {gateways}!bellcore!dana	  *
+*************************************************************************+
Newsgroups: comp.unix.solaris,comp.windows.x,comp.unix.programmer
From: db@sunbim.be (Danny Backx)
Subject: Solaris 2: how do I get rid of -lucb ?
Keywords: SVR4, shared libraries, Solaris 2
Reply-To: db@sunbim.be
Organization: BIM n.v. Everberg Belgium
Date: Fri, 18 Dec 92 09:47:38 GMT

Hi,

I am using Solaris 2.* on my SPARC, and many of the home-brew applications
I have compiled on it (with Motif, Xt, and Xlib libraries) have the habit
of trying to load libucb at run time.

What happens in fact is I compile the applications with commands like this :
	cc -o prog *.o -lXm -lXt -lX11
without any references to /usr/ucbinclude or /usr/ucblib around. That is, I
do NOT have an LD_LIBRARY_PATH or an LD_RUN_PATH set, and none of the sources
require /usr/ucbinclude.

When after linking I use "ldd" on the executable, it will tell me that the
UCB library is linked in. E.g.
	whitney!db 90 % ldd phone
		libXm.so =>      /usr/lib/libXm.so
		libXt.so.5.0 =>  /usr/lib/libXt.so.5.0
		libXmu.so.5.0 =>         /usr/lib/libXmu.so.5.0
		libX11.so.5.0 =>         /usr/lib/libX11.so.5.0
		libc.so.1 =>     /usr/lib/libc.so.1
		libresolv.so.1 =>        /usr/lib/libresolv.so.1
		libsocket.so.1 =>        /usr/lib/libsocket.so.1
		libnsl.so.1 =>   /usr/lib/libnsl.so.1
		libelf.so.1 =>   /usr/lib/libelf.so.1
-->		libucb.so.1 =>   /usr/ucblib/libucb.so.1
		libdl.so.1 =>    /usr/lib/libdl.so.1
		libintl.so.1 =>  /usr/lib/libintl.so.1
		libw.so.1 =>     /usr/lib/libw.so.1

How can I find out exactly what is causing this ? I would like to know how
to generate applications that can run without the binary compatibility
package.

Thanks,
	Danny
--
	Danny Backx
	System Engineer

E-Mail: db@sunbim.be    (or uunet!mcsun!ub4b!sunbim!db)

Telephone: +32(2)759.59.25	Fax : +32(2)759.47.95

Postal Mail :
	Danny Backx
	BIM
	Kwikstraat 4
	3078 Everberg
	Belgium

Xref: sparky comp.unix.solaris:426 comp.windows.x:20402 comp.unix.programmer:5741
From: maslen@gday.Eng.Sun.COM (Thomas Maslen)
Newsgroups: comp.unix.solaris,comp.windows.x,comp.unix.programmer
Subject: Re: Solaris 2: how do I get rid of -lucb ?
Date: 19 Dec 1992 01:12:52 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: gday
Keywords: SVR4, shared libraries, Solaris 2

dana@dino.bellcore.com (Dana Chee) writes:
>In article <1992Dec18.094738.15038@sunbim.be>, db@sunbim.be (Danny Backx) writes:
...
>|> I am using Solaris 2.* on my SPARC, and many of the home-brew applications
>|> I have compiled on it (with Motif, Xt, and Xlib libraries) have the habit
>|> of trying to load libucb at run time.
>|> 
>|> What happens in fact is I compile the applications with commands like this :
>|> 	cc -o prog *.o -lXm -lXt -lX11
>|> without any references to /usr/ucbinclude or /usr/ucblib around. That is, I
>|> do NOT have an LD_LIBRARY_PATH or an LD_RUN_PATH set, and none of the sources
>|> require /usr/ucbinclude.
>|> 
>|> When after linking I use "ldd" on the executable, it will tell me that the
>|> UCB library is linked in. E.g.
...
>	What compiler are you using?  If its the one in /usr/ucb/cc,
>then you are getting the expected behaviour.  /usr/ucb/cc is a shell
>script that adds -lucb -lsocket -lnsl -lelf -laio to your load path
>and /usr/ucbinclude to your include path.  What you probably want to
>do is get gcc, this will remove any of the above.  (I've not tried
>running /usr/ucb/cc without doing the above, since its designed to
>compile things in compatability mode).  The Cygnus distribution is
>available anon ftp from uunet, or you can get the source and build it
>yourself.

Let me try to disentangle the two threads in this paragraph... yes, as Dana
notes, it sounds as though the shell is finding /usr/ucb/cc on your path
before it finds the real compiler.  However, this is mostly orthogonal to the
issue of whether you use SunPro's cc, gcc, or any other compiler.  (I say 
"mostly" because the /usr/ucb/cc script works "out of the box" with SunPro's
cc, whereas last time I looked it needed some tweaks to work with gcc).

Thomas Maslen					
maslen@eng.sun.com				My opinions, not Sun(Soft)'s
Newsgroups: comp.unix.ultrix