UNIX-WIZARDS Digest V5#108
Mike Muuss
Unix-Wizards-Request at arpa.brl
Tue Jul 26 17:45:20 AEST 1988
UNIX-WIZARDS Digest Tue, 26 Jul 1988 V5#108
Today's Topics:
Re: Cheaper winnies on an NCR tower
Re: Input Line Editing
Re: Cheaper winnies on an NCR tower
Re: ptrace question
Re: Input Line Editing
Big Fun with Sys V signal handling
pty's
File checker: A summary
UNIX-WIZARDS Digest V5#105
Re: Cheaper winnies on an NCR tower
Re: Root shell in shell scripts, HELP?
Re: Cheaper winnies on an NCR tower
-----------------------------------------------------------------
From: "G.Pavlov" <pavlov at hscfvax.harvard.edu>
Subject: Re: Cheaper winnies on an NCR tower
Date: 25 Jul 88 00:50:08 GMT
Keywords: NCR TOWER 32/600 drive
Posted: Sun Jul 24 20:50:08 1988
To: unix-wizards at SEM.BRL.MIL
In article <105 at cs-col.Columbia.NCR.COM>, vause at cs-col.Columbia.NCR.COM (Sam Vause) writes:
> 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.
>
Does NCR manufacture its own drives for the Tower series ?? If not, what
does it do to them to make them worth their weight in gold (almost literally)?
greg pavlov, fstrf, amherst, ny
-----------------------------
From: Kazumasa Utashiro <utashiro at sran84.sra.junet>
Subject: Re: Input Line Editing
Date: 25 Jul 88 04:29:09 GMT
Sender: news at sragwa.sra.junet
To: unix-wizards at brl-sem.arpa
In article <9666 at eddie.MIT.EDU> nessus at wonko.MIT.EDU (Doug Alan) writes:
>> In article <16456 at brl-adm.ARPA> rbj at nav.icst.nbs.gov (Root Boy Jim) writes:
>>
>> > I suspect that the real place for line editing is either in the shell
>> > itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel.
>>
>> Putting line editing in the shell is wrong, because it should work in
>> all programs and be consistent. Putting it in the kernal is gross.
>> Thus, the right place to put it is precisely where Bob Pendleton wants
>> to put it -- in a process which gets input from the user and feeds
>> edited input to the user's other programs. If needed, mods to the
>> kernal and convention, however, should be made to make this as easy
>> and efficient as possible.
I have a program that provide input line editing function for any old
fashioned UNIX style commands. It is distributed as a free program in
JUNET (UNIX network in Japan), but I'm not sure that it is to be
distributed for world. So I include man page of this command and want
to hear about its function. It looks almost like newcsh except that it
works as a front-end for *any* program (even for vi :-). Note that
this command is not based on any great concept like user interface
should be something, but just a simple tool. Please don't talk to me
about where the line editing should be placed as a comment for this
program. If somebody want this program, I can post it to appropriate
news group. Thank you for reading my bad English.
Kazumasa Kayo Utashiro
Software Research Associates, Inc.
1-1-1 Hirakawa-cho, Chiyoda-ku, Tokyo 102, Japan
UUCP: kddlab!srava.sra.junet!utashiro
ARPA: utashiro%sra.junet at uunet.uu.net
JUNET: utashiro at sra.junet
NAME
fep - general purpose front end processor
SYNOPSIS
fep [-emacs|-vi] [-h history-length] UNIX-command
DESCRIPTION
Fep is a general purpose front end processor applicable to
most UNIX commands that features vi(1)- or emacs(1)-like
line editing and a command history mechanism like that of
csh(1).
Choice of editing style is made by selecting either the
emacs mode or the vi mode (named for the editors they emu-
late), specified either by command line option or by setting
a variable interactively or in the start-up file or environ-
ment EDITMODE (see editmode variable).
The default key bindings are shown below for both edit
modes. These can be customized using the fep-bind command.
Emacs Bindings
Here follow the default key bindings for the emacs mode.
Each function name should be self-explanatory. The function
names are defined as similarly to Gosling's emacs as possi-
ble.
...
Vi bindings
The vi mode has two sub-modes, the command mode and the text
insert mode. The commands of vi are emulated as correctly
as possible. Here is a list of the default key bindings of
the vi mode that differ from normal vi commands. The tty
driver control characters are also inherited in this mode.
...
Built-in commands
Fep has some built-in commands that are not passed to the
child process but understood and processed by fep itself.
These commands can be issued from the terminal or from the
start-up file.
fep-bind function-name key-binding
Change key bindings. For example, to bind the func-
tion list-file-name to the string "^X-^X", type the
following:
fep-bind list-file-name "\^X\^X"
fep-alias
fep-alias name
fep-alias name string
The first form prints all aliases. The second form
prints the alias for name. The last form set the
alias for name to string.
If you use fep without auto-tty-fix, following alias
could be usefull.
if $command == sh
fep-alias more "fep-command more"
fep-alias vi "fep-command vi"
endif
fep-unalias list
Remove alias for each name in list.
fep-set variable = value
Set a variable of fep to some value.
fep-unset variable
Unset a variable.
fep-cd [ directory ]
fep-chdir [ directory ]
Change directory. It sometimes happens that a child
process has changed directory, but fep is still in
the old directory. In such a case, neither list-
file-name nor expand-file-name will function as
expected. This command allows you to change fep's
current working directory (default = home direc-
tory).
fep-pwd
Print fep's current working directory.
fep-history [ number of line ]
Show the history of commands under fep.
fep-echo arguments
Only print the arguments. Variable names can be
used prefixed by the "$" character.
fep-source file
Read the specified file and execute it. The con-
tents of the file are not sent to sub-processes.
fep-save-history [ number of lines to save ] file
Save the current history buffer in the specified
file.
fep-read-history [ file ]
Read in the command history from the specified file.
The default file is the value of the history-file
variable. This file name is understood as a path
relative to the home directory. If you want to
specify the name relative to the current directory
instead, prefix the path by "./".
fep-command command
fep-! command
Execute command.
fep-exit
Kill the sub-process and exit.
fep-suspend
Suspend fep itself. In the unlikely possibility
that fep falls into a dead-lock in which the sub-
processes have stopped but fep is still running, use
one of these commands to escape from the situation.
fep-read-from-file file
fep-< file
Read data from specified file and send them to sub-
process. The sub-process will read the data from
the file as if they are typed at the keyboard.
fep-read-from-command command
fep-<! command
Send output of specified command to sub-process.
fep-start-script [ script-file ]
fep-script [ script-file ]
Start to send input and output to a script file. If
script-file is specified, it is used. If not the
value of the variable script-file will be used.
fep-stop-script
Stop scripting.
fep-show-bind
Print current binding information.
Control structures
fep-if expression
fep-elseif expression
fep-else
fep-endif
Only four control structures are supported but that
seems enough. Expression allows only the two opera-
tors "==" and "!=".
Variables can be referenced by prefixing with the
"$" character.
Note: The "fep-" prefix of the built-in functions and
the above operators can be abbreviated in commands that
fep executes from a file.
Comment
Lines starting with the character "#" are ignored by fep.
If fep encounters a comment in interaction, it is sent to
the sub-process. In reading from a file, comments will
merely be ignored.
Variables
Fep uses some variables.
editmode default: emacs
This variable defines the mode for command line
editing. Key bindings will be set for the appropri-
ate defaults when this variable is changed. Fep
first looks at the environment variable EDITMODE,
then looks at any command line arguments, and
finally reads in the .feprc start-up file.
expand-tilde default: on
Fep expands "~" to the real home directory name by
the expand-file-name function when this variable is
set.
ignore-empty-line default: on
If this variable is set, empty command lines are not
saved in the history file.
ignore-same-line default: on
If this variable is set, command lines identical to
the previous command line are not saved to the his-
tory file.
alarm-on-eof default: on
If this variable is set AND the function send-eof is
not bound to the eof character AND the variable
ignore-eof is not set, an alarm message will be
displayed once the first time eof is encountered on
an empty line.
history default: 100
Fep maintains a history file of the length specified
by this variable.
savehist default: off
If savehist is set fep saves the number of history
entries specified by value of this variable in the
file named in the variable history-file on terminat-
ing.
history-file default: .fephistory
Contains the name of the history file for reading
from and writing to. If the file described by this
variable exists, fep will read the file into the
history buffer on start up and then save the current
session's history when it exits.
showhist default: 20
This variable specifies the number of history lines
to be displayed by the show-history function.
ignore-eof default: off
Fep never worries about the eof character if this
variable is set.
noalias default: off
If set, command aliasing won't be done.
crt default: 24
If set, more message is shown during printing the
key bindings on each number of line specified by
this variable.
command default: command-name
Fep set this variable to the command name of the
sub-process when it starts up.
shell default: /bin/sh
Describe the command name to be invoked by invoke-
shell.
auto-tty-fix default: on
If this variable is set, fep looks at the tty mode
of the sub-command, and if the tty mode has changed,
fep fixes the tty mode of standard out and sets the
transparency flag according to the mode. Since this
tty mode check is done about a second after the last
input, please wait just one second after entering
cbreak mode. If this variable is not set, the
automatic tty mode check is not done, so you have to
change the tty mode and transparency explicitly
using the toggle-transparency function.
tty-fix-bell default: off
If this variable is set, fep rings the bell when the
tty mode is changed.
script-file default: fepscript
This variable is used by the fep-start-script com-
mand and by the start-script function.
delimiters
The contents of this variable are treated as delim-
iting characters for file name expantion and file
name list.
prompt default: see below
Fep outputs a prompt after executing built-in func-
tions. The default string is set to the NULL
string, but there are some default prompt strings
for some common commands such as sh, dbx, lpc, mail,
sendmail -bt and calc. However, since fep doesn't
care about what program is running, the same prompt
is still output when you are executing bc from sh.
You can change the value of prompt and other vari-
ables in the start-up file as follows:
if $command == sh
set prompt = "$ "
endif
Start-Up File
Fep executes the file ".feprc" in the home directory of the
user if it is found there when starting up. It looks for
arguments on the command line first, and only then reads the
".feprc" file, so the file has higher priority.
Functions
abort backward-character
backward-word beginning-of-line
delete-line delete-next-character
delete-next-word delete-previous-character
delete-previous-word delete-to-kill-buffer
end-of-line end-script
expand-file-name forward-character
forward-to-end-of-word forward-word
ignore invoke-shell
insert-and-flush insert-tab
kill-to-end-of-line kill-to-top-of-line
list-file-name literal-next
mark new-line
next-history previous-history
reprint search-forward
search-reverse self-insert
send-eof show-bindings
show-history start-script
terminate toggle-transparency
yank-from-kill-buffer
vi-c vi-d
vi-edit vi-ins-edit
vi-motion vi-new-line
vi-num
Probably only the function name "toggle-transparency" is
hard to understand. This function is provided for entering
non-line-oriented tools from a line-oriented tool using fep.
Assume a situation where you are using sh(1) with fep, and
then invoke vi(1). Since fep intercepts all input for edit-
ing, vi cannot work correctly. You can escape from this
annoying situation using the "toggle-transparency" function
which is bound to the Control-^ key by default. Of course
it is also necessary to return to the normal mode after
exiting vi.
This tty mode fix can be done automatically. If the auto-
tty-fix variable is set, fep looks at the tty mode of the
sub-command and fixes the tty mode of standard in accord-
ingly. This fix is done 0.5, 1, 5, 10, 60 seconds after the
last input, so if you enter cbreak mode plase wait just one
second. Then you can use vi(1) or any other tool using the
cbreak or raw mode.
OTHERS
Fep can bandle SHIFT-JIS kanji code if compiled with the
-DKANJI flag.
SEE ALSO
newcsh(1)
AUTHOR
K. Utashiro
Software Research Associates, Inc., Japan.
UUCP: kddlab!srava.sra.junet!utashiro
ARPA: utashiro%sra.junet at uunet.uu.net
JUNET: utashiro at sra.junet
FILES
~/.feprc, ./.feprc start-up file
~/.fephistory default history file
BUGS
While working on the program the author sometimes lost his
mind, whereupon so did the program.
-----------------------------
From: "H. L. Rogers" <rogers at ofc.columbia.ncr.com>
Subject: Re: Cheaper winnies on an NCR tower
Date: 25 Jul 88 14:57:09 GMT
Keywords: Have you ever worked in the real world?
To: unix-wizards at SEM.BRL.MIL
-------------------------------------------------------------------------
***PLEASE DIRECT REPLIES TO alt.flame OR /dev/null.
GET THIS DISCUSSION OUT OF wizards.***
-------------------------------------------------------------------------
In article <601 at hscfvax.harvard.edu> pavlov at hscfvax.harvard.edu (G.Pavlov) writes:
> Does NCR manufacture its own drives for the Tower series ?? If not, what
> does it do to them to make them worth their weight in gold (almost literally)?
Do you know anything about the real world? Or do you just hide-out
on campus and pretend?
No, NCR does not manufacture disk drives. NCR buys drives from drive
vendors, just like Sun, DEC, Apollo, and others do. Your comment about
"...worth their weight in gold..." shows you either don't know the
price of gold or the weight of a disk drive. You don't even come
close. I just wish I could sell 140 MB for over $30K!
I *do* know what value is added and I *do* know *competitive* pricing
in the marketplace. The value which is added amounts to very intensive
qualification testing and reliability measurements before the first
drive is ever shipped in a TOWER. NCR also does some very neat
things like empirically determining the optimum interleave factor
for a particular drive to maximize I/O performance. NCR also
provides optimum software integration for each drive it supports.
I doubt that we are very much different from other vendors in
all these areas.
As to the price, NCR remains *competitive* with every other *computer*
vendor on the basis of dollars per megabyte. Check it out. NCR does
not claim to be *competitive* in its drive pricing with the price of a
disk purchased directly from a disk vendor. If a customer wants to buy
his own drive and integrate it into the TOWER, then go for it! What
Sam was trying to say is that if you expect NCR to support that drive
as a part of your NCR maintenance contract, don't hold your breath.
On the other hand, if it is a drive qualified and supported by NCR,
I am quite sure NCR Customer Services will support the extra drive
for only a slight increase in the price of the support contract.
Just in case you don't understand why the support contract price
would go up, it is because it is based upon the mean time between
failures (MTBF) of the equipment. Additional electronics will
decrease the MTBF, making the particular equipment more expensive
to maintain because it is *predicted* to fail more often.
Many customers buy drives from NCR because they know the value of
reliability testing and enjoy the painless integration of
additional parts. But we don't discourage those who want to
"roll their own." The only caveat in addition to the maintenance
contract discussion above is: if the software does not recognize
the drive as one of many it *can* talk to, then you're going to need
help from the TOWER software developers to make it work. And, Mr. G.
Pavlov, NCR has done just that for several customers.
No flames, please...I just can't stand to see a Harvard man get
red-faced.
--
HL Rogers (hl.rogers at ncrcae.Columbia.NCR.COM)
-----------------------------
From: Guy Harris <guy at gorodish.sun.com>
Subject: Re: ptrace question
Date: 25 Jul 88 17:42:09 GMT
Sender: news at sun.uucp
To: unix-wizards at SEM.BRL.MIL
> What is (is there) a difference between 'ptrace' under Berkeley UNIX and
> under System V?
Little, if any.
> 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?
Yes, I like it too, but the only "other" processes that can be "ptrace"d in
4BSD are child processes; there really is no difference in functionality.
SunOS has an "attach" request that can be used to attach to other processes and
trace them, which comes in handy when debugging daemons, for instance.
-----------------------------
From: Peter da Silva <peter at ficc.uucp>
Subject: Re: Input Line Editing
Date: 25 Jul 88 15:19:12 GMT
To: unix-wizards at SEM.BRL.MIL
In article <922 at esunix.UUCP>, bpendlet at esunix.UUCP (Bob Pendleton) writes:
> From article <1112 at ficc.UUCP>, by peter at ficc.UUCP (Peter da Silva):
[ description of what you put a poor UNIX box through if you use RAW mode ]
> What Peter says is true. BUT, it is not a reason to stop looking for
> better ways to do things, or for opposing changes that would make
> using separate input line editing processes easier.
This is true. In System V the place to put this sort of thing, I guess,
would be a streams module. In an ideal world, you would put this in a
lightweight realtime process in the realtime operating system you're
running UNIX on top of.
Even if you give everyone a VAX, you still would be far better off with
a realtime kernel that is, itself, a seperate process. For more info,
see my articles on comp.sys.amiga where I talk about my fantasy of running
UNIX under AmigaOS (which *is* a realtime operating system that supports
lightweight processes).
--
Peter da Silva `-_-' Ferranti International Controls Corporation.
"Have you hugged U your wolf today?" (uunet,tness1)!sugar!ficc!peter.
-----------------------------
From: "Michael C. De Masi" <demasi at paisano.uucp>
Subject: Big Fun with Sys V signal handling
Date: 25 Jul 88 18:39:47 GMT
Keywords: signals make system calls croak
To: unix-wizards at brl-sem.arpa
Hello Wizards,
This is, I guess, more of a general question than I usually
post. Can anybody out there point me towards a generalized
text on strategies to process signals in a full screen run
time unix environment? Several applications around here
are having great troubles with the concepts involved here,
and it's hard to give them hard and fast rules that have
any meaning to their plight.
We do understand the basics behind signal() and the rest
of the signal handling facilities supplied with the system,
that's not the problem. The problem is developing some
set of strategies which will allow our programmers to use
these facilites in a coherent and useful fashion.
Any suggestions would be greatly appreciated, including
those which simply represent your personal views on the
subject. Please email if possible.
Thank you,
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
2340 Dulles Corner Blvd. Herndon, Virginia 22071 Phone: 703-834-8123
UUCP: decuac!grebyn!paisano!demasi
"All things considered, I'd rather be in Philadelphia" - W C Fields
-----------------------------
From: Freedman <jfjr at arpa.mitre-bedford>
Subject: pty's
Date: 22 Jul 88 12:34:57 GMT
Sender: unix-wizards-request at uk.ac.ucl.cs.nss
Posted: Fri Jul 22 13:34:57 1988
Full-Name: Freedman
Posted-From: The MITRE Corp., Bedford, MA
To: unix-wizards at arpa.brl
To: unix-wizards at SEM.BRL.MIL
I find ( I think ) I will have to use PTY's. I know nothing
about them. If anybody has any advice, pointers into literature,
or small examples of running code with pty's I would certainly
appreciate it. The FM (suffix of RTFM) is not at all clear about
pty's.
Jerry Freedman, Jr "Why did
jfjr at mitre-bedford.arpa Unix come from the east?"
(617)271-3191
-----------------------------
From: Dave Sill <dsill at arpa.nswc-oas>
Subject: File checker: A summary
Date: 22 Jul 88 19:15:10 GMT
Sender: unix-wizards-request at uk.ac.ucl.cs.nss
Posted: Fri Jul 22 20:15:10 1988
To: unix-wizards at mil.brl.sem.brl.mil
To: unix-wizards at brl-sem.arpa
Previously, I wrote:
> Subject: File checker
> Is there a free utility that reads a file containing a list of files
> and their modes/owners/groups, compares them to the actual files, and
> either reports the inconsistencies or corrects them? Just thought I'd
> check before I re-invent.
Following is a summary of the replies I've received to date.
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.
2) Three people mentioned that there is a nice script in "UNIX
Security" by Kochan and Wood that does this. Again, too slow for me.
3) One person suggested that such a utility would be useful if it was
quick enough.
4) One person suggested trying `cfs' by Rex Sanders. I was unable to
reach him.
5) One person suggested that the PD stat program might be useful.
True, but not a complete solution.
6) One person volunteered his own unfinished program to do this (Wade
Stebbings, wade at violet.berkeley.edu). I would have taken him up on
this, had I not already received number 7...
7) Dave Curry gave me a copy of his program `fcc', File Consistency
Checker. This turned out to be everything I wanted. It consists of
two programs: fcc and fci. Fci takes a list of files and produces a
data file for fcc based on the current stats of each file. Fcc
compares the data file against the current file system and, depending
on how you call it and how you have your data file set up, reports
differences in mode, owner, group, file type, link count, size, and
modification time. An option to fcc causes it to try to correct
owner, group, and mode inconsistencies. On my unloaded tahoe it takes
30 seconds to check 1500+ files. On a lightly loaded 780 it takes a
minute to check 1300+ files.
I've made several changes to fcc and fci, and have Dave's permission
to distribute copies of the source, which includes a makefile and man
pages, to anybody that wants them. Drop me a line and I'll send you
the shar file.
Thanks to all who replied.
-Dave
-----------------------------
From: Mike Muuss <Unix-Wizards-Request at arpa.brl>
Subject: UNIX-WIZARDS Digest V5#105
Date: 23 Jul 88 07:45:17 GMT
Sender: unix-wizards-request at uk.ac.ucl.cs.nss
Posted: Sat Jul 23 08:45:17 1988
To: UNIX-WIZARDS at arpa.brl
To: unix-wizards at brl-sem.arpa
UNIX-WIZARDS Digest Sat, 23 Jul 1988 V5#105
Today's Topics:
Re: Who dat?
Re: Cheaper winnies on an NCR tower
Request for user-contributed software
Re: Input Line Editing
-----------------------------------------------------------------
From: David Canzi <dmcanzi at watdcsu.waterloo.edu>
Subject: Re: Who dat?
Date: 22 Jul 88 03:09:48 GMT
To: unix-wizards at brl-sem.arpa
In article <14931 at oddjob.UChicago.EDU> matt at oddjob.UChicago.EDU (Ka Kahula) writes:
>) In article <3789 at rpp386.UUCP>, jfh at rpp386.UUCP (John F. Haugh II) writes:
>) > have the client create a file with the suid and sgid bits set. ...
>
>In article <51 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>) Let's see, what I do when you ask my process A to create this file is
>) to have a program B sitting around that is setuid/setgid to whomever
>) I want you to think A is; ...
>
>If you have this program B, you can impersonate your victim completely.
>Why not just assume that you have your victim's password? It comes
>to the same thing.
In versions of UNIX with which I am familiar, you need no permissions
of any kind on a file to make new links to it. So if there are setuid
files owned by root on the same filesystem as the directory where the
client process is supposed to create the setuid file, then any random
user can impersonate Mr. Root.
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.
-----------------------------
From: Sam Vause <vause at cs-col.columbia.ncr.com>
Subject: Re: Cheaper winnies on an NCR tower
Date: 22 Jul 88 12:13:48 GMT
Keywords: NCR TOWER 32/600 drive
To: unix-wizards at brl-sem.arpa
In article <531 at prlhp1.prl.philips.co.uk> ockenden at prlhp1.prl.philips.co.uk (Paul T Ockenden) writes for someone else
:
:NCR Drives : A Plea for help.
:
: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.
:
:First. Without going to an external cabinet, is there anyway of getting
:a bigger than 140Mb drive *INSIDE* the 32/600. We already have one 140Mb
Yes. You would have to purchase the 650 upgrade kit which would give you
an internal SCSI controller, and the ability to add 170MB disks.
:and the 46Mb drive so we could say bye bye to the 46Mb, if we could boot
:on it.... or move the 140Mb into the 46Mb's place... All suggestions
:gratefully accepted.....
:
:Second. 4500 UK Pnds for a 140Mb drive is er... a little steep...
No kidding! That's about US$7,425 at the moment, primarily due to the VAT
and other taxes in the UK, plus the sheer conversion rate difference (some-
thing like US$1.65 = UK#1.00 at the moment...)
:Does
:anyone know how to install a non-NCR drive into a 32/600 without
:waking up at night cold and sweating.
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.
HOWEVER, having said this, I have seen Maxtor XT1140 drives for sale as low
as US$1595 in various "Computer Shopper" magazines. NCR cannot be responsible
for the performance and reliability of drives purchased through a third-party
vendor.
:PS. These drives would have to take a hammering.....
Don't they all--that's one of the advantages of purchasing one from us--we've
completed as much stress testing and evaluation as humanly possible. Such
testing guarantees that the drives you purchase from us will be as reliable
as one could hope for. Period.
:Thanks in advance
:
: DJ.
:Paul Ockenden Philips Radiotheapy Systems, Crawley, UK +44 293 28787 x 4349
: UUCP - uunet!mcvax!ukc!prlhp1!ockenden JANET - ockenden%prlhp1 at uk.ac.Ukc
: Opions (where expressed), are those of Paul Ockenden the individual, NOT
: Paul Ockenden the Philips Employee !!
You're welcome!
+------------------------------------------------------------------+
|Sam Vause, NCR Corporation, Customer Services - TOWER Support |
|3325 Platt Springs Road, West Columbia, SC 29169 (803) 791-6953 |
| ...!ucbvax!sdcsvax!ncr-sd!ncrcae!cs-col!vause |
+------------------------------------------------------------------+
-----------------------------
From: Keith Bostic <keith at seismo.css.gov>
Subject: Request for user-contributed software
Date: 22 Jul 88 16:50:36 GMT
Keywords: 4BSD, user-contributed
To: unix-wizards at SEM.BRL.MIL
BSD will be starting a new cycle of software development this summer. As
most of you know, much of the software made available through Berkeley was
contributed by the user community. We wish to continue this tradition and
encourage anyone who is interested in contributing software to the user
community to contact us. We also have many projects, ranging in difficulty
from weekend hacks to master's or doctorate level work, that we do not have
time to do ourselves.
Possible projects include:
autodialer manager/daemon
biff(1) replacement (mail notification)
conferencing system
csh cleanups and the addition of ksh features, particularly
functions and command line editing
System V compatible cron(8) and at(1) programs
documentation browsing system
multi-buffered tape driver
multiuser, message-based application scheduler
public-domain NFS
replacement of current various current utilities with
public domain source code
make(1) replacement
We would appreciate being contacted by anyone interested working on these,
or any other, projects.
Keith Bostic
415-642-4948
uunet!keith
bostic at okeeffe.berkeley.edu
-----------------------------
From: "Brandon S. Allbery" <allbery at ncoast.uucp>
Subject: Re: Input Line Editing
Date: 22 Jul 88 23:18:33 GMT
Followup-To: comp.unix.wizards
To: unix-wizards at brl-sem.arpa
As quoted from <9666 at eddie.MIT.EDU> by nessus at wonko.MIT.EDU (Doug Alan):
+---------------
| In article <16456 at brl-adm.ARPA> rbj at nav.icst.nbs.gov (Root Boy Jim) writes:
| > I suspect that the real place for line editing is either in the shell
| > itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel.
|
| Putting line editing in the shell is wrong, because it should work in
| all programs and be consistent. Putting it in the kernal is gross.
| Thus, the right place to put it is precisely where Bob Pendleton wants
| to put it -- in a process which gets input from the user and feeds
| edited input to the user's other programs. If needed, mods to the
| kernal and convention, however, should be made to make this as easy
| and efficient as possible.
+---------------
??? Why not just a modified version of gets()? If you're running under
SVR3, you can build a new version of the shlib with the new gets() and
thereby upgrade every program on the system without recompiling!
(NOTE: [1] Using scanf() to do terminal input provides insufficient
protection from erroneous input and insufficient user-friendliness;
using a loop of getchar()'s is a bit weird. I always use gets(),
so all my programs would work first time. Other programs? Dunno,
depends on how crazy the programmers were.
[2] It would, of course, distinguish between a terminal and a
non-terminal (heck, stdio does this now), so gets() used in a filter
wouldn't fry sort's (for example) little mind.)
I may actually try this, after backing up my system: if it goes wrong I can
boot from the floppy and full-restore. . . .
++Brandon
--
Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY
For comp.sources.misc send mail to ncoast!sources-misc
-----------------------------
From: Bob Pendleton <bpendlet at esunix.uucp>
Subject: Re: Input Line Editing
Date: 21 Jul 88 15:02:27 GMT
To: unix-wizards at SEM.BRL.MIL
>From article <1112 at ficc.UUCP>, by peter at ficc.UUCP (Peter da Silva):
> In article <9677 at eddie.MIT.EDU>, nessus at wonko.MIT.EDU (Doug Alan) writes:
>> There is another way to guarantee that line editing will be uniformly
>> supported. (1) Provide an alternate, and better method. (See my and
>> some other's previous articles on the issue). (2) Remove line editing
>> completely from the kernal, forcing everyone to use the better method.
>
> ... Six context switches, at the minimum.
> Plus you execute in user mode. if your program requires swapping or paging
> to wake up, it's even worse.
>
> Not only that, but all your programs now have to check to see if they're
> in a pipeline and turn this stuff off when they are.
>
> this isn't that much compared to what you Athena jockeys already do, but
> it'll kill us poor folks with "mere" vax-class machines and terminals, shared
> among a dozen users. Interactive response time will go to hell.
> --
> Peter da Silva
What Peter says is true. BUT, it is not a reason to stop looking for
better ways to do things, or for opposing changes that would make
using separate input line editing processes easier. The way things
change in this business, by the time all the details are worked out
the performance/price ratio will have increased by another factor of
2. Some people will still be stuck on ancient, oeverloaded systems,
bot most won't.
I use ile every day on a Sun 3/50 and an ULTRIX VAX-750. Sometimes its
too slow on the 750. I don't notice it on a the Sun.
Bob P.
--
Bob Pendleton @ Evans & Sutherland
UUCP Address: {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet
Alternate: utah-cs!esunix!bpendlet
I am solely responsible for what I say.
-----------------------------
End of UNIX-WIZARDS Digest
**************************
-----------------------------
From: Greg Hackney <hack at bellboy.uucp>
Subject: Re: Cheaper winnies on an NCR tower
Date: 25 Jul 88 18:51:30 GMT
Keywords: NCR
To: unix-wizards at brl-sem.arpa
In article <531 at prlhp1.prl.philips.co.uk> ockenden at prlhp1.UUCP writes:
>NCR Drives : A Plea for help.
>Does anyone know how to install a non-NCR drive into a 32/600 without
>waking up at night cold and sweating.
It's my understanding that the Radiology Dept. at Michigan
State University has Tower 32-600s running with CDC-9766
drives and Xylogics 450 disk controllers.
I wouldn't recommend your trying to do it yourself though,
let a vendor do it, at no cost to you if it doesn't work out.
I got a bid from NCR for a big drive, and you are correct in
that they are proud of them. Priced theirselves right out of
that sale, and out of my desire to try to grow the machine, thus,
putting the project on another vendors machine.
--
Greg
-----------------------------
From: Joe Bob Willie <haugj at pigs.uucp>
Subject: Re: Cheaper winnies on an NCR tower
Date: 25 Jul 88 15:36:58 GMT
Keywords: NCR TOWER 32/600 drive
To: unix-wizards at brl-sem.arpa
In article <105 at cs-col.Columbia.NCR.COM> Sam Vause writes:
>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.
Nonsense, the purpose of NCR is to make money. The typical manufacturers
markup on disk drives and peripherals is near 100 percent. A certain
nameless manufacturer I worked for sold parallel boards, which cost $25
to manufacture, for $600 because the serial boards, which cost about $100
to manufacture were being sold for $600. Disk drives were a completely
different issue. Maxtor drives were priced about 100 percent above cost.
When we started shipping RLL2,7 Adaptek controllers in the machines they
marked up the drive prices at the same time they marked up the formatted
capacity, even after they marked up the cost of the disk controller!!!
>:PS. These drives would have to take a hammering.....
>
>Don't they all--that's one of the advantages of purchasing one from us--we've
>completed as much stress testing and evaluation as humanly possible. Such
>testing guarantees that the drives you purchase from us will be as reliable
>as one could hope for. Period.
NCR is not a drive manufacturer. To claim to conduct more testing that
Maxtor or Miniscribe or NEC or Fuji is pure marketing hype. The 286MB
NEC's in our P/95 are no less reliable than the 27?MB Fuji in the P/55.
Both have proved to be highly reliable drives. Both take quite a pounding
and I don't believe either cost what NCR is selling 140MB drives for.
To be certain, VAT is a big chunk of any machine being sold in Europe,
but the damned exchange rate is more favorable for Europeans than it
has been in the past. Blaming the high cost of a machine on a more
favorable exchange rate is folly!
I'm not certain how restraint of trade laws work, but this smells like
an area where they might apply.
- John.
--
jfh at rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers)
"Never attribute to malice what is adequately explained by stupidity"
-- Hanlon's Razor
-----------------------------
From: Jim Meritt <jwm at stdc.jhuapl.edu>
Subject: Re: Root shell in shell scripts, HELP?
Date: 25 Jul 88 23:34:36 GMT
Sender: news at aplcomm.jhuapl.edu
To: unix-wizards at SEM.BRL.MIL
WIZARD DISCLAIMER: not me, man. just a little trick I have run across...
In article <334 at marob.MASA.COM> daveh at marob.UUCP (Dave Hammond) writes:
}In article <833 at lsrhs.UUCP> led at lsrhs.UUCP (Jay Jungalwala) writes:
}> Well see what I am looking for is a program (useing shell schripts)
} ^^^^^^^^^ ^^^^^^ ^^^^^^^^
} Well, see, using scripts
}>to make a root shell useing csh but haveing it set uid to root, but it can
} ^^^^^^ ^^^^^^^
} using having
}>be run by non-root people. See I need this, because I am writeing a exam
} ^^^^^^^^^^
} writing an
}>(computer) and I need a root shell in the exam. And this will be executible
} ^^^^^^^^^^
} executeable
}>by everyone, but csh for some reason likes (I think) to do a getlogin(), then
}>a getuid() I on the getlogin(). So is there a way around this, or it can
}>also be a program (C) that will do it.
}> Well if you need more info on what I am talking about here is my
}>mailing address:
}> led%lsrhs at mit-caf.uucp [Last I checked this worked]
}>And I will give you all the information that I can.
}
}I am having so much fun correcting the grammar that to answer the question
}seems almost superfluous. Besides, I can't seem to make heads or tails of
}what JJ is really trying to say :-). However, as a stab-in-the-dark, I would
}say he's looking for 'su'. No?
try
:!spell % | more
Disclaimer: Individuals have opinions, organizations have policy.
Therefore, these opinions are mine and not any organizations!
Q.E.D.
jwm at aplvax.jhuapl.edu 128.244.65.5 (James W. Meritt)
-----------------------------
From: "Carl S. Gutekunst" <csg at pyramid.pyramid.com>
Subject: Re: Cheaper winnies on an NCR tower
Date: 25 Jul 88 23:52:30 GMT
Followup-To: comp.periphs
To: unix-wizards at SEM.BRL.MIL
In article <201 at pigs.UUCP> haugj at pigs.UUCP (Joe Bob Willie) writes:
>Nonsense, the purpose of NCR is to make money. The typical manufacturer's
>markup on disk drives and peripherals is near 100 percent.
Try 200 percent, relative to OEM cost. You'll find even greater markups on
items the vendor has a lock on, e.g., memory boards for a proprietary bus.
A vendor's justifications run something like this:
- It costs the vendor something to physically pass the drive through. There
are the handling costs associated with receiving, inventory, and shipping.
This definitely justifies *some* markup above OEM cost.
- Vendors perform drive *systems* tests, that is, the drive installed in the
system, running the vendor's software. The drive manufacturer obviously does
not do this, and certainly a distributor does not.
In the case of NCR, they *do* perform more rigorous drive tests than the
drive manufacturers do themselves.
- A peripheral provided by the vendor will be covered by your maintenance
contract. So you are paying the costs associated with the vendor educating
its field staff on how to service that drive.
This argument is actually more specious than most, since (1) you should be
paying for the cost of maintenance entirely in the maintenance contract, and
(2) most vendors don't actually service disk drives, they just replace them.
But there are various competitive reasons for a vendor to shift costs from
field service to purchase price.
- Vendors are in the business of making money (obviously), so they will charge
the highest price they can and remain competitive. Systems vendors generally
do not consider themselves as competing with drive vendors, since they know
(correctly) that the majority of their customers are not capable of instal-
ling a disk drive. So they set prices not on what the drive vendors charge,
but on what other systems vendors charge.
This is a game that changes with time. Pyramid was competing with DEC back
in 1984, so Pyramid's prices for Fujistu Eagles were set to compete against
DEC's RA-81. Now Pyramid also competes with Sequent, Gould, CCI, and others,
so the price is chosen to be competitve with *them.*
- There are competitive reasons for shifting costs from the CPU to the periph-
erals. On *systems* bids, this makes no difference. But many competitve bids
don't include peripherals. (Bright lads up there in Washington.) So the ven-
dor has good reason to decrease the CPU cost to below where it makes a
profit, and make up the difference in peripherals.
In summary, the vendor is selling you security -- here is a drive that works,
you don't have to worry about it. If it breaks, we'll fix it; you don't have
to gamble. And generally the vendor wins -- most customers *are* willing to
pay a significant premium for a drive that the vendor assures them will work.
I am much more sympathetic towards vendors that allow you to add your own
peripherals, and allow you to take your own risks, even if they overcharge for
the peripherals they sell. I *believe* Pyramid's policy is that you must buy
at least one drive from them, so that there will be at least one known good
drive on the system (for maintenance purposes). Additional drives you can add
yourself, and many customers do. The aftermarket for DEC-compatible periphe-
rals is legendary, and I am aware of a number of Sequent and Sun customers who
have added their own drives. I have also added my own drives to the NCR Tower,
although I was working for NCR at the time. :-)
Disclaimer: I am speaking only for myself, obviously.
<csg>
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list