Warning From uucp
codas!uucp
uucp at codas.att.com
Tue Jun 21 19:35:14 AEST 1988
We have been unable to contact machine 'novavax' since you queued your job.
novavax!mail proxftl!rafael (Date 06/19)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
uustat -knovavaxN4ea9
Sincerely,
codas!uucp
#############################################
##### Data File: ############################
>From moss!arpa!brl.arpa!INFO-UNIX Sun Jun 19 11:26:07 1988 remote from codas
Received: by codas.att.com (smail2.5)
id AA05296; 19 Jun 88 11:26:07 EDT (Sun)
Received: by moss.ATT.COM (smail2.5)
id AA07118; 19 Jun 88 11:23:11 EDT (Sun)
Received: by rutgers.edu (5.54/1.15)
id AA01804; Sun, 19 Jun 88 09:31:08 EDT
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 at brl.arpa>
To: INFO-UNIX at brl.arpa
Reply-To: INFO-UNIX at brl.arpa
Subject: INFO-UNIX Digest V5#070
Message-Id: <8806160245.aa00117 at SEM.BRL.ARPA>
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 at bonnie.ics.uci.edu>
Subject: Re: afio
Date: 14 Jun 88 22:47:35 GMT
Sender: news at orion.cf.uci.edu
Keywords: how to use afio
To: info-unix at SEM.BRL.MIL
In article <4449 at killer.UUCP> jlg at 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 at arizona.edu, ...!sun!laidbak!lm)
John Gennari
-----------------------------
From: "Randall W. Robinson" <rrobinson at ames.arc.nasa.gov>
Subject: Re: .mailrc
Date: 15 Jun 88 14:28:13 GMT
To: info-unix at SEM.BRL.MIL
in article <4097 at fluke.COM>, strong at 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 at 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 at ames.arc.nasa.gov
-----------------------------
From: "Wolf N. Paul" <wnp at 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 at brl-sem.arpa
In article <308 at marob.MASA.COM> samperi at 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 at dcs.UUCP TLX: 910-280-0585 EES PLANO UD
-----------------------------
From: Jeff Bowles <bowles at lll-crg.llnl.gov>
Subject: Re: SYS V sigset(2)
Date: 15 Jun 88 14:36:44 GMT
Sender: usenet at lll-winken.llnl.gov
Keywords: sigset(2) signal(2) SYSV.3.0
To: info-unix at SEM.BRL.MIL
In article <507 at micropen> dave at 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 at fxgrp.uucp>
Subject: Re: .mailrc
Date: 15 Jun 88 19:07:30 GMT
To: info-unix at SEM.BRL.MIL
In article <10371 at ames.arc.nasa.gov> rrobinson at ames.arc.nasa.gov (Randall W. Robinson) writes:
in article <4097 at fluke.COM>, strong at 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 at ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz at ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: "Randall W. Robinson" <rrobinson at ames.arc.nasa.gov>
Subject: Re: .mailrc
Date: 15 Jun 88 22:54:08 GMT
To: info-unix at SEM.BRL.MIL
in article <697 at fxgrp.UUCP>, ljz at fxgrp.UUCP (Lloyd Zusman) says:
>
> In article <10371 at ames.arc.nasa.gov> rrobinson at ames.arc.nasa.gov (Randall W. Robinson) writes:
> in article <4097 at fluke.COM>, strong at 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 at ames.arc.nasa.gov
-----------------------------
From: Lloyd Zusman <ljz at fxgrp.uucp>
Subject: 'shartools' patch02 wanted.
Date: 15 Jun 88 23:33:22 GMT
To: info-unix at 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 at ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz at ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: Rick Lindsley <richl at penguin.uss.tek.com>
Subject: Re: utility to determine rlogin?
Date: 15 Jun 88 22:49:12 GMT
Sender: news at puffin.uss.tek.com
To: info-unix at SEM.BRL.MIL
Jerry Peek <jerryp at 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 at brl-adm.ARPA> rbj at 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 at 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 at brl-sem.arpa
In article <10565 at agate.BERKELEY.EDU> arnold2 at 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 at marob.masa.com>
Subject: QIC-xx tape standards
Date: 16 Jun 88 02:54:53 GMT
Keywords: magtape standards, QIC
To: info-unix at 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 at acf8.NYU.EDU samperi at marob.MASA.COM
cmcl2!phri!marob uunet!hombre!samperi
(^ ell)
-----------------------------
From: Leo de Wit <leo at philmds.uucp>
Subject: Re: a "trivial" sed question
Date: 13 Jun 88 05:09:19 GMT
To: info-unix at brl-sem.arpa
In article <512 at cogen.UUCP> alen at 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 at quintus
Subject: A warning about read(2)/write(2)
Date: 16 Jun 88 02:18:31 GMT
Sender: news at quintus.uucp
To: info-unix at 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 at ficc.uucp>
Subject: Re: "cd path" strangeness
Date: 15 Jun 88 20:46:54 GMT
Keywords: csh cd xenix sysv
To: info-unix at brl-sem.arpa
In article <337 at vector.UUCP>, chip at 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
***********************
More information about the Comp.unix.questions
mailing list