postmaster@uunet.uu.net (06/20/88)
Reason: local mail handler complained as follows
jmail: HuwR -- unknown user or mailbox
-------- rejected letter ---------
Via: 00004001015218/UCL-CS.FTP.MAIL ; 19 Jun 1988 17:54:10 GMT
Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel
id aa02655; 19 Jun 88 13:06 BST
Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP
id aa02637; 19 Jun 88 13:01 BST
Received: from SEM.BRL.MIL by SEM.brl.ARPA id aa08024; 17 Jun 88 2:57 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa08020; 17 Jun 88 2:45 EDT
Date: Fri, 17 Jun 88 02:45:38 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@arpa.brl>
To: INFO-UNIX@arpa.brl
Reply-To: INFO-UNIX@arpa.brl
Subject: INFO-UNIX Digest V5#071
Message-ID: <8806170245.aa08020@SEM.BRL.ARPA>
Sender: info-unix-request@uk.ac.ucl.cs.nss
INFO-UNIX Digest Fri, 17 Jun 1988 V5#071
Today's Topics:
Re: afio
Re: C/IBM
Re: Rename bug?
Curses & Color
X.400 mail
Re: .mailrc
Re: Rename bug?
Re: "cd path" strangeness
Microport S/386 and Appropriate Hardware
Need decoder/encoder source to transfer binaries
DEC hardware manuals
troff -- bold italics
which shell does shell scripts
-----------------------------------------------------------------
From: Norman Yarvin <ins_anmy@jhunix.hcf.jhu.edu>
Subject: Re: afio
Date: 16 Jun 88 00:31:56 GMT
To: info-unix@SEM.BRL.MIL
In article <4449@killer.UUCP> jlg@killer.UUCP (J L Gomez) writes:
>I've compiled the afio program but do not how to use it with the
>UNIX-PC's floppy disk drive. I know how to use cpio but using the same
>syntax with afio doesn't work. I need to know how to use the -i, -o, and
>-t options of afio. The floppy disk drive name is /dev/rfp021.
>Thanks for the help and info!
The floppy disk is /dev/rfp021 for the raw device (cpio/afio) and /dev/fp021
for the mountable device (mount with "/etc/mount <directory> /dev/fp021";
dismount with "/etc/dismount".)
Afio works out of the box and supports multiple floppies. It can read
multiple floppies made with cpio (although it complains something is wrong
at the start of each new floppy.) Its biggest feature (for me) is that it
recovers from errors, instead of dying cpio-style. As to how to operate it,
the basic options are -i for input, -o for output, and -t for a listing; the
rest of the instructions are in the man page (format with "nroff -man
<man_page> | more").
Good luck!
------------------------------------------------------------------------------
| Norman Yarvin |
| (seismo!umcp-cs | ihnp4!whuxcc | allegra!hopkins) !jhunix!ins_anmy |
| |
| Disclaimer: Johns Hopkins is massively responsible for everything I say. |
------------------------------------------------------------------------------
-----------------------------
From: Richard Hoffman <ubiquity@cs.utexas.edu>
Subject: Re: C/IBM
Date: 16 Jun 88 04:52:09 GMT
To: info-unix@SEM.BRL.MIL
In article <768@altger.UUCP>, doit@altger.UUCP (Christian Rohrmueller) writes:
> In article <10565@agate.BERKELEY.EDU> arnold2@violet.berkeley.edu (mchawi) writes:
> >now that there are c compilers on big ibms, is there a rush of COBOL->C?...
>
> Yes. It's from RAPITECH SYSTEMS INC. in Suffern , NY 10901
> Montebello Corporate Park.
I think he meant "are a lot of shops trying to convert from COBOL to C?"
rather than "are there COBOL->C conversion tools?". If so, from what I
have seen in the Oil Industry, the answer is Zip. The big conversion
contraversy is whether to go from COBOL to PL/I. Not only are there a lot
of COBOL programs out there, there are a lot of COBOL programmers out
there, who have little interest in learning C and whose managers have
little interest in paying them to do it.
Another problem is that most COBOL programs depend on data types such
as zoned and packed decimal, which are not typically available in C.
As far as automatic conversion goes, I would think that, with the addition
of some packed decimal typedefs and conversion routines, COBOL->C could
be completely automated. The results would make pretty awful reading,
though.
--
Richard Hoffman / 5751 Valkeith / Houston, TX 77096 / (713) 729-5716
+- / 12166 Metric Blvd., #122 / Austin, TX 78757 / (512) 823-1822
"Malt does more than Milton can / To justify God's ways to Man." -- ??
-----------------------------
From: "Michael I. Bushnell" <mike@turing.unm.edu>
Subject: Re: Rename bug?
Date: 15 Jun 88 18:03:36 GMT
Sender: news@unmvax.unm.edu
Keywords: strange rename errno
To: info-unix@brl-sem.arpa
In article <55239@sun.uucp> limes@sun.UUCP (Greg Limes) writes:
>In article <1128@mcgill-vision.UUCP> der Mouse writes:
>>... I trust one written by a company out to make money even less.
>
>Funny, I would expect exactly the reverse. If the operating system does
>not work properly, the company gets bug reports and has to fix them
>(this costs bucks), and if the bugs are bad enough, the company starts
>to lose customers to competitors who can provide better functionality.
>Thus is it in the best interests of the for-profit corporation to
>provide software that is as reliable and bug-free as possible.
OK...here's the 10,000,000 question: who competes with SUN to provide
software for SUNs? No one. There is, therefore, no impulse on the
part of sun to provide the best functionality. Once someone's bought
the box, sun is a power to stick-it-to-em. DEC has a competitor for
Ultrix, but the response has not been to improve Ultrix, it has been
to keep hardware manuals secret to UCB can't write drivers.
--
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing.unm.edu!mike
-----------------------------
From: "Michael I. Bushnell" <mike@turing.unm.edu>
Subject: Re: Rename bug?
Date: 15 Jun 88 18:09:56 GMT
Sender: news@unmvax.unm.edu
To: info-unix@brl-sem.arpa
In article <55437@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>> I consider the whole vfs-based filesystem as an NFS thing, since it
>> exists only to support NFS.
>
>Which demonstrates that you *don't* know why the VFS mechanism
>exists. IT does not "exist only to support NFS." It exists to
>support *multiple* file systems; in other words, to permit several
>different file system types to share the same system call interface,
>and to permit new file system types to be added without rewhacking
>the system call interface.
And thus, fails. The discussion is about a manner in which those
different file systems do NOT provide the same system call interface.
Some of them give an error for rename("foo","foo"), some delete "foo",
some do nothing. flock(...) works on some, not on others. And then
there's the celebrated mkdir bug. If I do
open(fname, O_RDWR | O_CREAT | O_EXCL, mode), NFS doesn't guarantee
exclusive creation.
NFS and VFS do not guarantee the same semantics for different file
systems.
--
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing.unm.edu!mike
-----------------------------
From: davej@uicsrd.csrd.uiuc.edu
Subject: Curses & Color
Date: 14 Jun 88 12:18:00 GMT
Nf-ID: #N:uicsrd.csrd.uiuc.edu:45000015:000:990
Nf-From: uicsrd.csrd.uiuc.edu!davej Jun 14 07:18:00 1988
To: info-unix@SEM.BRL.MIL
I need to do colors with curses. Color is done by writing an escape
sequence to the display adapter which puts the display in the mode
for a particular color used for subsequently written chars.
The problem is the way curses trys to efficiently update the display.
It seems that 'cursrc' contains the current image of the actual display.
Assume the window I'm using is 'stdsrc'. If I write chars to 'stdscr' that
are intended to be in a new color, on a 'refresh' a char is actually
written to the display only if its char. value is different from that
in 'curscr'. So old chars may remain on the display in the incorrect
color.
I thought 'touchwin' was the answer to my problems, but all this
call seems to do is set some parameters so that the entire 'strdscr'
is compared against 'curscr' for differences; 'curscr' still acts as
a filter.
I'm sure somebody must have done colors with curses and has gotten
around this problem.
Any advice is greatly appreciated.
-----------------------------
From: James Harvey <jbh@mibte.uucp>
Subject: X.400 mail
Date: 15 Jun 88 13:04:58 GMT
Keywords: X.400, Unix, LAN, Help
To: info-unix@brl-sem.arpa
We are considering solutions for company wide E-Mail. There is a wide
variety of Local Area Networks (Apple, Novell Ethernet, ARCNet etc.)
and several NCR Unix boxes to be connected. Our Corporate Communica-
tions wants to buy Softswitch on an IBM mainframe or a DEC All-In-One
system to convert E-Mail formats but we are having problems with the
Towers. It looks like TCP/IP or X.25 communications may be available
for the NCR machines but I would like to use X.400 mailers or prefer-
ably a Unix to X.400 converter. My GREPping around the news directo-
rys has produced only two news items that even mention X.400.
Is there a Newsgroup that discusses X.400?
Does anyone know of an X.400 package for Unix?
Are we wasting our time looking at X.400?
Side issue unrelated to Unix... Has anyone ever connected a Novell
ARCNet to a Dec All-In-One for direct E-Mail?
--
Jim Harvey | "Ask not for whom the bell
Michigan Bell Telephone | tolls and you will only pay
29777 Telegraph | Station-to-Station rates."
Southfield, Mich. 48034 |
ihnp4!mibte!jbh or try ulysses!gamma!mibte!jbh
-----------------------------
From: King Ables <ables@hi3.aca.mcc.com.uucp>
Subject: Re: .mailrc
Date: 16 Jun 88 14:54:43 GMT
Posted: Thu Jun 16 09:54:43 1988
To: info-unix@SEM.BRL.MIL
in article <697@fxgrp.UUCP>, ljz@fxgrp.UUCP (Lloyd Zusman) says:
>
> If you really need this feature and you aren't totally sold on
> [mM]ail, you might wish to investigate the following alternative
> mailers: 'elm', 'mush', and 'mh'.
There's also MM from Columbia University which is a Unix version
of the Tops-20 MM mail manager. It's a very good port (rewrite)
of MM, as well. It has an option to do the exact thing he's asking
for, to be put directly into an editor to compose a message.
It comes in source form and is available via anonymous ftp from
cunixc.cc.columbia.edu. You can send mail to bug-mm@columbia.edu
if you can't get it via the internet, I imagine they can work out
a uucp transfer method.
I have nothing to do with MM or Columbia University except being
a very satisfied user of MM.
-king
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ables
-----------------------------
From: Guy Harris <guy@gorodish.sun.com>
Subject: Re: Rename bug?
Date: 16 Jun 88 17:59:56 GMT
Sender: news@sun.uucp
To: info-unix@brl-sem.arpa
> And thus, fails. The discussion is about a manner in which those
> different file systems do NOT provide the same system call interface.
> Some of them give an error for rename("foo","foo"), some delete "foo",
> some do nothing.
Geez, talk about "people unclear on the concept...." The discussion is about a
bug in some UFS implementations! This does NOT mean that there is some
inherent flaw in the VFS mechanism. This means that there is a flaw in some
UFS implementations; that particular flaw is fixed in SunOS 4.0.
> NFS and VFS do not guarantee the same semantics for different file
> systems.
No shit, Sherlock! VFS was *NEVER INTENDED* to support the exact same
semantics on all file systems; in some sense, that's the *point* of it! If,
as, and when "/proc" is implemented under VFS, for example, try doing a
"rename" on it; you're likely to be rudely surprised if you expect it to work -
UNIX generally considers it impolite to change process IDs of processes on the
fly. It might be amusing to consider having "unlink" do a "kill(pid,
SIGKILL)", but that wouldn't conform to UNIX semantics either, unless you made
the "/proc" directory sticky.
Making a particular file system fully or partially support the same semantics
as a UNIX on-disk file system is the responsibility of the author of the file
system code; it is NOT the responsibility of the VFS mechanism. NFS was not
designed to fully support UNIX file system semantics; some design compromises
were made in order to achieve goals other than full UNIX file system semantics.
You can debate whether these design compromises were correct or not (I don't
plan to do so; it's not germane to this discussion), but that's a different
matter.
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: Re: "cd path" strangeness
Date: 16 Jun 88 20:16:36 GMT
Keywords: csh cd xenix sysv
To: info-unix@SEM.BRL.MIL
In article <922@.UUCP> jbush@ficc.UUCP (james bush) writes:
In article <337@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes:
> Here is a wierd one. In csh, move to some directory which doesn't have
> a "path" subdirectory. Then type either "cd path" or "chdir path".
> ...
This is even more wierd. I tried it on our Intel Xenix system, and it worked
as you said when I did it under my login. However, when I tried to show it
to my friend under his id, it came up with the "expected" error message! I
am not sure what the difference is.
The wierd behavior described by Mr. Rosenthal is due to a little
known feature of the C shell:
If a shell variable is set to a value whose first character is a "/",
it can be used with cd without the leading dollar sign. For example,
suppose you have done the following:
set foo = /a/b/c/d/e
Then, the next two lines will have the exact same behavior:
cd $foo
cd foo
Here's the description in our csh man page:
cd [dir]
chdir [dir]
Change the shell's working directory to directory
dir. ...
... If dir is the name of a shell variable
whose value starts with a /, change to the direc-
tory named by that value.
Note that this works only with shell variables, not environment variables.
The wierd behavior described by Mr. Bush might be due to the fact that
his 'path' variable's first entry begins with a "/", while his friend's
'path' variable doesn't.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: Burt Janz <bhj@bhjat.uucp>
Subject: Microport S/386 and Appropriate Hardware
Date: 16 Jun 88 18:58:21 GMT
Followup-To: myself or this group (flames to /dev/null)
Keywords: Microport, Rose Hill, service, support
To: info-unix@brl-sem.arpa
Hello, world! |-)
I've been watching the net for some time now, and I've seen the complaints
about Microport's 386 UNIX, and about miscellaneous hardware combinations,
and some general commentary. I shot my mouth off before, and got shot back
at. I must be a glutton for punishment... 'cuz
it's my turn, again. |-) |-)
This is actually a very pleasant story. Grab some coffee, and relax.
It's also a bit long... sorry about that...
In April, I purchased a 386 system from Rose Hill Systems. They are in
Scotts Valley, just "down the road a'piece" from Microport. The support
fellas at Microport had good things to say about Rose Hill machines, and Rose
Hill was VERY cooperative when I called them up. A fella named Curt Meyer
spent LOTS of time with me describing the system, both in hardware and
in software terms. I expressed some hesitation about the way they did some
things (like running an 80386-16 at 20mhz), and they did their best to
allay my concerns.
Well, I purchased their System 81 in the tower configuration. I added a
Maxtor 1065 (drive type 12) and a Quantum Q540 (drive type 7) from my old
SV/AT system, brought over the 2mb BocaRam card (16-bit extended memory
running at 8mhz), and shoved in the Everex Stream-60 controller card.
Installation of S/386 went perfectly, first time. (I had pre-formatted the
drives with Vfeature Deluxe which, by the way, didn't find any defects.)
So, I'm running happily along (although I can't run the serial ports over
4800 baud... and I'm STILL having problems with the lp driver!), and the
system DIES!! My trusty dvm tells me that I have power, but it won't boot,
and the keyboard lights don't extinguish at POST. The drives run up and
synchronize, but... no joy at boot time.
I called Rose Hill, was given an RMA, and shipped my system on Friday,
June 11. I called on the 15th (I sent it 2 day overnight Emery), and was
told that the power supply was bad, and that they'd replace it, test the
system, and get it right back to me.
Today is the 17th. I'm typing this on my Rose Hill Model 81 tower.
NOW, THAT'S SERVICE!!!!!
(Oh, by the way, the system warrantee was 1 year, so there was no charge
on service. And they paid shipping back to me.)
Many people out there are complaining about the state of their hardware,
that they have problems using two drives (I don't...), that they have
problems using the compiler (I don't...), that they see too many bad points
about Microport to keep using it (I don't...), and that they're going to
buy Xenix and run it (I won't...). Having used Xenix, I'm MUCH happier with
Microport, both in the software itself (my needs REQUIRE SVID compatibility)
and in the support (they actually seem to know what's wrong, and how to patch
around it). Having been intimately familiar with how DEC does its support,
I'm much happer with Microport. Not having a SUN, I have nothing to compare
it to... but too many changes too quickly does not a stable release make!
I am also extremely satisfied with my choice of Rose Hill for my hardware.
Granted, things shouldn't break. But they do, or some engineer would never
have invented the term MTBF. Therefore, hardware service should play into
the purchase decision of any equipment. I happen to feel that, as far as
Rose Hill is concerned, the price/performance ratio was fine.
If you are still looking for a system, consider Rose Hill. If you are
still looking for UNIX, consider Microport.
If you are still unsatisfied, please... buy a source licence, and market
your OWN version of UNIX!!!! |-)
Disclaimer: The usual about not being employed by either Microport or
Rose Hill, and about just being a very satisfied customer of both.
PLEASE, if you want to flame, do it elsewhere. I'm trying to give some
constructive commentary on an unfortunate circumstance. Yes, I WAS down
for almost a week, but it could have been much longer, and much more
expensive!!!
---------
Burt Janz
..decvax!bhjat!bhj
-----------------------------
From: Andrew Lue <andrew@nsc.nsc.com>
Subject: Need decoder/encoder source to transfer binaries
Date: 16 Jun 88 19:44:32 GMT
Keywords: decode encode
To: info-unix@SEM.BRL.MIL
Does anyone know of programs which can encode and decode binaries?
If you do, please tell me where I can retrieve the source.
UUDECODE and UUENCODE won't help because I need to transfer binaries
between VMS and UNIX systems. FTP doesn't work well. We've had problems
with Kermit, too.
Why am I transfering binaries between these systems, you query?
I'm cross-compiling for a Series 32000-based target, and I have the
cross development tools on both hosts. Sometimes the load on one machine
is just too heavy, so I want to transfer some of the work to the other machine.
Thanks in advance for any assistance.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrew H. Lue {decwrl|sun}!nsc!andrew
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: DEC hardware manuals
Date: 16 Jun 88 14:37:32 GMT
To: info-unix@brl-sem.arpa
In article <1105@unmvax.unm.edu> mike@turing.unm.edu (Michael I. Bushnell)
writes:
>... DEC has a competitor for Ultrix, but the response has not been to
>improve Ultrix, it has been to keep hardware manuals secret so UCB
>can't write drivers.
Unless there is a conspiracy of which I am unaware (which is of course
possible), this is not why DEC clings to their hardware documentation
so tightly. Rather, it is in a (laughably ineffective) attempt to keep
hardware vendors like Emulex from gleaning some of `their' market share.
From my vantage point, the only thing this policy gets DEC is lost
sales, because I recommend against products for which detailed manuals
are not available.
(Ah well: we already have our revenge :-) , as the RISC machines sweep
past DEC while DEC's marketing dithers. If they had brought out their
RISC [nicknamed Titan, I believe] four years ago, they might have the
lead.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Michael Ryan <miker@wjvax.uucp>
Subject: troff -- bold italics
Date: 16 Jun 88 19:20:49 GMT
Keywords: bold italics lost
To: info-unix@brl-sem.arpa
the swank , but viciously terse, troff and -ms
documentation available to me has me at a loss. the problem ? bold italics.
at the beginning of paragraphs in the -ms document the key phrase is in
bold italics. at the tops of columns in the nroff/troff user's manual
voila! bold italics. they explain these are created using '.bd.'
to obtain bold italics one must use a construct '.bd I N' , N being the
level of enboldening. '.bd I' should turn off enboldening. the caveat ?
yes, 'The mode must be still or again in effect when the characters are
physically printed.' what ? oh I get it , but I can't get it to work.
I either get all bold italics, even after I believe I have stopped enboldening,
or I get no bold italics at all.
frustrated and tired , I am asking for some examples of working
bold italics.
I will gladly post a summary to comp.unix.wizards.
thanks,
michael
--
==== *michael j ryan
*{..!pyramid,..!decwrl!qubix}!wjvax!miker
*Watkins-Johnson Co., San Jose CA : (408) 435 1400 x3079
* above views are not necessarily those of Watkins-Johnson Co.
-----------------------------
From: David Goodenough <dg@lakart.uucp>
Subject: which shell does shell scripts
Date: 15 Jun 88 17:27:47 GMT
Followup-To: mail,dg@lakart.UUCP
To: info-unix@SEM.BRL.MIL
Flame me if this is old hat.
I've doctored the Followup-To to encourage ( :-) mail responses.
I use /bin/csh as my normal shell.
Hence if I execute a file whose mode is 755, and whose contents is ascii
text, my c-shell should exec(2) a sub-c-shell, and tell it to take the file
as normal input.
Why, then, is a '#! /bin/csh' needed in the following shell script?
--- cut here --- beginning of shell script ---
#! /bin/csh
foreach i (*.c)
cc -E -X23 -I/u1/vw/h/ -I../h/ -DCPU=MC68000 -DNOT_GENERIC $i >>&! typeds
end
grep typedef typeds | sort -u >&! typeds1
--- cut here --- end of shell script ---
MAIL - DON'T POST - responses
--
dg@lakart.UUCP - David Goodenough +---+
| +-+-+
....... !harvard!cca!lakart!dg +-+-+ |
+---+
-----------------------------
End of INFO-UNIX Digest
***********************