Unix-Wizards-Request@BRL.ARPA (The Moderator) (12/14/87)
UNIX-WIZARDS Digest Sat, 12 Dec 1987 V4#098
Today's Topics:
Re: Command interfaces
Re: Disk striping? (4.3 BSD)
Re: Setting process groups
Re: login prompt not staying set
Re: How much hair? (was "Command interfaces")
Command interface interim suggestion
Re: rdump, Ethernet slowness
Need to connect RP06 to unibus (Help!)
Re: Is process <n> alive?
Re: The whole prompt string thing (
Re: spell
Re: Setting process groups
Re: Has tar r ever worked? For anybody?
Re: rdump, Ethernet slowness
Re: How much hair? (was "Command interfaces")
Re: Has tar r ever worked? For anybody?
BSD 4.x available on a 3B5 ???
BSD at AT&T (was Re: ACCESS TO SHARED TAPEDRIVES)
Re: Is process <n> alive?
Re: spell
Re: Kernel Timings with MicrovaxII
Re: Looking for DMF-32 sync port IP driver for 4.3BSD
Re: Re: Request for human interface design anecdotes
Re: globbing in the shell (Was Re: more rm insanity)
ditroff device description trouble
UDA-50 error messages
Wait, Select, and a SIGCHLD Race Condition
System Industries Disk Cache Processor and 4.3 vaxen
curses/terminfo
Pagedaemon
getlogin(3C) returns bogus name
Re: Is process <n> alive?
Re: a solution to the RM insanity
C version of ps: From whence doeth the info cometh?
Re: Is process <n> alive?
Re: rdump, Ethernet slowness
Wanted: Unix callback software
Unix on an apollo
How to set priority of a running task
Re: Wait, Select, and a SIGCHLD Race Condition
Wanted: Opinions on Unix on Mainframes
Re: C version of ps: From whence doeth the info cometh?
Re: How to set priority of a running task (LONG)
Re: Wait, Select, and a SIGCHLD Race Condition
Re: Command interfaces
quotas for printing under BSD UNIX
Re: ditroff device description trouble
Re: more rm insanity - a suggestion.
Re: //host vs "mount point"
Yet more on command interfaces
Re: Has tar r ever worked? For anybody?
Non-writes to /tmp
Re: //host vs "mount point"
Re: getlogin(3C) returns bogus name
Re: Request for human interface design anecdotes
Re: Wait, Select, and a SIGCHLD Race Condition
-----------------------------------------------------------------
From: Bob Larson <blarson@skat.usc.EDU>
Subject: Re: Command interfaces
Date: 10 Dec 87 00:42:09 GMT
Sender: nobody@oberon.USC.EDU
To: unix-wizards@SEM.BRL.MIL
In article <3167@psuvax1.psu.edu> schwartz@gondor.cs.psu.edu (Scott E. Schwartz) writes:
>In article <5565@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes:
>>In article <3161@psuvax1.psu.edu> schwartz@gondor.psu.edu (Scott E. Schwartz) writes:
>Agreed, to some extent. But the dark underside of the primos command
>processor is that you can't ever have more functionality than it gives
>you at the moment.
Not true, since it allows access to functions that may be user written, and
is a programming language in itself.
[example in answer to my question ommited. The shortest one I received via
mail. (It took advantage of a feature of diff that the others didn't.)
>By the way, how does primos handle something like
> ls [!B]*.[!c]
>i.e. multiple internal negation.
Primos does not dirrectly support double negation, however it also has
CPL (equivelent to shell scripts):
&do i &list [wild ^@@.c]
&if [substr %i% 1 1] ^= B &then type %i%
&end
Substite dir for type if you want to add options.
If anyone cares to notice this doesn't handle large directories, I
would note that unix lacks (to my knolage) any reasonable way to
handle large wildcard expantion, and that fixing the above cpl take 1
more line.
I don't plan on continuing the command processor debate, like editors,
it is mainly a matter of personal preference. I think primos handles
the common case of name generation nicely (without any ambiguities
such as those mentioned about an unspecified os in a different
message), but lacks direct support for multiple negation. (A rare
case for me.) (Where the primos command processor realy looses is in
lack of general-purpouse redirection, pipes, and easy handling of
multi-tasking.)
--
Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list: info-prime-request%fns1@ecla.usc.edu
oberon!fns1!info-prime-request
-----------------------------
From: Don Speck <mangler@csvax.caltech.edu>
Subject: Re: Disk striping? (4.3 BSD)
Date: 10 Dec 87 08:25:59 GMT
To: unix-wizards@SEM.BRL.MIL
In article <2369@emory.uucp>, arnold@emory.uucp (Arnold D. Robbins {EUCC}) writes:
> However, there is a limited form of disk striping already in the BSD
> kernel: /dev/swap! One can swap on more than one physical disk at a time.
>
> My question is, how general or non-general are the mechanisms used in
> putting together the swap device?
During a time when it looked like my boss would only buy small disks
(Eagles), I started writing a pseudo-device to stripe several partitions
together.
Chris Torek pointed out that it's easy to do for the raw device:
supply physio() with an appropriate (*minphys)() routine that will
chop up the I/O and bump the blkno and buffer address.
But for the block device it's messy. You can't just fudge the blkno
and buffer address, because those are the property of the buffer cache,
and may be inspected by getblk() at ANY TIME. So you have to construct
one or more new buf structures, and use B_CALL to merge the relevant info
back to the original buf. (Which means you can't use the stripe driver
for a swap device. What's that you say? Oh, the real swap device gets
around this by only providing a character device).
The really ugly part is allocating those new buf structures. You can
rip them off from either the buffer cache or the swap headers, but
either way, there may not be any available when you ask, so you might
have to sleep(). The problem is that strategy routines aren't supposed
to sleep(), because they might be called at interrupt time. I think ND
may be the only thing that does this, but I'm not sure.
I never got around to testing the code, partly due to lack of empty
partitions.
So no, the mechanism used in the swap device is not very general.
Don Speck speck@vlsi.caltech.edu {amdahl,scgvaxd}!cit-vax!speck
-----------------------------
From: "J. Collier" <james@cantuar.uucp>
Subject: Re: Setting process groups
Date: 9 Dec 87 14:11:17 GMT
Keywords: security setpgrp
Expires:
Sender:
Followup-To:
To: unix-wizards@brl-sem.arpa
Chris Torek (chris@mimsy.uucp) writes (from the unix-wizards digest):
>
>In article <13102@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>>BTW, while I was playing around with this, I noticed that the man page
>>for setpgrp(2) does not say it is an error to put yourself in an existing
>>process group.
>>
(extract from setpgrp(2) manual entry)
> [EPERM]
> The effective user ID of the requested process is different
> from that of the caller and the process is not a descendent
> of the calling process.
>So it is implicit in the section listing for `EPERM'.
I don't understand the relevance of this. Perhaps I'm mis-reading
Chris's article; if not..
Surely the `EPERM' section refers only to the ownership of the
calling process and the target process [ie the process specified by the
first argument to setpgrp()]. As Duncan says, the 4.3 BSD code does not
check the requested process group.
Duncan continues:
>Not that this causes any harm anyway - if you try to killpg a process group
>containing processes that don't belong to you, only your own get killed [..]
In BSD [at least] I believe the criminally gifted can still find modest
uses for setpgrp() in combination with one or two rather more serious
security flaws. I'm not sure if it can be considered a problem on its
own, though, and it would probably be expensive to tighten. Comments?
[Aside: I once tried using setpgrp()/getpgrp() for IPC in a
program where process groups were not needed for the usual purposes -
instant parameterised signals, and cheap too!]
-------------------------
James Collier Internet(ish): james@cantuar.{uucp,nz}
Computer Science Dept., UUCP: {watmath,munnari,mcvax}!cantuar!james
University of Canterbury, Spearnet/Janet: j.collier@nz.ac.canty
Christchurch, New Zealand. Office: +64 3 482 009 x8356 Home: +64 3 554 025
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.COM>
Subject: Re: login prompt not staying set
Date: 9 Dec 87 17:51:39 GMT
Sender: nobody@tekecs.TEK.COM
To: unix-wizards@SEM.BRL.MIL
[]
"It would be much easier to tell login to exit after printing
"login incorrect" (and letting init re-start the getty), but
then you run into the problem of the last closed process
hanging up the line (if hupcl is set, which you DO normally
want done) which would screw up anyone coming in through a
properly set up modem (it would, of course, not affect
hardwired terminals)."
And on non-modem but shared lines, getty will reset the baud rate to
the default, so you have to cycle with the break key after every missed
password. Frustrating.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Robert Reed <bobr@zeus.TEK.COM>
Subject: Re: How much hair? (was "Command interfaces")
Date: 10 Dec 87 00:06:50 GMT
To: unix-wizards@brl-sem.arpa
In article <22244@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
'seems to desired only rarely' is a red flag. Within a particular language
one very tends to do that which can be done easily within the language.
For example, FORTRAN has no natural mechanism for recursion. One can do
recursion in FORTRAN, albeit painfully. Is it any surprise that FORTRAN
programmers rarely find a need for recursion? The same holds true of
command languages as well -- if a particular approach cannot be
implemented readily in a command language, then it won't be used.
It seems that you've never tried writing a quicksort or any tree traversal
methods in FORTRAN. I've done both, and can attest to the inaccuracy of
your statement:
Is it any surprise that FORTRAN programmers rarely find a need for
recursion?
It has been my experience that certain programmers will be willing to fight
extreme levels of hair to accomplish a given task. They may not like it,
but given the available tools and the requirements of their task, what are
they to do?
You also seem to be confusing goals with methods. The Primos and "sh"
methods are alternatives for doing the pairwise matching of files from two
directories. The methods chosen for accomplishing the task will vary with
the facilities available (e.g. use an insertion sort rather than a
quicksort), but that doesn't discount the task. In my own experience,
pairwise matching of filenames is an occasional but a rare requirement,
regardless of the command processor I happen to be using.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
-----------------------------
From: Jon 'Quality in - Quantity out' Foreman <physh@unicom.uucp>
Subject: Command interface interim suggestion
Date: 10 Dec 87 03:40:53 GMT
Keywords: command interface, globbing, tomfoolery, kudgery
To: unix-wizards@SEM.BRL.MIL
As everyone knows, unix figures out how to run something by
examining it magic number (or for shell scripts, its lack thereof.) I
have often found a need for overriding a shells behavior of treating
* and ? etc, as special in someway. For instance, I always wanted
programs like "send" and "reply" from TOPS 20, so under UNIX I could
say: "send bar I'll meet you for lunch?" and bar could "reply sure!"
and not have it choke on the quote, question mark or exclaimation point.
Since the binary images have so much extra information in them
already (symbol table, reloadability when pure, etc), why not add yet
another optional header, say 1024 bytes long, which defines how
arguments are supposed to be handled? Then a command interpreter such
as sh(1) or csh(1) or tcsh(1?) etc. can just open the file, read 1024
and have some method of resolving such sillyness. The kernel could
recognize this header and just skip over it if it doesn't need anything
from it.
Even just a mechanism in the shell to do this on named programs
would be nice (sorta like alias, say, unglob send; unglob reply.)
--
{ucbvax,hoptoad}!\ ~~~~~~~\~~~ That's spelled
{lll-lcc,hplabs}!well!unicom!physh Jon }() "physh" and
{ptsfa,dual}!/ / pronounced "fish".
-----------------------------
From: Don Speck <mangler@cit-vax.Caltech.EDU>
Subject: Re: rdump, Ethernet slowness
Date: 10 Dec 87 08:59:55 GMT
To: unix-wizards@brl-sem.arpa
In article <14115@oddjob.UChicago.EDU>, matt@oddjob.UChicago.EDU (Ke Kupua) writes:
> excruciating! It takes about 4 hours to [r]restore a level 0 dump of a
> 175MB partition.
That's 12 Kbytes/sec, a magic number. It's the rate you get if
tcp_recvspace is too much bigger than tcp_sendspace.
To save on acknowledgements, an ack is not sent until 35% of
tcp_recvspace bytes have been received. The 4.3bsd /etc/rrestore
does an ioctl to raise the receive buffer for its socket (to the
same as the block size - 10K). The sender's buffer is probably
smaller than 35% of 10K, and hence can't send that much data
without getting an acknowledgement; and things just sit there
until the receiver's TCP times out and decides to send an ack.
Try removing the SOL_SOCKET stuff from rrestore. It was a nice
idea, but doesn't interoperate very well.
You have the same problem in rdumping from a 4.2bsd machine to
a 4.3bsd /etc/rmt.
Don Speck speck@vlsi.caltech.edu {amdahl,scgvaxd}!cit-vax!speck
-----------------------------
From: Don Speck <mangler@csvax.caltech.edu>
Subject: Re: rdump, Ethernet slowness
Date: 10 Dec 87 08:47:04 GMT
To: unix-wizards@brl-sem.arpa
In article <1268@laidbak.UUCP>, mdb@laidbak.UUCP (Mark Brukhartz) writes:
> I believe that the /etc/rmt protocol, used by rdump, is synchronous. Each
> I/O operation is acknowledged (back through the Ethernet) before the next
> one is begun.
That wasn't the bottleneck. The problem lies in this section:
In article <788@hsi.UUCP>, stevens@hsi.UUCP (Richard Stevens) writes:
> 52,000 bytes/sec - speed of a C program writing 1000 32768-byte
> buffers to another process on the other system,
> across the Ethernet, using a stream socket, as
> in the 552,000 bytes/sec example given above.
52Kbytes/sec of tcp throughput is ATROCIOUS for a VAX/785 with a good
Ethernet board like an Interlan NI1010A. My 750's, with the same kind
of Ethernet board, do 88 Kbytes/sec with reads of that size. I cannot
account for why his throughput would be this poor. Any ideas?
Don Speck speck@vlsi.caltech.edu {amdahl,scgvaxd}!cit-vax!speck
-----------------------------
From: Al Arthur <aca@nyit.uucp>
Subject: Need to connect RP06 to unibus (Help!)
Date: 8 Dec 87 23:44:23 GMT
Keywords: RP06, unibus, vax 11/730
To: unix-wizards@brl-sem.arpa
Does anyone out there have any experience with putting an
RP06 on a Vax unibus?
I have a Vax 11/730, with an R80 and an rl02, running 4.3BSD.
My problem is that I have no disk space (as you can imagine).
I also have an RP06, and a unibus controller from a PDP-11/44 (Is
that an RH11?).
I would like to put this RP06 and controller on the vax,
but don't know if my proposed configuration will work out.
I would imagine that I could use the `up' driver, if I could
make the physical connection work out. If anyone has experience
or suggestions, could you please let me know?
Thanks,
Al
~~
--
Alex Arthur, System Programmer/UUCP Administrator
New York Institute of Technology - Computer Graphics Laboratory
Gerry House, Old Westbury, New York 11568
Phone:(516) 686-7644 UUCP: ...!philabs!nyit!aca
-----------------------------
From: Dave Cohrs <dave@spool.wisc.EDU>
Subject: Re: Is process <n> alive?
Date: 10 Dec 87 15:52:57 GMT
Sender: news@spool.wisc.EDU
To: unix-wizards@SEM.BRL.MIL
In article <429@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>Is there a universal way that will work on any Unix to write a function
> isprocess(n)
>which returns TRUE if process n is alive, and FALSE if it isn't alive?
Any Unix? Well, if the Unix acts like either 4.3BSD or SysV, the
following should work:
int
isprocess(n)
int n;
{
extern int errno;
return (kill(n,0) == 0 || errno != ESRCH);
}
If you read the 4.3BSD kill(2) man page, you see that kill still
does permission checks, so you have to check errno upon return
to make sure that the error isn't EPERM, meaning the process is
alive, but you can't send it signals.
This works on SysV as well. I tested it.
Dave Cohrs
+1 608 262-6617 UW-Madison Computer Sciences Department
dave@cs.wisc.edu ...!{harvard,ihnp4,rutgers,ucbvax}!uwvax!dave
-----------------------------
From: Dave Cohrs <dave@spool.wisc.EDU>
Subject: Re: Is process <n> alive?
Date: 10 Dec 87 15:52:57 GMT
Sender: news@spool.wisc.EDU
To: unix-wizards@SEM.BRL.MIL
In article <429@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>Is there a universal way that will work on any Unix to write a function
> isprocess(n)
>which returns TRUE if process n is alive, and FALSE if it isn't alive?
Any Unix? Well, if the Unix acts like either 4.3BSD or SysV, the
following should work:
int
isprocess(n)
int n;
{
extern int errno;
return (kill(n,0) == 0 || errno != ESRCH);
}
If you read the 4.3BSD kill(2) man page, you see that kill still
does permission checks, so you have to check errno upon return
to make sure that the error isn't EPERM, meaning the process is
alive, but you can't send it signals.
This works on SysV as well. I tested it.
Dave Cohrs
+1 608 262-6617 UW-Madison Computer Sciences Department
dave@cs.wisc.edu ...!{harvard,ihnp4,rutgers,ucbvax}!uwvax!dave
-----------------------------
From: Ron Natalie <ron@topaz.rutgers.EDU>
Subject: Re: The whole prompt string thing (
Date: 10 Dec 87 19:58:32 GMT
To: unix-wizards@brl-sem.arpa
The PS1 string in the Bourne shell is not reevaluated prior to printing
(unless you modify the source as some have suggested). Again, the best
way to do this is to change the prompt by defining a function (in 5R2
or later) to replace cd that changes the prompt. It is definately a lose
to run 'pwd' on every prompt to set it when you can only change it by
the "cd" command, you only need to do that work when cd'ing. You can
also add popd and pushd at the same time.
-Ron
-----------------------------
From: Dan Kegel <dan@srs.uucp>
Subject: Re: spell
Date: 10 Dec 87 13:59:41 GMT
To: unix-wizards@SEM.BRL.MIL
> I recently ran spell on a short letter. Of the three mistakes in the
> letter, it missed two, an atypically bad record.
> The first was "lager" for "larger". Clearly "lager" is a perfetly [sic] good
> word if you are a beer drinker [but it shouldn't be in MY dictionary] ...
Here's a modest proposal:
What if spelling checkers didn't just check the spelling of the word, but
also whether it was likely in the given context?
IBM's speech recognizer does exactly this sort of processing, so don't say
it's impossible.
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: Setting process groups
Date: 10 Dec 87 18:16:40 GMT
Keywords: security setpgrp
To: unix-wizards@SEM.BRL.MIL
In article <251@cantuar.UUCP> james@cantuar.UUCP (J. Collier) writes:
>... Perhaps I'm mis-reading Chris's article; if not..
No. I was wrong, and the security hole exist. Sorry about that.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Larry Autry <larry@sgistl.SGI.COM>
Subject: Re: Has tar r ever worked? For anybody?
Date: 10 Dec 87 16:17:01 GMT
Keywords: tar
To: unix-wizards@SEM.BRL.MIL
In article <22121@ucbvax.BERKELEY.EDU>, bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes:
> In article <1344@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) writes:
> > Under 4.3BSD, has anybody ever been able to add files to an existing
> > tar tape with tar r? When we try it the tape goes around and it
> > appears to be doing something, but then when we tar t the files are
> > not there.
>
On the SGI Iris 3030 'tar r' is known not to work with 1/4" tapes.
However, unless you absolutely must append to the original and only tar file
on the tape there is an alternate method. Using the 'mt' utility if it is
available on your system, space the tape past the first tar file. Additional
files can be added to the tape. This accomplished by using the non-rewind
device number as the output device. If 'mt' is not available, try using
'tar t2'.
example: mt fsf 1
tar cv2 . (uses /dev/rmt2 as output)
mt rew
and of course to retrieve;
mt rew
mt fsf 1
tar xv2
mt rew
This can be used for cpio as well. I realize that this does not address the
actual problem of appending to files. It does however solve the problem of
wasting cartridge tapes by having only one file on the entire tape.
disclaimer - It worked for me on my system, good luck.
--
Larry Autry
larry@sgistl.sgi.com
or
{ucbvax,sun,ames,pryamid,decwrl}!sgi!sgistl!larry
-----------------------------
From: Griff Smith <ggs@ulysses.homer.nj.att.COM>
Subject: Re: rdump, Ethernet slowness
Date: 10 Dec 87 16:25:19 GMT
To: unix-wizards@SEM.BRL.MIL
In article <411@anuck.UUCP>, jrl@anuck.UUCP writes:
> > The network transfer rate is good, but the latency is poor.
>
> How good is this? I know that the network bandwidth is 10Mb,
> but when I transfer a 1 MB file, instead of the 10 seconds that
> the true bandwidth suggests I might get on an unloaded net,
> I find that it takes a minute or more.
10 Mbit/sec == 1.2 Mbyte/sec. True, I never see speeds anywhere near
that. I do see 110 Kbyte/sec when I use a CCI POWER 6/32 running
4.3BSD to dump to a DEC VAX 8650, also running 4.3BSD. I think this
comes to 9 seconds/Mbyte. I just tried a file copy between those two
processor and got 10 seconds/Mbyte, which is just what you wanted.
> Is this software delay,
Probably; protocol delay, and sometimes processor overload. TCP/IP
can chew up a lot of a processor. Our CCI machine has speeded up
by a factor of 6 since we first started using 4.3BSD on our VAXen.
The first factor of 2 was a windowing strategy mismatch between
4.3BSD and the version of 4.2BSD that was running on the CCI processor.
A further factor of 3 resulted when we upgraded to a 4.3BSD+ beta
distribution from Berkeley.
> maybe someone will make [a controller] that can really feed the
> net, which would change my mind about being somewhat put off of
> ethernet because it fails to deliver on the single-user throughput.
>
> John R. Lupien
> ihnp4!mvuxa!anuxh!jrl
You don't say what flavor of UNIX you are using. Protocol implementations
can have a lot of effect on the speed.
--
Griff Smith AT&T (Bell Laboratories), Murray Hill
Phone: 1-201-582-7736
UUCP: {allegra|ihnp4}!ulysses!ggs
Internet: ggs@ulysses.uucp
-----------------------------
From: Richard Harter <g-rh@cca.CCA.COM>
Subject: Re: How much hair? (was "Command interfaces")
Date: 10 Dec 87 23:45:55 GMT
To: unix-wizards@brl-sem.arpa
In article <2805@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes:
>In article <22244@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
>
> 'seems to desired only rarely' is a red flag. Within a particular language
> one very tends to do that which can be done easily within the language.
> For example, FORTRAN has no natural mechanism for recursion. One can do
> recursion in FORTRAN, albeit painfully. Is it any surprise that FORTRAN
> programmers rarely find a need for recursion? The same holds true of
> command languages as well -- if a particular approach cannot be
> implemented readily in a command language, then it won't be used.
>
>It seems that you've never tried writing a quicksort or any tree traversal
>methods in FORTRAN. I've done both, and can attest to the inaccuracy of
>your statement:
>
> Is it any surprise that FORTRAN programmers rarely find a need for
> recursion?
>
As a side note, it happens that I have implemented quicksort and
tree traversal methods in FORTRAN. I have even done things in FORTRAN
that are hard to do. (Simple recursion in FORTRAN is not hard -- it is
merely tedious and prone to error.)
More to the point is that I think you have missed the point of what
I was saying. Let us return to the FORTRAN programmer for a moment. If you
ask a typical FORTRAN programmer if recursion is important, the answer is
very likely to be "no". (I acquit you of being a typical FORTRAN programmer.)
And, for him, he is right -- recursion is an unimportant theorectical novelty
with no real practical use. How can he say this, you ask? Very simple, he
is wearing blinders induced by the language he uses. He doesn't use recursion,
and he doesn't think of using recursion, because it is not part of his natural
lexicon. Recursion becomes something that is done only if there is compelling
need for it. You go on to say:
>You also seem to be confusing goals with methods.
No, what I am saying is that goals are conditioned by methods. More
particularly, subgoals are conditioned by methods. If a particular methodology
is difficult in a particular language, then one does not use it as a regular
thing. If X is not easy to do, then one doesn't try to do X. If you never
do X, then X can't be very important to do. Note that I am not saying that
this line of reasoning is correct -- merely that this is the natural tendency.
A statement that X can be done easily in Primos (clearly false,
nothing can be done easily in Primos) and not easily in sh, but that it
doesn't matter because X hardly ever needs to be done, is suspect if it
comes from someone who only uses sh. The user of sh may never see a need
for doing X, because he doesn't think of doing X. If one wants to evaluate
X as a tool, one should talk to the people for whom it is easy. You may find
that they don't use it much either. You may find that they use it all of the
time but that it is a workaround for something that could be done more
naturally in another language. Or you may find that they use it all of the
time and that it is a useful concept that is missing from your lexicon of
concepts and tools.
--
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Richard Harter, SMDS Inc.
-----------------------------
From: David Elliott <dce@mips.uucp>
Subject: Re: Has tar r ever worked? For anybody?
Date: 10 Dec 87 17:57:51 GMT
Keywords: tar driver streamers
To: unix-wizards@SEM.BRL.MIL
In article <22121@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes:
>In article <1344@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU.ucsc.edu (99700000) writes:
>> Under 4.3BSD, has anybody ever been able to add files to an existing
>> tar tape with tar r? When we try it the tape goes around and it
>> appears to be doing something, but then when we tar t the files are
>> not there.
...
>In answer to your question, yes, "tar r" has been used under
>4.3BSD.
My experience is that it depends on the "tape" device involved and the
driver.
If it is a regular file, it works. If it is a pipe, it can't.
If it is a streaming tape (either QIC or 1/2"), it is generally not
possible, since positioning the tape is costly. In fact, some systems
(Tek 61XX, for example) want you to read and write big chunks (128K) to
avoid burning out the motor, and don't supply tape record backspace.
In any event, if the driver doesn't support record backspace or
backward seeks, you can't do the 'r'.
You need to understand that a tar tape (see tar(5)) ends with two zero
blocks followed by random data. In order to do the replace, tar has to
go to the end of the tape, backspace a record, rebuild the last record
with the new data in place, and then continue as though it was the
original 'tar' running.
Sadly, no tape format for Unix has been completely successful at
dealing with everything. Tar doesn't handle long file names or multiple
volumes. Cpio doesn't handle volumes out of order and can't be ported
easily to systems with long inode or device numbers. Dump is for
filesystems. Nobody deals with adding to the end of a tape by simple
concatenation.
I think that whoever comes up with something to handle all of these
problems and can get people to use it will deserve a lot of gratitude.
--
David Elliott dce@mips.com or {ames,decwrl,prls}!mips!dce
-----------------------------
From: Bert Still <still@usceast.uucp>
Subject: BSD 4.x available on a 3B5 ???
Date: 10 Dec 87 21:38:40 GMT
Keywords: Berkeley Un*x kernel for AT&T 3B5
To: unix-wizards@brl-sem.arpa
I have a curious question. Has anyone ever (successfully) built a
Berkeley BSD4.[23] kernel on an AT&T 3B5? Last I heard, Mt. Xinu hadn't done
it.
Bert
--------------------------------------------------------------------------------
UUCP: ...seismo!ncr-sd!ncrcae!usceast!still
CSNET: still@cs.scarolina.edu
BITNET: T410119@UNIVSCVM (truncates things at column 80)
Bert Still, Dept of Math, University of South Carolina, Columbia, SC 29208
--------------------------------------------------------------------------------
-----------------------------
From: "Dick St.Peters" <stpeters@dawn.steinmetz>
Subject: BSD at AT&T (was Re: ACCESS TO SHARED TAPEDRIVES)
Date: 10 Dec 87 23:12:41 GMT
Sender: root@steinmetz.steinmetz.uucp
To: unix-wizards@SEM.BRL.MIL
In article <3259@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes:
>In article <3053@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>> That an AT&T employee would rather use a foreign, unsupported
>>product than his own company's native, supported, official "one true Unix"
>> ...
>I disagree with the implication. Both System V and BSD Unix have their
>pros and cons. Depending on what you're doing, in some cases you'll be
>better off with System V and in other cases you'll prefer BSD (for instance,
>research vs development). I see nothing wrong with that. It just says
>that neither is perfect.
The issue, as I see it, is not which system is better but that AT&T
has tried its best to impose on everyone else a "one true UNIX" that
it doesn't feel constrained to impose on itself.
Maybe if Mr. Krell had to use his own company's product, he just might
find a way to convince AT&T to improve it enough so everybody *wanted*
to use it.
--
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpeters@ge-crd.arpa
uunet!steinmetz!stpeters
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.COM>
Subject: Re: Is process <n> alive?
Date: 10 Dec 87 22:02:15 GMT
Sender: nobody@tekecs.TEK.COM
To: unix-wizards@SEM.BRL.MIL
"On this SysV, this can be done (with some difficulty) by doing
a kill(0,n), which doesn't actually do anything to the process
(as far as I can tell), but it does return different values in
errno for no-such-process and for wrong-uid ... So far, I
haven't tried to solve the problem on BSD, but the above remark
implies that my SysV code won't work."
Your code will work. BSD kill(2) guarantees that validity checking
happens in this order: first that the signal number is valid (and 0
is); next that the target process exists; next that you're allowed to
send the signal; next (other irrelevancies). Thus, kill(pid,0) will
always return errno==ESRCH if pid doesn't exist.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: David Herron -- Resident E-mail Hack <david@e.ms.uky.edu>
Subject: Re: spell
Date: 11 Dec 87 02:54:00 GMT
To: unix-wizards@SEM.BRL.MIL
In article <501@srs.UUCP> dan@srs.UUCP (Dan Kegel) writes:
>> I recently ran spell on a short letter. Of the three mistakes in the
>> letter, it missed two, an atypically bad record.
>> The first was "lager" for "larger". Clearly "lager" is a perfetly [sic] good
>> word if you are a beer drinker [but it shouldn't be in MY dictionary] ...
>Here's a modest proposal:
>What if spelling checkers didn't just check the spelling of the word, but
>also whether it was likely in the given context?
>IBM's speech recognizer does exactly this sort of processing, so don't say
>it's impossible.
er.. I thought it was "lagar" ... I guess that just shows what's more
important to me when I'm drinking :-)
Anyway ... not to knock IBM's speech recognizer (it's a very interesting
gadget ... and very surprising to see coming from IBM). There are a
couple of practical reasons for not using that algorithm, at least for
right now.
They have this huge database (er.. knowledge base) of (mainly) information
about what phonemes are likely to follow other phonemes. There is very
little information in the database for higher level morpheme information.
Doing that correctly is tantamount to understanding the full meaning of
the text being spell-checked.
Since IBM's KB is largely phoneme oriented and english spelling has little
to do with pronunciation, it's not very applicable to a spelling checker.
(Yes, I know something about the soundex algorithm, but not much)
The speech recognizer does run inside a standard PC/AT ... but that's
with special hardware of some sort added in (if I remember correctly,
some sort of hi-speed parallel cpu). In other words, your proposed
spelling checker will not only require a large database, but also
a lot of cpu.
The KB is weighted towards internal IBM business memo's, as that was
the source for the text which they used for creating the KB. In other
words ... getting a general purpose KB won't be easy.
Most of those problems are workable -- in principle I agree that you
could have a higher-level form of their algorithm -- i.e. have a KB which
is morpheme oriented and gives likelyhoods of certain morphemes following
other morphemes in the same manner that IBM is using now with their
speech recognizer.
Oh, and remember that language is a changing thing -- 50 years from now
the KB will need to be refreshed...
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<----
<---- Winter health warning: Remember, don't eat the yellow snow!
-----------------------------
From: Bill Mitchell <whm@arizona.EDU>
Subject: Re: Kernel Timings with MicrovaxII
Date: 11 Dec 87 02:47:14 GMT
To: unix-wizards@brl-sem.arpa
In article <10646@brl-adm.ARPA>, mankin@gateway.mitre.ORG (Allison J. Mankin) writes:
>
> Hi, folks,
>
> I am working on IP-level performance in 4.3 BSD on a
> MicrovaxII. The CPU is a 630-Q-A, since we bought the system
> over 2 years ago. The operating system is pure Berkeley 4.3.
>
> My question is about the real-time clock resolution. The
> hardware manual does not cover the 630, but analogy to the 750
> (and a good letter to this list by Chris Torek back in August)
> got me hoping it would be possible to read times at a resolution
> of microseconds from the 630's Interval Count Register.
> I didn't see anything to contradict this in the 4.3 source code.
> Alas, experiment and our DEC representative have at last revealed
> that I will never read times of less than 10 milliseconds from this ICR.
The VAX Architecture Reference Manual, a hardbound book published by DEC,
talks about this. The MicroVAX II is a subset VAX implementation and for
a subset VAX implementation, the NICR and ICR may be omitted and the ICCS
needs only a working IE bit. When IE is set, an interrupt at IPL 22 is
generated every 10ms. It goes on to say that the ICR and NICR on the MVII
read as zero and ignore writes (do you get non-zero values from your MVII
ICR?).
> Now, in the latest Proceedings of the ACM Symposium on Operating
> Systems Principles (SOSP-11), there are at least two articles where
> a MicrovaxII was used to do performance timings. Jeff Mogul et al
> includes figures like 1.77 milliseconds for the kernel to process a
> received IP packet. Liskov et al give times such as that required for
> a minimal system call (200 microseconds). (By the way, their articles
> are very juicy and interesting). Do you get such timings only by doing
> thousands of identical operations and measuring the aggregate time?
I'd definitely be interested in hearing about how they got the accurate timings
on a MVII. It might be the KWV11-C that you mention, but I wonder if there
might be something even simpler available somewhere. All that you really
need is a board that has a high-resolution real-time clock that can be read
in response to a system call -- there must be some 3rd party boards around
that can do that.
I tried to get some KWV11-C documentation out of DEC, but they say that all
that is available is a schematic (for $95). If there's a driver, I'd like
to know about it.
All the VAX-11 models supposedly have a full-precision (1usec resolution) clock
so if you're desperate, maybe you could pick up a 725, 730, or 750 at a bargain
price.
Bill Mitchell
whm@arizona.edu
{allegra,cmcl2,ihnp4,noao}!arizona!whm
-----------------------------
From: Richard Stevens <stevens@hsi.uucp>
Subject: Re: Looking for DMF-32 sync port IP driver for 4.3BSD
Date: 10 Dec 87 16:01:08 GMT
To: unix-wizards@brl-sem.arpa
In article <3061@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes:
>
> I'm looking for an IP driver for the synchronous port of a DEC
> DMF-32 to be used on a 4.3BSD (actually MtXinu 4.3/NFS) vax. The standard
> 4.3 driver doesn't support use of the sync port; is there some reason why,
> other than that nobody bothered to write it because they had better
> alternative interfaces to use? Is there some horrible secret about DMF's
> which make them lousy network devices?
We have a driver for the synchronous port of the DMF-32 (we added the support
to the 4.3 driver that Keith Muller at UCSD distributes, since the distributed
4.3 driver doesn't handle Emulex boards correctly). We started with
a 4.2 BSD driver from the Univ. of Guelph that supported the synchronous
port using the IBM Bisynch protocol for RSCS emulation. Our driver is
used with a proprietary software product that we purchased for SNA
LU6.2/PU 2.1 communications. We can give the driver mods to handle the
synchronous port to anyone, but we aren't able to distribute the actual
SNA data link protocol routines that is now part of our driver. The line
counts are:
(1) original 4.3 DMF driver from UCSD 1,035 lines
(2) our "generic" mods to handle synchronous port 1,230 lines
(3) SNA data link code (functions called by driver) 1,794 lines
I can distribute (2) but not (3). As you can see, depending on the
protocol that you're supporting with the synchronous port, there could
still be a lot of work to do, although I'd guess that SNA PU2.1
support could be close to worst case ?? I'd also guess that the reason
standard 4.3 doesn't support the synchronous port is that item (2) is of
little use without some version of item (3) and there are so many different
uses of the sync. port (SDLC for SNA, HDLC for X.25, GenByte for Bisync,
GenByte for DECnet's DDCMP, etc.).
Richard Stevens
Health Systems International, New Haven, CT
{ uunet | ihnp4 } ! hsi ! stevens
-----------------------------
From: Esmond Pitt <ejp@ausmelb.oz.AU>
Subject: Re: Re: Request for human interface design anecdotes
Date: 9 Dec 87 04:19:00 GMT
To: unix-wizards@brl-sem.arpa
In article <10659@brl-adm.ARPA> niuvax!sys1@anl-mcs.arpa (Systems Programmer) writes:
< In an article in UNIX-WIZARDS-DIGEST (V4#088) paul@umix.cc.umich.EDU
<writes:
< > One rm-ed an entire directory of source ...
< > Well, we hadn't done backups in about two months.
< > So, I fired him.
<
<I submit that in that case perhaps the wrong person was fired. Perhaps the
<manager of a system that is not backed up in two months or more has already
<demonstrated a considerably more significant level of incompetence and danger
<to his installation than someone who makes a typing error.
Hear hear. Once upon a time a manager fired a payroll programmer for updating
only one of the two occurrences of the tax rate in a program.
He should have fired himself, for not manifesting the constant or putting
it outside in a file, when he wrote the program some years before.
Managers have occupational hazards too.
--
Esmond Pitt, Austec International Ltd
...!seismo!munnari!ausmelb!ejp,ejp@ausmelb.oz.au
-----------------------------
From: Steve Balogh <root@cit5.oz>
Subject: Re: globbing in the shell (Was Re: more rm insanity)
Date: 9 Dec 87 08:35:45 GMT
To: unix-wizards@brl-sem.arpa
I have overcome the problem of accidently deleting a whole directory of files
(after accidently doing it to my home directory ONCE only) by doing the
following....
1. I have set up a bin directory under my home directory which contains
commands and programs which I use on a regular basis.
2. I have changed my PATH to include $HOME/bin as the FIRST entry (or
at least BEFORE /bin ).
3. I have included a set of programs which simulates a trashcan by making
a directory called $HOME/.TRASH and creating the following scripts:
rm will do a mv from current directory to $HOME/.TRASH
rummage will do an ls of $HOME/.TRASH
scavange will retrieve an accidently rm'ed file
empty will REALLY remove all files from $HOME/.TRASH
4. I automatically perform an "empty" command when logging out. (it
could be said that this is dangerous, but it is a risk that I am
willing to take so as to not make the .TRASH directory too big) It
could be done manually on a regular basis.
This system has saved many files which would have been accidently deleted and
sometimes also serves as a place to put temporary files. (although this is not
really recommended) I believe that the mv command only changes file pointers
and does not actually copy a file, so even large files can be removed quickly
with this method.
I am sure that there are better and more exotic ways of solving the "rm *"
problem but I find that the above works well for me.
Steve.
- - - - -
(It's my opinion and not my employers)
Steve Balogh VK3YMY | steve@cit5.cit.oz (...oz.au)
Chisholm Institute of Technology | steve%cit5.cit.oz@uunet.uu.net
PO Box 197, Caulfield East |
Melbourne, AUSTRALIA. 3145 | {hplabs,mcvax,uunet,ukc}!munnari\
+61 3 573 2266 (Ans Machine) | !cit5.cit.oz!steve
-----------------------------
From: Lawrence Keith Blische <lkb@theceg.uucp>
Subject: ditroff device description trouble
Date: 10 Dec 87 19:58:46 GMT
Keywords: ditroff typesetting DESC
To: unix-wizards@brl-sem.arpa
What I am trying to do is generate a new device description for ditroff.
This is for System V/AT. I've read font(5) nad troff(5). The system did
not come equiped with the `makedev' program as mentioned in font(5); so I
wrote a simple minded one. I've setup a DESC file and font description
files for each font (R I B IB PE C CW) and have painstakenly inspected the
hex dumps of the *.out files produced by my makedev and those supplied
for other devices (i10, aps and X97.tim10p). To further test my makedev
(and my understanding of this) I wrote the inverse program, `unmakedev'
and have used it to produce the ASCII input for the i10, aps, etc. supplied
files.
I know (I believe, actually) troff is able to read and interpert my *.out files
because the font widths that it generates look good but... my problem
is shown below. The following input file, `test', causes ditroff to go looking
for a font called `2' instead of for the 2nd font (which I think should be `I').
test: .ft 2
Italic
#troff -TP351 test >foo
troff: Can't open /usr/lib/font/devP351/2.out
Can anyone offer advice as to what I must do to convince ditroff
that .ft 2 is a reference to the 2nd mounted font, not a font named 2?
I do not have source so I can't look this up myself. Wish I could...
Thanks in advance,
Larry
--
--------------------------------------------------------------
Larry Blische
UUCP:uunet!theceg!lkb
+1 301 282 5876 (9-5 ET)
-----------------------------
From: John Bossert <bossert@entropy.ms.washington.EDU>
Subject: UDA-50 error messages
Date: 11 Dec 87 03:36:07 GMT
To: unix-wizards@SEM.BRL.MIL
I've been seeing the following occasionally:
uda0: hard error, disk transfer, unit 1
grp 0x0, hdr 0x540
uda0: hard error, SDI error, unit 1
event 0353 hdr 0x0
uda0: hard error, disk transfer, unit 1
grp 0x0, hdr 0x2d0
uda0: hard error, SDI error, unit 1
event 0353 hdr 0x0
From looking at the code for uda.c, I see that they're MSCP
error log packets. Unfortunately, I can't find info on the
particulars. Doctors, the prognosis?
VAX 750, 4.2bsd, UDA50, RA81's. Thanks.
--
In-Real-Life: John Bossert, Thalatta Corporation, (+1 206 643 7187)
Domain: bossert@Thalatta.COM Path: uw-beaver!uw-entropy!thebes!bossert
-----------------------------
From: stuart@cs.rochester.EDU
Subject: Wait, Select, and a SIGCHLD Race Condition
Date: 11 Dec 87 05:43:40 GMT
Sender: daemon@cs.rochester.EDU
To: unix-wizards@SEM.BRL.MIL
I need advice (or sympathy) for handling a race condition in 4.3BSD
flavored UNIX. Briefly, I want to use wait3 to reap all the dead or
stopped children of a process, then use select to wait for the first
new IO or child activity. Sketch something like this:
while (0 < (pid = wait3(..., WNOHANG, ...))) {
/* do something with child */
}
/* XXX Race condition is here */
numfds = select(...);
if (numfds < 0) {
if (errno == EINTR)
/* caught a signal, what kind was it, etc */
}
There is a race condition between reaping children and starting the
select. It is possible that a child can change status, a SIGCHLD gets
delivered *before* I enter select, I don't notice it, enter select and
hang forever. Even if I have a handler for SIGCHLD that sets a flag
and I check that flag immediately before calling select, there is still
a (small) window of vulnerability.
Ideally, I would like to set the signal mask to block SIGCHLD and have
select release the signal *after* starting to wait. That would allow
me to ensure that *all* dead children are noticed. However, select
does not release any signals as far as I can tell. Berkeley truly
improved the signal handling features going to 4.3, but the (improved)
features don't seem to let me write this code safely. (In particular,
the sigblock, signal, sigpause, signal, setsigmask idiom is of no help
here.)
I would appreciate advice on how to safely avoid this race condition
given 4.3BSD features. I suspect that it's not possible, but would be
delighted to learn otherwise (see next paragraph for an equivocation
for "not possible"). It's not essential that the skeleton code look
like that given above; all that's needed is that I/O and child
activity is processed as soon as *either* is available. Neither kind
of activity is guaranteed to happen, and some events may already have
happened, which must not be ignored.
There *is* a kludge that I can fall back on, but I would really like to
avoid it: Put a maximum on the timeout given to select and check for
more children when select times out. Even if I miss a SIGCHLD, I would
still reap the child. This is doable, but a pain, because I am
managing timer requests in addition to IO and child requests in the
same package; keeping the real timeouts straight from the kluge
timeouts (which might coincide!) is real ugly. The whole point of this
package is to multiplex lots of request and AVOID POLLING. The kludge
is, of course, nothing but polling.
Stu Friedberg {ames,cmcl2,rutgers}!rochester!stuart stuart@cs.rochester.edu
-----------------------------
From: Rob Robertson <rob@philabs.Philips.COM>
Subject: System Industries Disk Cache Processor and 4.3 vaxen
Date: 10 Dec 87 20:33:23 GMT
To: unix-wizards@SEM.BRL.MIL
We have a pair of Systems Industries Disk Cache Processors (DCPs) on
evaluation. They are hooked to our vaxen (an 8600 and a 785) running
4.3bsd. Since we've had them installed, we really haven't noticed any
real performance gains. However I really have no idea on how to tweak
the kernel to use them better....
Is there anyone out there using the DCP on a unix vax?
Question 1
Do they help at all?
Question 2
If they do help how can I configure them to maximize
the performance increase.
Just knowing someone else out there is using them under BSD would
hearten me.
rob
--
william robertson
rob@philabs.philips.com
-----------------------------
From: Russell Lawrence <russ@wpg.uucp>
Subject: curses/terminfo
Date: 11 Dec 87 03:12:14 GMT
Keywords: HELP!
To: unix-wizards@SEM.BRL.MIL
To finish a project that I've been working on for some time, I will need to
write a low level (non-curses), terminally independent function for positioning
the cursor. I assume that this can be achieved using the terminfo routines.
However, I've read the 'curses and terminfo' sections of my manual about a
hundred times and have decided that I'm not anywhere close to deciphering the
language used.
Does someone out there in netland have any examples handy that would show a
neophyte how to use the basic functions in terminfo, especially tparm(),
tputs(), putp().
Thanks.
--
Russell Lawrence (WP Group POB 306, Metairie, LA 70004)
AT&T: +1 504 456 0001
UUCP: !{philabs,hpda,nbires,amdahl,...}!uunet!wpg!russ
COMPUSERVE: 72337,3261
-----------------------------
From: Steven Grimm <koreth@ssyx.ucsc.EDU>
Subject: Pagedaemon
Date: 10 Dec 87 23:44:51 GMT
Sender: usenet@saturn.ucsc.EDU
Keywords: swapping
To: unix-wizards@SEM.BRL.MIL
This is probably a very simple question, but our resident UNIX guru couldn't
come up with an answer. It has to do with the "pagedaemon" process. I was
doing a ps -aux one day and noticed that although our pagedaemon's total
process size is 512K, none of it is resident in main memory. Am I mistaken
in assuming that the page daemon is what handles page swapping? If so, how
on Earth does it ever get swapped in from disk to swap things in from disk?
That seems like an awfully strange setup to me. Any answers would be
greatly appreciated.
+New! Improved! Now 100% Artificial-+-+-----------------------------------+
|# # @@@ **** &&&&& $$$$$ % %| |Steven Grimm |
|# # @ @ * * & $ % %+-+ ARPA: koreth@ucscb.ucsc.edu |
|### @ @ **** &&&& $ %%%%%| | UUCP: ...!ucbvax!ucscc!ssyx!koreth|
|# # @ @ * * & $ % %+-+ ______________________________|
|# # @@@ * ** &&&&& $ % %| | |"Let's see what's out there."|
+-----with NutraSour(TM)! No natural colors or preservatives!------------+
-----------------------------
From: Lenny Tropiano <lenny@quincy.uucp>
Subject: getlogin(3C) returns bogus name
Date: 9 Dec 87 14:57:04 GMT
Keywords: getlogin, username, login
To: unix-wizards@SEM.BRL.MIL
On my UNIX PC I have noticed a problem occasionally with the
getlogin(3C) system call. At certain times I have noticed
getlogin returning "LOGIN" or "rc" instead of the user's name
who is logged in.
I know what "LOGIN" and "rc" are, but why are they showing up
for a valid logged-in user? This is quite strange...
--- piece of code ---
char *getlogin();
printf("User is: %s\n", getlogin());
--- end piece of code ---
Any suggestions? I have recreated the /etc/utmp, /etc/wtmp and
this hasn't cleared up the problem. Sometimes it goes away
and other times it comes back.
Thanks,
Lenny
--
Lenny Tropiano UUCP: ...uunet!godfre!quincy!lenny -or-
American LP Systems, Inc. ...cmcl2!phri!bc-cis!icus!quincy!lenny -or-
1777-18 Veterans Memorial Hwy. ...mtune!quincy!lenny -or
Islandia, New York 11722 +1 516-582-5525 ...ihnp4!icus!quincy!lenny
-----------------------------
From: Bruce <bak@csd_v.uucp>
Subject: Re: Is process <n> alive?
Date: 11 Dec 87 01:50:26 GMT
To: unix-wizards@SEM.BRL.MIL
In article <429@minya.UUCP>, jc@minya.UUCP (John Chambers) writes:
> Is there a universal way that will work on any Unix to write a function
> isprocess(n)
> which returns TRUE if process n is alive, and FALSE if it isn't alive?
>
> Note that I have said nothing about the relationship of process n (if it
> exists) to the process that is asking. They might or might not be related.
> They might or might not have the same uid and gid. I don't want to kill
> the process (or even upset it in any way). I just want to know if it is
> alive.
>
This solution is a little awkward but will definitely work.
Open a read-only pipe to the "ps -ef" command ( "-al" on BSD I believe, anyway
there are your #ifdefs ) and read the output searching the PID field for the
process of interest to you.
I have a routine (from Kernighan and Pike) called zap which matches any string
in the line and then does a kill -9 to the pid, thereby allowing me to kill
processes mneumonically rather than PID. Thus
$ tail -f abc &
9803
.
.
many screenfulls of junk later
.
$ zap abc
bak 1632 1354 0 19:51:13 cons2 0:58 tail -f ggg ? n
bak 1648 1354 0 19:51:13 cons2 0:58 tail -f abc ? y
$
ksh: 1648 Killed
The same idea is applicable to just looking at the PID field for your case.
Of course ps is not the quickest command to execute and if there are a lot
of processes running quite a bit of winnowing has to be done. But if no
better solutions come along, this will do the job and is highly portable.
One other thing it will absolutely be transparent ot the running process
on all flavors of unix.
--
Bruce Kern | uunet!swlabs!csd_v!bak
Computer Systems Design | 1-203-270-0399
29 High Rock Rd., Sandy Hook, Ct. 06482 | This space for rent.
-----------------------------
From: Bill Gallmeister <gallmeis@wasp.cs.unc.EDU>
Subject: Re: a solution to the RM insanity
Date: 11 Dec 87 03:33:00 GMT
Sender: news@thorin.cs.unc.EDU
To: unix-wizards@SEM.BRL.MIL
Back where I come from, we have a saying. My colleagues there,
who taught me most things I know, use this saying to great advantage
with those who remove all their files by mistake, or wait for an hour
for "cat" with no arguments to come back. The saying is,
"A power tool is not a toy."
UNIX is a power tool. Also a trade mark of Bell Labs.
- bill o
Bill O. Gallmeister unc!gallmeis
"A power tool is not a toy."
-----------------------------
From: Jim Sewell <jim@coplex.uucp>
Subject: C version of ps: From whence doeth the info cometh?
Date: 11 Dec 87 07:56:28 GMT
Keywords: ps C
To: unix-wizards@SEM.BRL.MIL
I would like to write a program allowing a system administrator to watch what
his people are doing on his machine in real time. It would be a full screen,
self updating ps of sorts, with updates being made when either:
1. A new process pops up
or 2. A process changes what it is doing
My question is "Where does UN*X store the information ps makes available, and
how do I access it?" I am working with System V Plexus and IBM AT (Microport)
machines.
Any help is appreciated. | Jim Sewell ..!mit-eddie!bloom-beacon!coplex!jim
"Make knowledge free!" |
-----------------------------
From: Arthur David Olson <ado@elsie.uucp>
Subject: Re: Is process <n> alive?
Date: 11 Dec 87 14:52:25 GMT
To: unix-wizards@SEM.BRL.MIL
# Is there a universal way that will work on any Unix to write a function
# isprocess(n)
# which returns TRUE if process n is alive, and FALSE if it isn't alive?
echo Here's source for a command we've found useful here at elsie.
: To unbundle, sh this file
echo 'adopt.1' 1>&2
cat >'adopt.1' <<'End of adopt.1'
.LC @(#)adopt.1 1.1
.TH ADOPT 1E \*(eH
.SH NAME
adopt \- wait for process
.SH SYNOPSIS
.B adopt
[
.B \-v
] [ processid ... ]
.= adopt
.SH DESCRIPTION
.I Adopt
waits for completion of the process(es) identified by the ID number(s)
given on the command line.
It differs from
.IR wait (1),
which can only be used to wait for completion of a shell's own child processes.
.PP
This option is available:
.TP
.B \-v
Warn about processes that are not running when
.I adopt
begins execution.
End of adopt.1
echo 'adopt.c' 1>&2
cat >'adopt.c' <<'End of adopt.c'
#
#include "stdio.h"
#if !defined lint && !defined NOID
static char sccsid[] = "@(#)adopt.c 1.2";
#endif /* !defined lint && !defined NOID */
#include "errno.h"
#include "ctype.h"
#ifndef SLEEPTIME
#define SLEEPTIME 5
#endif /* !SLEEPTIME */
extern int errno;
extern int optind;
static
exists(s)
char * s;
{
char * cp;
int pid;
if (s == NULL || *s == '\0')
return -1;
for (cp = s; *cp != '\0'; ++cp)
if (!isascii(*cp) || !isdigit(*cp))
return -1;
if (sscanf(s, "%d", &pid) != 1 || pid < 0)
return -1;
return kill(pid, 0) == 0 || errno != ESRCH;
}
main(argc, argv)
int argc;
char * argv[];
{
int vflag;
int i;
int c;
int result;
int ok;
vflag = 0;
while ((c = getopt(argc, argv, "v")) == 'v')
vflag = 1;
if (c != EOF ||
optind == (argc - 1) && strcmp(argv[optind], "=") == 0) {
(void) fprintf(stderr,
"%s: usage is %s [-v] processid ...\n",
argv[0], argv[0]);
return 1;
}
/*
** Initial checks.
*/
ok = 1;
for (i = optind; c != EOF || i < argc; ++i) {
result = exists(argv[i]);
if (result < 0) {
(void) fprintf(stderr, "%s: wild argument '%s'\n",
argv[0], argv[i]);
return 1;
}
if (vflag && result != 1) {
(void) fprintf(stderr,
"%s: process %s does not exist\n",
argv[0], argv[i]);
ok = 0;
}
}
/*
** Wait loop.
*/
for (i = optind; i < argc; ++i)
while (exists(argv[i]) == 1)
(void) sleep(SLEEPTIME);
return ok ? 0 : 1;
}
End of adopt.c
exit
--
ado@vax2.nlm.nih.gov ADO, VAX, and NIH are Ampex and DEC trademarks
-----------------------------
From: aglew@ccvaxa.uucp
Subject: Re: rdump, Ethernet slowness
Date: 11 Dec 87 05:17:00 GMT
Nf-ID: #R:hsi.UUCP:788:ccvaxa:57900004:000:1364
Nf-From: ccvaxa.UUCP!aglew Dec 10 23:17:00 1987
To: unix-wizards@brl-sem.arpa
..> Speed of dump vs. rdump
You're all talking around the problem of synchronous I/O,
if your network has sufficient thruput but excessive
latency to use synchronously.
In 4.3 dump has been changed to use multiple processes
and acheive a facsimile of asynchronous I/O, but I doubt
that rdump has. What we really need are asynchronous
I/O facilities in UNIX, so that the person who wants to
do things at the maximum thruput rate can do so without
having to mess with multiple processes. HP's contention that
asynch I/O isn't needed because it can be acheived with
multiple processes and shared memory doesn't hold water
(especially if you're me, and do a lot of I/O intensive
work, and are always pressing against your process limits).
Asynchronous I/O primitives should basically look like this:
IOtransT aread(fd,buf,n) - initiate a read
IOtransT awrite(fd,buf,n) - initiate a write
iowait(n,iolist) - wait for ios to complete
With operations to guarantee sequentiality, or sometimes not.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.
-----------------------------
From: Tim Knox <timk@omepd>
Subject: Wanted: Unix callback software
Date: 10 Dec 87 19:30:02 GMT
To: unix-wizards@SEM.BRL.MIL
I am looking for software that implements callback under 4.3BSD.
This would allow a user to call in over phone lines and log a request
to be called back. Then when a dialout modem is free, the user
would be called (at a number stored in a database for that user)
and given a login prompt.
Tim Knox (...!{verdix,uoregon,ogcvax}!omepd!timk)
-----------------------------
From: David_T_Lawlor@cup.portal.COM
Subject: Unix on an apollo
Date: 11 Dec 87 06:30:19 GMT
XPortal-User-Id: 1.1001.3033
To: unix-wizards@SEM.BRL.MIL
Is it possible to debug a program on an apollo?
I know you can debug apollo compiler products very well but
I'm using Professional Pascal from Metaware and can't find a way
to debug on the apollo.
The aegis command DEBUG works for apollo pascal. I've heard there is an
undocumented command which allows you to go into assembly mode but don't
know what it is or how to use it.
Thanks in advance....
davel@cup.portal.com
-----------------------------
From: David Geary <dmg@ssc-vax.uucp>
Subject: How to set priority of a running task
Date: 10 Dec 87 19:06:42 GMT
Keywords: task, priority (What are these keywords for anyway?)
To: unix-wizards@SEM.BRL.MIL
Does anyone know how to reset a task's priority while it is running?
I know that I can set a task's priority when I execute it using
nice, but I want to set it while it is running. I've heard of
renice, but we don't have it. Any other way??
Thanx,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ "...You may be right, ~
~ I may be crazy, ~
~ but it just may be a lunatic ~
~ you're looking for..." ~
~ ~
~ "You May Be Right", Billy Joel ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
***********************************************************
* David Geary, Boeing Aerospace Co., Seattle, WA *
* (206)773-5249. --I disclaim everything I've ever said--*
***********************************************************
-----------------------------
From: Wen-King Su <wen-king@vlsi.caltech.edu>
Subject: Re: Wait, Select, and a SIGCHLD Race Condition
Date: 11 Dec 87 18:58:57 GMT
Sender: news@csvax.caltech.edu
To: unix-wizards@SEM.BRL.MIL
In article <5105@sol.ARPA> stuart@cs.rochester.edu writes:
>I need advice (or sympathy) for handling a race condition in 4.3BSD
<flavored UNIX. Briefly, I want to use wait3 to reap all the dead or
>stopped children of a process, then use select to wait for the first
<new IO or child activity. Sketch something like this:
This method uses the timeout in a non-polled way. The ORIGINAL_TIMER
is the timer you are using. The ZERO_TIMER is a structure with zero
in all its fields. Now, instead of passing &ORIGINAL_TIMER to select,
you put its address in a pointer and pass that pointer instead so you
can change the pointer on the fly whenever a child signal is received.
on SIGCHLD interrupt, set time_ptr = &ZERO_TIMER;
do { time_ptr = &ORIGINAL_TIMER;
if (0 > (pid = wait3(..., WNOHANG, ...))) break;
.... }
numfds = select(...,time_ptr);
if(time_ptr == &ZERO_TIMER) { go back to wait for childs }
if (numfds < 0) { if (errno == EINTR) { ... } else { ... } }
/*------------------------------------------------------------------------*\
| Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers |
\*------------------------------------------------------------------------*/
-----------------------------
From: Richard Draves <rpd@F.GP.CS.CMU.EDU>
Subject: Re: Wait, Select, and a SIGCHLD Race Condition
Date: 11 Dec 87 18:00:57 GMT
Sender: netnews@PT.CS.CMU.EDU
To: unix-wizards@brl-sem.arpa
One solution (this idea is from GNU Emacs) is to put a large timeout
on the select. Make a SIGCHLD handler that clears the timeout.
Then if the handler is called before entering select, the select won't
block.
Rich
-----------------------------
From: "Mark E. Sunderlin" <megabyte@chinet.uucp>
Subject: Wanted: Opinions on Unix on Mainframes
Date: 8 Dec 87 18:17:53 GMT
To: unix-wizards@SEM.BRL.MIL
We here at the IRS are very interested in running and using
Unix or a Unix like system on our Unisys (Sperry) 1190 and
Amdahl 5880 mainframe computers.
Does anyone have any advice, stories, comments, or horror stories
about using Unix on these mainframes?
Also, could somone get us in contact with venders who
sell Unix mainframe products? (Are you listening Unisys and
_especially_ Amdahl?)
Thanks a lot for all of you help.
"This is the AK-47 assault rifle, the prefered weapon of your enemy"
The opinions expressed herein are my own and do not reflect those of
the Internal Revenue Service or any other agency of the United States
Government. (A US Gov't disclaimer designed to protect the taxpayers
from their fellow taxpayers)
--
UUCP: (1) ??????????????!scsnet!sunder Mark E. Sunderlin
(2) ihnp4!chinet!megabyte aka Dr. Megabyte
CIS: 74026,3235 (202) 634-2529
Mail: IRS PFR:D:NO 1111 Constitution Ave. NW Washington,DC 20224
-----------------------------
From: Dave Stein <angst%csilvax@hub.ucsb.EDU>
Subject: Re: C version of ps: From whence doeth the info cometh?
Date: 11 Dec 87 21:38:54 GMT
Sender: news@hub.ucsb.EDU
To: unix-wizards@brl-sem.arpa
In article <150@coplex.UUCP>, jim@coplex.UUCP (Jim Sewell) writes...
>I would like to write a program allowing a system administrator to watch what
>his people are doing on his machine in real time. It would be a full screen,
>self updating ps of sorts, with updates being made when either:
> 1. A new process pops up
>or 2. A process changes what it is doing
>My question is "Where does UN*X store the information ps makes available, and
>how do I access it?" I am working with System V Plexus and IBM AT (Microport)
I don't think it's available on Sys V, but there is a program called "top"
which is similar to what you want. I've used it on Sun 3.X, and on some
Berkeley machines. If you could get source for it, it would be very helpful.
As for where ps gets its information, it reads /dev/kmem (kernel memory),
/dev/mem (physical memory), and /dev/swap (swap device). I used to work
at a place where my job was porting kernel utilities like ps, vmstat, and
top, and I've rewritten ps more than once. If you are no familiar with it,
I would *greatly* suggest you get a copy of the source and study it closely.
It is not trivial. You need to be familiar with the process table (the
large array of processes that the kernel keeps), and u-areas (per-process
information) and the like.
Good luck! Feel free to respond via email if you have more questions.
Dave Stein "Life's a clambake."
ARPA: angst%csilvax@hub.ucsb.edu Disclaimer: college students don't
UUCP: ...ucbvax!hub!csilvax!angst need no disclaimers!
-----------------------------
From: Dave Stein <angst%csilvax@hub.ucsb.EDU>
Subject: Re: How to set priority of a running task (LONG)
Date: 11 Dec 87 23:22:13 GMT
Sender: news@hub.ucsb.EDU
To: unix-wizards@SEM.BRL.MIL
In article <1584@ssc-vax.UUCP>, dmg@ssc-vax.UUCP (David Geary) writes...
>Does anyone know how to reset a task's priority while it is running?
>I know that I can set a task's priority when I execute it using
>nice, but I want to set it while it is running. I've heard of
>renice, but we don't have it. Any other way??
You didn't say what flavour of UN*X you're running, but on BSD 4.2/3
and those based on BSD (like Sun 3.X), you can use the setpriority
system call to accomplish this.
Excerpt reprinted without permission...
GETPRIORITY(2) UNIX Programmer's Manual GETPRIORITY(2)
NAME
getpriority, setpriority - get/set program scheduling prior-
ity
SYNOPSIS
#include <sys/resource.h>
...
setpriority(which, who, prio)
int which, who, prio;
DESCRIPTION
...
The setpriority call sets the priorities of all of the
specified processes to the specified value. Only the
super-user may lower priorities.
I don't know if it's available on Sys V. Anyone?
Dave Stein "Life's a clambake."
ARPA: angst%csilvax@hub.ucsb.edu Disclaimer: college students don't
UUCP: ...ucbvax!hub!csilvax!angst need no disclaimers!
-----------------------------
From: Richard Draves <rpd@F.GP.CS.CMU.EDU>
Subject: Re: Wait, Select, and a SIGCHLD Race Condition
Date: 11 Dec 87 23:48:33 GMT
Sender: netnews@PT.CS.CMU.EDU
To: unix-wizards@brl-sem.arpa
> on SIGCHLD interrupt, set time_ptr = &ZERO_TIMER;
...
> numfds = select(...,time_ptr);
...
>| Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers |
This method doesn't quite work. The problem is if the signal comes in after
the select procedure call but before the trap to the kernel, then the
select will end up blocking because the kernel will get ORIGINAL_TIMER
instead of ZERO_TIMER as the argument to the trap. The signal handler
must atomically zero out the actual timer structure.
Rich
-----------------------------
From: Dave Ihnat <ignatz@chinet.uucp>
Subject: Re: Command interfaces
Date: 10 Dec 87 16:56:48 GMT
To: unix-wizards@brl-sem.arpa
This is a little annoying. First, I doubt the PR1MOS CLI can handle
general wildcards in as flexible a manner as sh or ksh; you can truly
construct some bizarre patterns, if you wish. But the second part of
my annoyance is that you *don't* want an expression that rivals the
sendmail syntax for complexity and illegibility; the example given
does, and I know I could come up with some that are worse for the
shell using wildcards, negation, and alternates. Finally, the keynote
is that this is another religious argument, akin to the question
"My {OS | editor | machine } is better than *, because..."
Nobody is ever going to either definitively answer the argument, nor
are we going to convince somebody that X really *is* better than Y,
and sell their box that runs Y to buy an X box.
If a discussion of what should *be put into* a CLI--what features
should be cross-implemented--should spring up, fine. But "my CLI's
better than your CLI" is boring; I've heard it all before over vi vs.
emacs, BSD vs SysX, etc.
--
Dave Ihnat
ihnp4!homebru!ignatz || ihnp4!chinet!ignatz
(w) (312) 882-4673
-----------------------------
From: Kurt Zeilenga <kurt@hi.uucp>
Subject: quotas for printing under BSD UNIX
Date: 11 Dec 87 23:30:22 GMT
To: unix-wizards@SEM.BRL.MIL
We are in much need of (laser) printing quotas on our instructional
systems (4.3BSD, 4.2BSD clones). Does anybody know of any free (or
very inexpensive) software that I could obtain to do this? I would
like it to be per user per printer. Send mail to me, I'll post a
summary of replies.
-----------------------------
From: "William E. Davidsen Jr" <davidsen@steinmetz.steinmetz.uucp>
Subject: Re: ditroff device description trouble
Date: 11 Dec 87 17:59:02 GMT
Keywords: ditroff typesetting DESC
To: unix-wizards@SEM.BRL.MIL
In article <209@theceg.UUCP> lkb@theceg.UUCP (Lawrence Keith Blische) writes:
| Can anyone offer advice as to what I must do to convince ditroff
| that .ft 2 is a reference to the 2nd mounted font, not a font named 2?
Try using \f2 instead.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: Neil Hunt <hunt@spar.SPAR.SLB.COM>
Subject: Re: more rm insanity - a suggestion.
Date: 11 Dec 87 21:20:05 GMT
To: unix-wizards@SEM.BRL.MIL
In article <> ggs@ulysses.homer.nj.att.com (Griff Smith) writes:
>In article <12726@think.UUCP>, barmar@think.UUCP writes:
>>>In article <> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>>>Have you ever used TOPS-10?
[Globbing not in the shell results in every command being different]
>
>As a veteran of the TOPS-10 SCAN/WILD wars, I agree with the first
>complaint. When command parsing is done in the application program
>there is too much opportunity for "creativity".
>
>DEC did have a library that "simplified" directory scanning ("WILD")
>and command arg parsing ("SCAN"). It required the user to build tables
>of expected arguments, default values, etc. Some people took the
>trouble to learn how to use it, many gave up and did their own quick
>and dirty versions.
VMS comments - don't do it like this !
======================================
If I remember correctly, VMS (VM$ !) has (had ?) a horrible system.
A command could be installed `foreign', in which case you could
call some $y$tem$call with a long$ name$ to obtain the complete command line
with spaces zapped; it was up to you to parse this as you would.
Otherwise you built a file describing the command options allowed
(options had to begin with '/', of course) in some incredibly non obviou$
$yntax, and executed some command which incorporated this into
your command interface. To get a command with real options included
into the interface for everyone required the services of a wheel (superuser).
Only with the latter option could standardised globbing be done.
Even then, the shell didn't make use of any of this extra data in an
interesting way - it simply syntax checked your command. THere was
no completion, or prompting !
There was a library of $y$tem$call$with$long$name$ which allowed one to
access directories, so it was possible to perform some kind of expansion
in a program using the foreign interface, but the speed was absolutely
appaling !
An idea - take the idea behind the VMS approach, but do it right.
=================================================================
Now I run a UNIX shell called cshedit -- a local hack -- where
typing ESC in the middle of a line does filename completion,
and '?' prompts with a list of possible completions of the current
line as typed so far. Some limited intelligence is provided;
if a word is the first word in the line, or after a ';' or '&', the
completion is by files in the current path; otherwise it is over
files in the current directory.
This shell is incredibly useful. Users who have become familiar with
it will not touch any other, not even the newer csh which has completion
on ESC, but automatically gives you a list of possible completions
whenever there is ambiguity. The '?' mechanism is much more useful.
E.g. you want to see what will go when you type 'rm ab*' -- you type
'rm ab?' and the shell gives you a list of all the matches.
If you haven't specified enough, add some more letters, then *, then
CR and away it goes (and so do your files -- as previewed !).
(By the way it also has complete EMACS line editing commands built in...
^B, ^F, ^P move forward and back in the line and command history,
type ^RccESC to search the history for the last cc command;
add ^Rcc -cESC for the last cc -c command, and repeat ^R^R^R to search
back again for previous commands in the history ...)
Arguably, the ESC '?' feature could be extended in a simple way to allow
the command itself (after the command name (verb) has been typed, anyway)
to provide the shell with some guidance on how to expand or interpret
names, along the lines of a usage message.
If there were a standard way to obtain a usage message [e.g. command -Help],
and some better conventions about how to interpret one, then one could
imagine the shell, when first given an ESC or '?', could invoke the program
to obtain its usage message (which could then be cached); for example:
Usage: command [-a %d] [-b %f] [-fast] [-verbose|-silent] file.end file
Now we could have
% commESC # ESC asks for completion.
-------
% command -? # ? asks for options with '-'.
-- # (shell obtains usage message)
[-a %d] [-b %f] [-fast] [-verbose|-silent] # list of pos options.
% command -faESC # completion.
-----
% command -fast f? # options begining 'f'.
--
f123.end f456.end f789.end # list of files matching f
# and also having .end
% command -fast f1ESC
----
% command -fast f123.end f1*3? # ? asks for completions
-----
f123.end f123.results f123.results.old f113.results
% command -fast f123.end f1*3.rESC # complete on .r
_____
% command -fast f123.end f1*3.resultsBEEP # still ambiguous - BEEP warns.
% command -fast f123.end f1*3.results.ESC
----
% command -fast f123.end f1*3.results.old # final command; confirm with CR
========
{{ underlining indicates what the user types, eveything else is provided
-----------
by the shell, except the commentary # commentary
which is to explain this protocol. }}
========
One could see a faster way where the usage message was called by some
standard name inside the program, and the shell could extract the message
from the object without the cost of execing the program just to get hold
of the message:
---------
char *usage_messages[] =
{
"[-a %d] [-b %f] [-fast] [-verbose|-silent] file.end file",
"# explanation (human readable) after command marks",
"[more [options [here | or here]]]",
NULL,
};
main()
{
if(...)
usage(usage_mesages); /* Library func prints "usage: argv[0] ..." */
...
}
---------
Now the shell can open the command object file, read the symbol table,
and extract the strings directly.
Advantages
==========
Such a scheme is backward compatible - if a command has no usage_messages
strings, then the shell will make some assumptions - no worse than now.
New commands with appropriate stuff will work. Users not liking the stuff
can use a standard shell, rather than the modified version.
By the way - this still doesn't stop you typing rm * !
Comments anyone ?
Neil/.
-----------------------------
From: Snoopy <snoopy@doghouse.gwd.tek.COM>
Subject: Re: //host vs "mount point"
Date: 11 Dec 87 18:19:18 GMT
Sender: nobody@tekecs.TEK.COM
To: unix-wizards@SEM.BRL.MIL
In article <9591@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
|In another article whose referent has been deleted, Doug Gwyn gives
|the following example:
|>> grep -i gwyn /n/ucbvax/n/monet/etc/passwd
|>> should work, but I doubt that
|>> grep -i gwyn //ucbvax//monet/etc/passwd
|>> would.
|In article <9446@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew
|Klossner) writes:
|>What you really want (at least in the environment I work in) is
|> grep -i gwyn //monet/etc/passwd
|>All hosts reside in the same flat name space....
|This one is too easy. There are places that, for administrative
|reasons (read `paranoia and/or pinheadedness' :-) ), *require*
|such indirection. (I am not claiming that UCB is one such.)
You will be happy to learn that //host1//host2/etc/passwd does in
fact work under DFS. And you *can* mount remote filesystems if
you really want to. I prefer using symbolic links which:
(a) are more flexible, and (b) don't require the superuser(s) to get
involved. (No, let's not start the symlink argument again!)
Snoopy
tektronix!doghouse.gwd!snoopy
snoopy@doghouse.gwd.tek.com
Pizza. Just say yes!
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.COM>
Subject: Yet more on command interfaces
Date: 11 Dec 87 18:31:18 GMT
Sender: nobody@tekecs.TEK.COM
To: unix-wizards@brl-sem.arpa
[]
"Since the binary images have so much extra information in them
already (symbol table, reloadability when pure, etc), why not
add yet another optional header, say 1024 bytes long, which
defines how arguments are supposed to be handled? Then a
command interpreter such as sh(1) or csh(1) or tcsh(1?) etc.
can just open the file, read 1024 and have some method of
resolving such sillyness."
The shell doesn't normally read a file before executing it; it only
tries to open the file if the exec(2) call fails (meaning it's not a
binary executable, so maybe it's a shell script).
Besides the performance impact (making the shell read every command
file) and the massive hair imposed by changing the a.out structure
(which dozens of utilities "know"), this technique would fail because
of execute-only files, which the shell can't examine.
I haven't yet seen the TENEX approach mentioned: as soon as you hit the
space after the command name, the program runs and it reads the rest of
the command line. Under some circumstances the program may even supply
in-line prompts, a facility made easy by the fact that the tty driver
doesn't echo a character until the application reads it. An
example would be:
rm [file-name] *.o [are you sure?]
^ ^ ^ ^
^ ^ ^ User hit carriage return; system doesn't echo
^ ^ ^ it, but asks for confirmation instead.
^ ^ User enters *.o
^ As soon as user types a space, the command runs and prompts
^ for the argument.
All the shell reads is "rm ".
This isn't a real example; it's been fourteen years since I typed a
TENEX command and I don't remember any specific ones. I believe the
in-line prompting was provided only to novices, and that experts could
disable it. Needless to say, this made it very easy for a novice to
operate. (You could also enter a ? at any point in this dialog to get
help.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Snoopy <snoopy@doghouse.gwd.tek.COM>
Subject: Re: Has tar r ever worked? For anybody?
Date: 11 Dec 87 18:45:26 GMT
Sender: nobody@tekecs.TEK.COM
Keywords: tar driver streamers
To: unix-wizards@brl-sem.arpa
In article <1085@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes:
>If it is a streaming tape (either QIC or 1/2"), it is generally not
>possible, since positioning the tape is costly. In fact, some systems
>(Tek 61XX, for example) want you to read and write big chunks (128K) to
>avoid burning out the motor, and don't supply tape record backspace.
The "burning out the motor" bit refers to the Cypher drives, which were
disqualified. All production units have Wangtek drives, which don't
burn out their motors. A large block size is still recommended to
minimize the amount of time wasted repositioning the tape.
Snoopy
tektronix!doghouse.gwd!snoopy
snoopy@doghouse.gwd.tek.com
Pizza. Just say yes.
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.COM>
Subject: Non-writes to /tmp
Date: 11 Dec 87 21:36:34 GMT
Sender: nobody@tekecs.TEK.COM
To: unix-wizards@brl-sem.arpa
[]
"As you know, UNIX does writes when it feels like it, and uses
any available in core blocks to read from. So if a program
started and finished between /etc/update's sync's, the only
disk overhead would be that of creating and deleting a
directory entry which is done synchronously."
On my system, the major use of /tmp files is for one phase of a
compiler to pass information to the next. The close in the first
(writing) phase seems to force the blocks to disk. Or does it?
"If you declare /tmp as a disk, you will be keeping two copies
of the most recently used blocks in core."
You'll only have two copies (one in the virtual /tmp) if you would
otherwise have written a copy to disk (to the real /tmp). Sounds like
a win to me.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.COM>
Subject: Re: //host vs "mount point"
Date: 11 Dec 87 21:59:05 GMT
Sender: nobody@tekecs.TEK.COM
To: unix-wizards@brl-sem.arpa
[]
"You will be happy to learn that //host1//host2/etc/passwd does
in fact work under DFS."
But it wasn't meant to; it only works by accident.
And a triple reference fails:
% ls -ld //lemming//hammer//tekecs
ls : //lemming//hammer//tekecs : Too many levels of symbolic links
(There were no symlinks among these three roots.)
"And you *can* mount remote filesystems if you really want to."
No you can't:
% /etc/mount //lemming/dev/ds66a /l
mount : //lemming/dev/ds66a on /l : Reference is to remote file (sys74)
"I prefer using symbolic links which: (a) are more flexible,
and (b) don't require the superuser(s) to get involved."
A big lose of symlinks for this is that root can accidentally "rm" the
connection. You can't "rm" a mounted mountpoint.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: Rick Rashid <rfr@TEMP.IUS.CS.CMU.EDU>
Subject: Re: //host vs "mount point"
Date: 12 Dec 87 03:22:45 GMT
Sender: netnews@PT.CS.CMU.EDU
To: unix-wizards@SEM.BRL.MIL
The "/.." remote file system in use at CMU has a fair amount of history going
back to 1980. It originated with a library based implementation called
Lucifer done by Alex Schaeffer (now at Stanford). The idea, but not the code,
was picked up on by Mike Accetta at CMU and implemented in an early BSD
kernel in 1981. Originally, the syntax Mike used was "[host]/usr/foo".
This caused no end of grief for UNIX programs which could not parse filenames
with "[]" in them. Mike then picked up the "/.." idea from the Newcastle
work. It was carried over into Mach by Mike and is one of two compatible
remote file systems in use in CMU-CSD, the other being the ITC's VICE
file system.
A lot of fine tuning went into the use of "/.." and the way in which
cd and pwd deal with remote directories. In particular, most things
you say make sense if you think of /.. as the super-root directory which
contains in it the root directories of machines on the network.
For example:
cd /../rfr/usr/rfr/../../../temp
pwd
Yields:
/../.temp.ius.cmu.edu
Where the pwd command provides the full domain name to disambiguate
the machine for the user (a local convention).
Also:
cd /../rfr/usr/rfr/../../../temp/usr/rfr/../../../rfr/usr/rfr
Is the same as:
cd /../rfr/usr/rfr
If you "cd /.." and say "ls" you get a list of all the machines in the
CS Department. If you then "cd host" you are at the root for that host.
The scheme is certainly not perfect. In particular, as noted in the
previous notes, "/../.." must be thought of as special since it is, in
fact, your "real root". While this makes some sense, and indeed
/../../bin is really /bin, it can be confusing without an explanation
(and even sometimes with one). Since "/../.." wouldn't logically mean
anything but "super-super-root" I don't personally feel real bad about
punning on it in this way, but I do understand the concern expressed.
-Rick
BTW: The use of "/../host" is a convention and not a requirement.
In fact, the remote hosts links are special files which can be placed
anywhere in your file hierarchy using a program called "remhost".
Because /.. is so useful, this fact is seldom taken advantage of, however.
One negative to the fact that the remote links are files is that you cannot
simply access a host by /../host unless that host file has been entered.
The cost of entering, though, is small and in practice hundreds of hosts
are in our "/.." at CMU. It would be a relatively simple manner to
add automatic updates to "/.." upon reference. There is already
a daemon which will automatically switch symbolic links to remote
directories from one machine to another upon host or network failure.
This, combined with an automatic file replicator daemon,
allows a (very) poor man's form of replicated remote files.
-----------------------------
From: Dave Ihnat <ignatz@chinet.uucp>
Subject: Re: getlogin(3C) returns bogus name
Date: 11 Dec 87 16:17:36 GMT
Keywords: getlogin, username, login
To: unix-wizards@SEM.BRL.MIL
Yep; I've seen this one, when I was porting 'mdm'. I'll bet you're
running more than one shell login window. It seems that getlogin() isn't
quite swift enough to differentiate between the physical device--probably
'console'--and the virtual windows 'w1', 'w2', etc. on that device; so
it'll return whatever it finds first in /etc/utmp. I haven't spent
the time yet to yank the object out of the library, rewrite it, stuff
it back in the library, etc. Not to mention having to muddle around
in the shared library...
--
Dave Ihnat
ihnp4!homebru!ignatz || ihnp4!chinet!ignatz
(w) (312) 882-4673
-----------------------------
From: Matt Costello <matt@ncr-sd.SanDiego.NCR.COM>
Subject: Re: Request for human interface design anecdotes
Date: 12 Dec 87 03:54:21 GMT
To: unix-wizards@brl-sem.arpa
The real problems in interface design generally occur because of
unstated assumptions. We had a hilarious incident occur here
recently...
There is a plan here to put a PC on every desk, including those of
secretaries and managers. So that each individual would not have
to waste time aquiring a decent editor and the other tools, a
package was put together containing 10 disks of software that was
PD or that we had a license for. At the part of the installation
process where the files were to be copied on the hard disk, the
instructions said to insert each of the 10 disks into the floppy
disk drive. Imagine our suprise when a worried secretary called
to say that she had been able to fit only 5 of the disks into the
disk drive. Fortunately no damage occured and the instructions
were quickly changed.
Disclaimer: I don't have a PC, nor do I want one.
--
Matt Costello <matt.costello@SanDiego.NCR.COM>
+1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET>
{sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt
-----------------------------
From: Matt Costello <matt@ncr-sd.SanDiego.NCR.COM>
Subject: Re: Wait, Select, and a SIGCHLD Race Condition
Date: 12 Dec 87 05:53:50 GMT
To: unix-wizards@SEM.BRL.MIL
In article <5105@sol.ARPA> stuart@cs.rochester.edu writes:
>I need advice (or sympathy) for handling a race condition in 4.3BSD
>flavored UNIX. Briefly, I want to use wait3 to reap all the dead or
>stopped children of a process, then use select to wait for the first
>new IO or child activity.
I've two methods I use to get around the race conditions in signals.
They are:
1. If you are not using SIGALRM for something else, have your timeout
routine re-enable the SIGALRM on 1 second intervals until it is
turned off in the outer level code. If the original signal hits
the timing hole then the second (or third) won't.
The beauty of this is that it usable in any version of UNIX, since
it uses no features specific to BSD or USG.
For wanting to not miss any child processes with SIGCHLD:
onedied() {
signal(SIGCHLD,SIG_DFL); /* will infinite loop otherwise */
signal(SIGALRM,onedied); alarm(1);
}
signal(SIGCHLD,onedied);
/* race condition is here... */
numfds = select(); /* or read(), or msgrcv() */
alarm(0);
2. For select() or any operation where the process is waiting on incoming
IO, you can have the signal routine send a dummy message that will
cause the select() to return immediately. Rather than aborting the
operation find some way to make it terminate normally. This works
wonderfully for SYSV message queues since it is perfectly legal to
send a zero length message.
--
Matt Costello <matt.costello@SanDiego.NCR.COM>
+1 619 485 2926 <matt.costello%SanDiego.NCR.COM@Relay.CS.NET>
{sdcsvax,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt
-----------------------------
End of UNIX-WIZARDS Digest
**************************jc@minya.UUCP (John Chambers) (12/21/87)
Lately I've been seeing a bunch of these in this newsgroup and a couple
of others. They are huge files, and nearly double the space a newsgroup
occupies on disk. They also add measurably to the modem time. Does
anyone out there know a simple, elegant way to eliminate them?
Note that I'm not criticising the people who do them. I understand
that there are machines that don't or can't run usenet, and there is
a good use for such digests. I just don't want the original newsgroup
and the digest both on my machine. My disk space is not unlimited.
Perhaps we need a separate mechanism for distributing such summaries.
Hey, I just thought of one: a separate, moderated newsgroup. Isn't
that an original idea? Do you think we might implement it? {(:-)}
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)