postmaster@uunet.uu.net (06/18/88)
Reason: local mail handler complained as follows
jmail: HuwR -- unknown user or mailbox
-------- rejected letter ---------
Via: 00004001015218/UCL-CS.FTP.MAIL ; 18 Jun 1988 08:32:51 GMT
Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel
id aa02872; 18 Jun 88 7:50 BST
Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP
id aa02857; 18 Jun 88 7:47 BST
Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab00152; 16 Jun 88 3:01 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa00117; 16 Jun 88 2:45 EDT
Date: Thu, 16 Jun 88 02:45:44 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#070
Message-ID: <8806160245.aa00117@SEM.BRL.ARPA>
Sender: info-unix-request@uk.ac.ucl.cs.nss
INFO-UNIX Digest Thu, 16 Jun 1988 V5#070
Today's Topics:
Re: afio
Re: .mailrc
Re: AT&T vs. CSS (PC/Tools)
Re: SYS V sigset(2)
Re: .mailrc
Re: utility to determine rlogin?
Re: C/IBM
QIC-xx tape standards
Re: a "trivial" sed question
A warning about read(2)/write(2)
Re: "cd path" strangeness
-----------------------------------------------------------------
From: John Gennari <gennari@bonnie.ics.uci.edu>
Subject: Re: afio
Date: 14 Jun 88 22:47:35 GMT
Sender: news@orion.cf.uci.edu
Keywords: how to use afio
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.
The syntax of the two programs is very different. The -i -o options are
similar but some of the options have reverse meaning from cpio (Mark "fixed"
them). In particular, the option for creating directories is backwards.
I think you're probably having probs because you are used to
$ find / -print | cpio > /dev/rfp021
Afio does not default to stdout, you specify the file.....
# create an archive of /:
$ find / -print | afio -o /dev/rfp021
# read back that archive (N.B.: afio does *not* include the leading "/",
# i.e., "/tmp/foo" is resoted as "tmp/foo", you must be in "/" if that's
# where you want things w/ absolute paths to go. This is a big win.):
$ cd /
$ afio -i /dev/rfp021
Larry Mcvoy (lm@arizona.edu, ...!sun!laidbak!lm)
John Gennari
-----------------------------
From: "Randall W. Robinson" <rrobinson@ames.arc.nasa.gov>
Subject: Re: .mailrc
Date: 15 Jun 88 14:28:13 GMT
To: info-unix@SEM.BRL.MIL
in article <4097@fluke.COM>, strong@tc.fluke.COM (Norm Strong) says:
>
> I would like to put something in my .mailrc file, so that I will automatically
> be in the vi editor when I invoke the mail program. Currently, I have to type
> ~v every time. Is there a way to do this?
> --
>
> Norm (strong@tc.fluke.com)
Try putting a 'setenv EDITOR=/usr/bin/vi' (or whatever the path
is) in your .login. This should do it.
Randy
rrobinson@ames.arc.nasa.gov
-----------------------------
From: "Wolf N. Paul" <wnp@dcs.uucp>
Subject: Re: AT&T vs. CSS (PC/Tools)
Date: 15 Jun 88 12:18:44 GMT
Keywords: AT&T, lawsuit, CSS, PC/Tools
To: info-unix@brl-sem.arpa
In article <308@marob.MASA.COM> samperi@marob.UUCP (Dominick Samperi) writes:
>I started this discussion, and I'm not sure that the original question is
>being addressed: the article said that AT&T won a settlement against CSS
>because CSS "used ideas from UNIX." Source code copying may not have been
>the issue. The question is: if I develop tools that have the same (or more)
>functionality as some of the standard UNIX tools (ls, rm, cpio, tar, etc.),
>then can I use the same program names? And if not, can I use the word "UNIX"
>in describing the functionality of the tools? Does MKS have a license from
>AT&T?
If they did, I am sure AT&T would require them to display a copyright notice
to that effect somewhere. However, all their disks, manuals, etc, only show
a MKS copyright.
There are also numerous other examples of people developing functional clones
of UNIX -- including the same names for commands -- without AT&T taking any
action: Regulus, Coherent, Minix, etc.
There are numerous PD programs which duplicate UNIX functionality, and which
AT&T is surely aware of because they are distributed over this network:
PD Tar, AFIO (a cpio clone), GNU AWK, etc. No action was taken against any
of these by AT&T. In fact, John Gilmore had a letter from AT&T's legal dept.
stating that UUSLAVE, which is functionally equivalent to uucico, did not
contain any AT&T code and did not infringe on their rights.
That's why I am not sure that the CSS case has the impact Dominick hints at
above.
And finally, as I said in my original reply, I heard from someone in the orbit
of the CSS principals that they were almost certain that CSS had had access to
VI source code, and that was right after PC-VI first appeared.
Since ATT&T and CSS settled out of court, there is no knowing what AT&T would
have ended up showing and arguing in court, unless CSS violates the terms of
the settlement and the thing comes to trial after all.
--
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP: ihnp4!killer!dcs!wnp ESL: 62832882
DOMAIN: wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD
-----------------------------
From: Jeff Bowles <bowles@lll-crg.llnl.gov>
Subject: Re: SYS V sigset(2)
Date: 15 Jun 88 14:36:44 GMT
Sender: usenet@lll-winken.llnl.gov
Keywords: sigset(2) signal(2) SYSV.3.0
To: info-unix@SEM.BRL.MIL
In article <507@micropen> dave@micropen (David F. Carlson) writes:
>
>I have a program in which it is "useful" to have reliable signals,
>and therefore I must use sigset(2) (under System Vr3.0).
>
Now, before going any further, repeat after me: "System V Release N+1
must not change functionality of programs compiled to run under System V
Release N."
The reason that there are new system calls to support things you'd expect
are two-line mods to existing system calls (like sigpause(2) springing up)
boil down to the above compatibility goal. We can argue about whether
SVR3 is incompatible with previous releases, but this is why.
>Problem is that the man pages tell me that when I am in a handler the
>signal is automatically set to SIG_HOLD. (Goes on to describe a troubled
>stack in a dying program.)
>Of course, the exclusive resource assumed by the signal handler is
>locked by a previous entry and deadlock results.
(Red light goes on.) If you need to exclusively lock something, why not
use the file-record locking calls or semaphores?
> How does sigpause(2) differ from pause(2) for waiting? The man pages
> detail dire consequences for mixing signal(2) and sigset(2) but I see
> little relation between pause(2) and sigset(2). Is there a hidden hazard
> or is this only a problem of wating within a signal handler itself?
Remember that pause(2) doesn't check for held signals - you could sleep on a
signal that's currently held....
Jeff
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: Re: .mailrc
Date: 15 Jun 88 19:07:30 GMT
To: info-unix@SEM.BRL.MIL
In article <10371@ames.arc.nasa.gov> rrobinson@ames.arc.nasa.gov (Randall W. Robinson) writes:
in article <4097@fluke.COM>, strong@tc.fluke.COM (Norm Strong) says:
>
> I would like to put something in my .mailrc file, so that I will automatically
> be in the vi editor when I invoke the mail program. Currently, I have to type
> ~v every time. Is there a way to do this?
> ...
Try putting a 'setenv EDITOR=/usr/bin/vi' (or whatever the path
is) in your .login. This should do it.
Nope. Sorry, but this does *not* do it in any of the [mM]ail programs
I've ever run. All that does is tell the mail program that when you
type "~e", you should get put into /usr/bin/vi to edit your mail message.
Upon closer reading of the original question, you can see that Mr.
Robinson was asking how he can automatically get put into 'vi' WITHOUT
having to type "~v" (or "~e", I presume). As far as I know, there is
no way to do this in any of the [mM]ail programs I've seen. I once
hacked up a private version of Mail to do this exact thing, but I was
at a site that had a BSD source license and I unfortunately was not
allowed to take my source code with me when I left.
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'.
--
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: "Randall W. Robinson" <rrobinson@ames.arc.nasa.gov>
Subject: Re: .mailrc
Date: 15 Jun 88 22:54:08 GMT
To: info-unix@SEM.BRL.MIL
in article <697@fxgrp.UUCP>, ljz@fxgrp.UUCP (Lloyd Zusman) says:
>
> In article <10371@ames.arc.nasa.gov> rrobinson@ames.arc.nasa.gov (Randall W. Robinson) writes:
> in article <4097@fluke.COM>, strong@tc.fluke.COM (Norm Strong) says:
> >
... and so on ad infinitum
> Nope. Sorry, but this does *not* do it in any of the [mM]ail programs
> I've ever run. All that does is tell the mail program that when you
> type "~e", you should get put into /usr/bin/vi to edit your mail message.
>
> Upon closer reading of the original question, you can see that Mr.
> Robinson was asking how he can automatically get put into 'vi' WITHOUT
> having to type "~v" (or "~e", I presume). As far as I know, there is
> no way to do this in any of the [mM]ail programs I've seen. I once
> hacked up a private version of Mail to do this exact thing, but I was
> at a site that had a BSD source license and I unfortunately was not
> allowed to take my source code with me when I left.
> Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Hmmmm.... Ok, on both the system here at work and my system at
home the EDITOR var sets the default editor for most of the
operations on these systems. This may not be the case for all
systems or programs. The standard mailers on systems really is
one of the exceptions. If there is another mailer added to the
system (ie. elm) then it would be picked up by the mailer going
in.
- Lloyd, you might want to reread the the posting. I, "Mr.
Robinson", did not post the question, I only responed to Norm
Strong's posting.
-- Randy
rrobinson@ames.arc.nasa.gov
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: 'shartools' patch02 wanted.
Date: 15 Jun 88 23:33:22 GMT
To: info-unix@SEM.BRL.MIL
Can anyone direct me to patch02 for Rich Salz's recent 'shartools'
posting in comp.sources.*? I have patch01 and patch03, but somehow
I lost patch02.
Please reply via email.
Thanks in advance.
--
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: Rick Lindsley <richl@penguin.uss.tek.com>
Subject: Re: utility to determine rlogin?
Date: 15 Jun 88 22:49:12 GMT
Sender: news@puffin.uss.tek.com
To: info-unix@SEM.BRL.MIL
Jerry Peek <jerryp@cmx.npac.syr.edu> writes:
So, setting up my .login was easy. I put a test like this one in it:
switch ("`ttykind`")
case network:
# do stuff for network login
case xxx:
# do stuff for xxx login
default:
In article <16109@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes:
Why not just do `switch ($term)'? You don't need ttykind, except for
finding out *other* peoples terminal types.
Because rlogin will pass the terminal type across for you. $term may not
provide the information you want.
Rick
-----------------------------
From: Christian Rohrmueller <doit@altger.uucp>
Subject: Re: C/IBM
Date: 14 Jun 88 12:11:04 GMT
Posted: Tue Jun 14 13:11:04 1988
To: info-unix@brl-sem.arpa
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've never worked with it. Just got some information materials.
Hope that helps,
Christian
-----------------------------
From: Dominick Samperi <samperi@marob.masa.com>
Subject: QIC-xx tape standards
Date: 16 Jun 88 02:54:53 GMT
Keywords: magtape standards, QIC
To: info-unix@brl-sem.arpa
Where can one find the QIC-xx streaming tape standards documented? In
particular, QIC-02 describes the command set, and QIC-24 describes one
of the more common formats. These standards are referred to everywhere,
yet I've never seen them described. Thanks.
--
Dominick Samperi, NYC
samperi@acf8.NYU.EDU samperi@marob.MASA.COM
cmcl2!phri!marob uunet!hombre!samperi
(^ ell)
-----------------------------
From: Leo de Wit <leo@philmds.uucp>
Subject: Re: a "trivial" sed question
Date: 13 Jun 88 05:09:19 GMT
To: info-unix@brl-sem.arpa
In article <512@cogen.UUCP> alen@cogen.UUCP (Alen Shapiro) writes:
>I know the answer is 'use tr -d "\012"' but here is the question;
>
>Is there a way USING SED to remove all <NL> chars from a file. This is
[40 lines deleted]
From an sed addict:
I don't think this can be done for any size of file. I'll explain:
Whenever sed outputs a line, it has a trailing newline. The best you can
do is thus create one big line containing all lines of the file and remove
newlines from it (all but the last). You already indicated that you can use
N to add to the pattern space. The problem is: this pattern space has of
course a limited size (don't know if it is malloc'ed or just a big buffer)
unless sed swaps this space to the disk (don't think so). Think your core
dump was due to running out of buffer space. If your file is small enough,
you could do:
sed -n -e '
1h
2,$H
${
x
s/\n//g
p
}' your_file
This doesn't need labels (look Ma, no GOTO's! 8-).
Leo.
-----------------------------
From: ok@quintus
Subject: A warning about read(2)/write(2)
Date: 16 Jun 88 02:18:31 GMT
Sender: news@quintus.uucp
To: info-unix@SEM.BRL.MIL
Amongst the goodies recently posted to comp.sources.unix was one whose
README file said that it was a rewrite of a public domain version, and
that one of the changes that had been made was to use read(2)/write(2)/
lseek(2)/open(2)/close(2) for I/O instead of using stdio.
THAT WAS A BAD IDEA.
If you want to make your program's I/O more efficient, simply replacing
stdio calls by low-level UNIX calls is not a good idea. If you use
stdio, that package will do I/O a buffer at a time, so you only get a
system call (and a disc access) when a buffer is filled or emptied.
The package I am talking about was reading and writing 56 byte chunks,
so it was doing a system call and a disc access for every 56 bytes.
(And since 56 does not divide 8192 evenly, some of these transfers
could cost two disc accesses.)
To make your disc I/O more efficient, do as few transfers as possible,
and do as much useful work as you can in each transfer. For example,
in this balanced tree package, it would have been a good idea to keep
the tree as a tree of 8k "pages", each page containing a set of keys
(128 64-byte nodes would fit into a page, reducing the number of
disc accesses required by a factor of 7).
[This isn't a question, but it is the answer to a question that _should_
have been asked before the package was written.]
-----------------------------
From: james bush <jbush@ficc.uucp>
Subject: Re: "cd path" strangeness
Date: 15 Jun 88 20:46:54 GMT
Keywords: csh cd xenix sysv
To: info-unix@brl-sem.arpa
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".
>
> The expected response would be "path: No such file or directory." Instead,
> no message is issued, and either you stay where you were or you move to
> $path[1]...
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.
--
James Bush, Ferranti, Houston Praise the Lord
Internal address: jbush extension 5230, mail stop A/3204, room A/3602
External address: ..!uunet!nuchat!sugar!ficc!jbush
-----------------------------
End of INFO-UNIX Digest
***********************