UNIX-WIZARDS Digest V5#107
Mike Muuss
Unix-Wizards-Request at arpa.brl
Mon Jul 25 17:45:14 AEST 1988
UNIX-WIZARDS Digest Mon, 25 Jul 1988 V5#107
Today's Topics:
Re: Who dat?
Re: Input Line Editing
Re: File checker: A summary
ptrace question
NCR 800 flame (was: Re: Cheaper winnies on an NCR tower)
Re: Input Line Editing
Re: The Name of the Beast
Re: SysV RFS Puzzle
Mfg's ripoff prices for disks (was Re: Cheaper winnies on an NCR tower)
-----------------------------------------------------------------
From: "John F. Haugh II" <jfh at rpp386.uucp>
Subject: Re: Who dat?
Date: 23 Jul 88 16:21:12 GMT
To: unix-wizards at SEM.BRL.MIL
In article <4909 at watdcsu.waterloo.edu> dmcanzi at watdcsu.waterloo.edu (David Canzi) writes:
>Maybe a server can securely verify the userid of a client by requiring
>the client to create a setuid file with name *and* *contents* specified
>by the server?
>--
>I am not David Canzi, my name is.
or perhaps, require the file be created with only one link? and with
a current last file modified/accessed/inode-changed collection of times?
- john.
--
I don't live in a desert, my name does ;-)
--
John F. Haugh II +--------- Cute Chocolate Quote ---------
HASA, "S" Division | "USENET should not be confused with
UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE"
DOMAIN: jfh at rpp386.uucp | -- with my apologizes
-----------------------------
From: John Plocher <plocher at uport.uucp>
Subject: Re: Input Line Editing
Date: 23 Jul 88 23:37:13 GMT
To: unix-wizards at brl-sem.arpa
In article <6339 at bloom-beacon.MIT.EDU> Theodore Y. Ts'o writes:
> putting the line editor in the shell is the right thing to do.
I've found all three methods (in shell, in kernel, in program) to
be useful at different times. For the *few* programs that need
special editing (pre-selected defaults, interactive command driven things,
etc) a simple library call to an edit_gets() solves many problems
without making anyone else's programs pay for the feature.
For most of the other interactive editing I do, the shell (ksh) editing
features meet my needs. If you think about it, the shell has its own set
of library calls to do line editing, so there are only 2 methods :-)
The normal editing that the tty driver does is often enough for
the programs which don't need the complex editing features outlined
by other posters here.
Like most things in the Real World, there isn't always one Right Thing.
It is a Good Idea to provide a method, but let someone else provide policy.
Library calls (or dynamic linkage or configuration thru ioctl()s...) to
set up an editing environment are OK, but don't implement something that
could get in the way of a program which didn't need it.
-John Plocher
-----------------------------
From: Henry Spencer <henry at utzoo.uucp>
Subject: Re: File checker: A summary
Date: 24 Jul 88 00:54:31 GMT
To: unix-wizards at brl-sem.arpa
In article <16608 at brl-adm.ARPA> dsill at nswc-oas.arpa (Dave Sill) writes:
>1) Two people suggested short awk/ls/diff-based scripts. For my
>purposes, this is inadequate. I need to check about 1500 files and
>any form of shell script would just be too slow.
Did you try it? It ain't necessarily so. Ignoring the annoying problem
of argument lists being too long, this should be
ls -... lotsafiles | awk '...' | diff - whatitoughttobe
which ought to be amply fast unless you're running this thing every five
minutes. Kind of academic since you do have a C solution, but automatically
dismissing shell-and-filters solutions as "too slow" is a sign of ignorance.
Well-done shell programs are often fast enough.
--
MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology
smells that way. | uunet!mnetor!utzoo!henry henry at zoo.toronto.edu
-----------------------------
From: hartman at m.cs.uiuc.edu
Subject: ptrace question
Date: 24 Jul 88 01:45:00 GMT
Nf-ID: #N:m.cs.uiuc.edu:9100009:000:613
Nf-From: m.cs.uiuc.edu!hartman Jul 23 20:45:00 1988
To: unix-wizards at brl-sem.arpa
What is (is there) a difference between 'ptrace' under Berkeley UNIX and
under System V? My SVR3 man page says something like "provides a means
by which a PARENT process may control the execution of a CHILD process".
The BSD entry says something more like "the execution of ANOTHER process".
I like the less restrictive, BSD definition better -- but is there really
a difference in functionality, and if so, why?
Also, any short examples demonstrating the use of 'ptrace' would be
appreciated. Thanks.
--
Mark Hartman hartman at cs.uiuc.edu
..uiucdcs!hartman
-----------------------------
From: Timothy Reed <txr98 at wash08.uucp>
Subject: NCR 800 flame (was: Re: Cheaper winnies on an NCR tower)
Date: 24 Jul 88 01:27:30 GMT
Keywords: NCR TOWER 32/600 drive
To: unix-wizards at brl-sem.arpa
(flame on)
That's interesting that NCR goes to such lengths to test those HD
cart tape drives, then how could they release the 800 with a virtually
incompatible drive, when compatibility with [246]00's is such a
selling point. I'll tell you, we weren't told about this by NCR - not
'til the thing was installed - I actually first found out about it
through the net! The 'dd' solution means we have to dd a tape out to
disk and read it on again, or take the 800 into account with every tape
we write - both methods slow and cumbersome, with the cause totally
unecessary - the 800 should not have been released until the cart drive
was made compatible with the others n the NCR family.
(flame dying down)
How come 'cpio -B' doesn't swap bytes correctly? And why does the
byte swap have to take place during the write - 'dd if=/dev/rstp/00yy
conv=swab' doesn't work - this kind of kludge would be much more
palatable.
(flame off completely)
Glad to see the reset button moved out from 'under the hood' - you
can't get to the switch when you got a bunch of towers next to each
other.
# Tim Reed
# Usual disclaimers - I'm commenting entirely on my own behalf.
-----------------------------
From: "Brandon S. Allbery" <allbery at ncoast.uucp>
Subject: Re: Input Line Editing
Date: 24 Jul 88 02:44:14 GMT
Followup-To: comp.unix.wizards
To: unix-wizards at SEM.BRL.MIL
As quoted from <9677 at eddie.MIT.EDU> by nessus at wonko.MIT.EDU (Doug Alan):
+---------------
| > From: henrik at blblbl.UUCP (Larry DeLuca)
| > While it's not going to help the ile people much, it still seems the
| > best place for a line editor of some sort is still the tty driver
| > (ioctl's can be used to set characters or toggle between modes).
|
| No, you're wrong.
+---------------
Strong disagreement. Given a STREAMS-based tty driver, one could push the
following modules:
terminfo-like module (or termcap, depending on your prejudices)
input line editor module
output module -- replaces more, etc.
The TLM would be able to accept a term{cap,info} entry by grabbing an ioctl
(or whatever; my STREAMS guide is still on order) with the data in it. The
user could push their own choice of input and output filters (vi/emacs, more/
less) or leave off either or both. Then programs could do "smart" screen
I/O via ioctls or etc. (or even by canonical escape sequences, as with the
existing SysV facilities -- not that I've ever seen a SysV kernel with any
of the virtual terminals actually compiled in) processed by the TLM.
To the person who wants a "dumb X" -- isn't that what "window" is?
++Brandon
--
Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY
For comp.sources.misc send mail to ncoast!sources-misc
-----------------------------
From: Mark Reynolds <mark at aoa.uucp>
Subject: Re: The Name of the Beast
Date: 24 Jul 88 17:58:11 GMT
Keywords: dynix
To: unix-wizards at SEM.BRL.MIL
In article <5007 at husc6.harvard.edu> sob at harvisr.UUCP (Scott Bradner) writes:
>In working up a talk about unix to be given to the IBM "share" user's
>group ( Flames to /dev/null ) I thought it might be interesting to
>include a list of the various ways that vendors ( & others ) spell unix.
>
>I've got:
> UNIX (tm)
> ....
dynix
Mark Reynolds
...!BBN.COM!bbn!aoa!mark
-----------------------------
From: Leslie Mikesell <les at chinet.chi.il.us>
Subject: Re: SysV RFS Puzzle
Date: 24 Jul 88 21:09:59 GMT
To: unix-wizards at SEM.BRL.MIL
In article <734 at mccc.UUCP> pjh at mccc.UUCP (Pete Holsberg) writes:
>
>I have Starlan and RFS running between a pair of 3B2/400s which are
>running SysV R3.1.2. Machine mc3 is advertising resource mc3-root to
>the primary (mccc). That resource is on mccc's automatic mount list,
>yet mccc says that there are no resources available for mounting. ???
>
>What's happening? How do I get mccc to mount mc3's resource? Thanks.
>(I've been using the sysadm menus to do all this. Is there a bug
>somewhere?) I should point out that at one point mc3-root was indeed
>mounted on mccc's /mnt, but since rebooting mccc, I can't get mccc to
>mount mc3-root.
When you reboot the primary name-server, you lose all the resource names
although any current mounts would continue to work. The solution is
to designate mc3 as a secondary name server or always re-boot it after
re-booting mccc. Or, you can fix things manually:
If you go to mc3 and "unadv resource_name" followed by "adv resource_name
directory", it should clear things up, and "nsquery" will show the
resource. At that point you can go to mccc and mount it with the
command "mount -d resource_name directory". There may be an automatic
recovery process attempting to do the mount, though. If so you should
either wait till it succeeds or kill it after mounting manually.
If you have designated a secondary name server, note that it
takes over automatically if the primary goes down, but you must manually
switch back before anything new can be advertised (using "rfadmin -p" at
the secondary). Also note that no process can be using the mount point
(or below) as its current directory when the mount is done (but this would
give a different error message).
Les Mikesell
-----------------------------
From: Peter Rowell <peter at thirdi.uucp>
Subject: Mfg's ripoff prices for disks (was Re: Cheaper winnies on an NCR tower)
Date: 24 Jul 88 22:10:05 GMT
Keywords: NCR TOWER 32/600 drive
To: unix-wizards at brl-sem.arpa
In some article ockenden at prlhp1.prl.philips.co.uk (Paul T Ockenden) writes for someone else
:
:We have an NCR Tower 32/600 here. NCR being the *wonderful*
:people they are want about (UK#)4500 for a 140Mb drive. This sticks in
:my throat.
: ...
:
:Second. 4500 UK Pnds for a 140Mb drive is er... a little steep...
To which vause at cs-col.Columbia.NCR.COM (Sam Vause) replies:
>The design of the operating System disk interface code precludes the addition
>of any non-approved disk into the TOWER. The reason for this is *NOT* to
>inconvenience you as a customer, but to make sure that only *CERTIFIED* drives
>are installed--the reliability of the machine and its data is the most impor-
>tant issue here. Drives this size *MUST* have an extremely high reliability
>rating.
>
Sam: Did it occur to you that if he wants to put in his own damn drive
that maybe he has the right to do that and would not expect NCR to
guarantee it til the Second Coming of Christ? If, in fact, he *did*
expect NCR to guarantee it, just say that it, and any problems that
exist *only* when it is plugged in, are *his* problems, and not yours.
This reply (and, I am certain, the corporate policy that spawned it)
smacks of the worst kind of patronization in order to justify
near-criminal profit margins on mass storage. Yes, I am fully aware
that NCR has plenty of company in this particular boat, including DEC,
Sun, and every other system manufacturer I have ever done business with.
I have been quoted a price, by one of my current system vendors, of $4400
for an out-of-the-box CDC Wren II with the normal 90 day warranty. Literally
2 miles away, I found the same drive from a disrtributor for $895 and
the warranty was 30 days money back, 6 months swap out! Unless we believe
that the distributor was operating as a non-profit institution, we must
assume that the system vendor is being criminally greedy.
I could go on, but my blood pressure is going up.........
----------------------------------------------------------------------
Peter Rowell "You will need a bigger rock."
Third Eye Software, Inc. (415) 321-0967
Menlo Park, CA 94025 ...!pyramid!thirdi!peter
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list