Unix-Wizards-Request@BRL.ARPA (The Moderator) (12/14/87)
UNIX-WIZARDS Digest Sun, 13 Dec 1987 V4#099
Today's Topics:
Re: ditroff device description trouble
Re: Summary of Emacs csh alias replies
Re: /dev/swap - possibility of it being a ramdisk
Re: Is process <n> alive?
Re: Wait, Select, and a SIGCHLD Race Condition
Re: History lesson
Re: BSD at AT&T
a ksh script for safe removal
Re: login prompt not staying set
Re: `rm -rf dir' fails with Directory not empty
Re: ACCESS TO SHARED TAPEDRIVES
Re: login prompt not staying set
Re: AT&T attitude to educational source
Re: globbing in the shell (Was Re: more rm insanity)
Re: /dev/swap - possibility of it being a ramdisk
Re: a ksh script for safe removal
Re: more rm insanity
Re: spell
signal handling,c-shell,hp840
-----------------------------------------------------------------
From: Jay Plett <jay@unm-la.uucp>
Subject: Re: ditroff device description trouble
Date: 12 Dec 87 06:50:58 GMT
Keywords: ditroff typesetting DESC
To: unix-wizards@SEM.BRL.MIL
In article <209@theceg.UUCP>, lkb@theceg.UUCP (Lawrence Keith Blische) writes:
> .......................... I've setup a DESC file and font description
> files for each font (R I B IB PE C CW) ...................................
>
> test: .ft 2
> Italic
>
> #troff -TP351 test >foo
> troff: Can't open /usr/lib/font/devP351/2.out
Your problem is that you MUST have a "special" font mounted.
This font will be identified in the F.out file by a value of
1 in the "specfont" field of the Font struct. It must be
the last font listed in the DESC file (you can have more than
one special font but remember that any fonts named after the first
special font in DESC will be treated as special). I haven't
tried this, but suspect that - if you don't want or need a
special font - you could create a dummy one that contains only
a single ascii character.
When ditroff reads DESC.out, it sets a var "smnt" to the mount
position of the first special font it finds. Then, when you do
a font change, it tests that you aren't trying to change to a
special font (i < smnt). If no special font was encountered
while reading DESC.out, smnt will be 0, so font 2 (or any other
number) will fail the test. Ditroff forgets that it thought it
detected an error, recognizing only that it didn't find font 2,
so it then tries to find a mounted font named "2", fails, and
finally tries to mount font "2" on position 0. It is only at
this point that it tries to read "2.out" and complains. I would
call this behavior a bug.
--
Jay Plett
UUCP: {cmcl2,ihnp4}!lanl!unm-la!jay
{ucbvax,gatech}!unmvax!unm-la!jay
ARPA: jxyp@lanl.gov
-----------------------------
From: "Barton E. Schaefer" <schaefer@ogcvax.uucp>
Subject: Re: Summary of Emacs csh alias replies
Date: 10 Dec 87 18:07:53 GMT
Posted: Thu Dec 10 10:07:53 1987
To: unix-wizards@SEM.BRL.MIL
In article <brl-adm.10750> dsill@NSWC-OAS.arpa (Dave Sill) writes:
}My question was: how can one set up a csh alias for emacs that will
}run emacs if there isn't one in the background or foreground it if it
}is in the background.
}
}Most "solutions" involved grepping the output of jobs to determine if
}there was a background emacs job, followed by an if-then-else to
}either run or foreground emacs. I've never been able to get an
}if-then-else to work in an alias. Some suggested putting the if-then-
}else in a file to be sourced by the alias. This works, but requires
}reading the file each time the alias is invoked, so I might as well
}use a script.
"Might as well use a script" ?!?!?
For something as short as the 6 or 7 lines in the file in question, the
major part of the overhead is NOT in reading the file, but in fork-execing a
new shell which then has to read the file anyway. Sourcing the file from the
current shell will be MUCH faster than running a script.
Furthermore, what do you think is going to happen when you issue a "%emacs"
in the script? There isn't any background job running under the script shell!
This is one case where you MUST use "source", or type the commands in yourself
(which you don't want to do or you wouldn't have asked the question in the
first place).
--
Bart Schaefer CSNET: schaefer@cse.ogc.edu
UUCP: ...{tektronix,verdix}!ogcvax!schaefer
"A band of BIG, DUMB, LOUDMOUTHED, BUNGLING OGRES is a GREAT ASSET to the
neighbohood. It keeps out the RIFF-RAFF." -- Wormy
-----------------------------
From: " Dr. Robin Lake " <rbl@nitrex.uucp>
Subject: Re: /dev/swap - possibility of it being a ramdisk
Date: 11 Dec 87 20:20:35 GMT
To: unix-wizards@SEM.BRL.MIL
In article <712@qetzal.UUCP> rcw@qetzal.UUCP (Robert C. White) writes:
>Hello Wizards,
>
>Watching my poor little unix boxes swap, it occurred to me:
>why not utilize some extra ram to implement /dev/swap? It seems that
>the machine would speed up quite a bit, and hey, extra memory
>is pretty inexpensive, at least for the smaller
>unix boxes. Also, it would be tactically easier to
>increase the amount of "swap" memory as opposed to repartitioning
>my disks, or mounting a disk pack under /tmp or some other
>horrid kludge.
About 10 years ago, I was involved with the design of a "solid-state disk"
--- a ram disk that looked like a fixed-head disk for PDP-11 Unibus
machines. A graduate student of mine did his Ph.D. dissertation on the
performance of UNIX with such a box. (Sugit Kumar, Case Western Reserve
University). Bottom line was that you want TWO such "ramdisks", one for
/tmp or /usr/tmp and one for the commonly used programs (/bin, /usr/bin).
The only shortcoming is that the device drivers and the I/O strategies of
the kernel consume relatively huge amounts of time per "disk" access. The
result is that a solid-state device (17,000 times faster transfer rate
than a rotating disk) only performs 10 to 50 times better.
Nonetheless, watch for significant new computer architectures from the 3-letter
computer vendors which take advantage of more ram memory than you might have
ever believed would fit in a box! Exciting times ahead....
Rob Lake
BP America R&D
(ex-Principal Scientist, Monolithic Systems Corp - mfgr. of "Extended
Memory Unit" )
decvax!mandrill!nitrex!rbl
216-581-5976
--
Rob Lake
{decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl
-----------------------------
From: rjd@occrsh.ATT.COM
Subject: Re: Is process <n> alive?
Date: 11 Dec 87 18:22:00 GMT
Nf-ID: #R:csd_v.UUCP:-14100:occrsh.ATT.COM:142700019:000:833
Nf-From: occrsh.ATT.COM!rjd Dec 11 12:22:00 1987
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?
>
> 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.
I don't have the base note for this, just the above. If you have the
process number (such as saving it when it went into background) either
(in shell) a ps -p <process number> will give you a status code, or
(in C) kill(0,<processnumber>) will also give you a status code.
If you don't have a process number, it gets a little more difficult.
Randy
-----------------------------
From: Wen-King Su <wen-king@vlsi.caltech.edu>
Subject: Re: Wait, Select, and a SIGCHLD Race Condition
Date: 12 Dec 87 15:59:15 GMT
Sender: news@csvax.caltech.edu
To: unix-wizards@brl-sem.arpa
In article <496@PT.CS.CMU.EDU> rpd@F.GP.CS.CMU.EDU (Richard Draves) writes:
<> 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
OOPS, you are right. How about this:
on SIGCHLD interrupt, set time_struct = ZERO_TIMER;
...
numfds = select(...,&time_struct);
It should cover all possibilities. I knew there is a way, I just
couldn't remember all the details.
/*------------------------------------------------------------------------*\
| Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers |
\*------------------------------------------------------------------------*/
-----------------------------
From: "Ian! D. Allen" <idallen@watcgl.waterloo.EDU>
Subject: Re: History lesson
Date: 8 Dec 87 01:32:33 GMT
To: unix-wizards@brl-sem.arpa
Yes, the Software Development Group at the University of Waterloo still
develops and distributes the B Language Programming environment for
Honeywell computers. They're also finishing off an ANSI C compiler and
support tools for C on Honeywell machines. Contact watmath!watbun!pjfraser
for details.
--
-IAN! (Ian! D. Allen) University of Waterloo
-----------------------------
From: Eduardo Krell <ekrell@hector.uucp>
Subject: Re: BSD at AT&T
Date: 12 Dec 87 20:13:37 GMT
Sender: daemon@ulysses.homer.nj.att.COM
To: unix-wizards@brl-sem.arpa
In article <8170@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes:
>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.
It's not that dictatorial. Witness the current standarization efforts AT&T
is involved in (with Microsoft on Xenix/System V, with Sun on a SPARC standard,
POSIX, etc).
>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.
That's exactly what I'm doing. All the kernel work I do is on System V
Release 3.x machines. I'm quite satisfied with the changes we've made
(otherwise I wouldn't be using it). Whether we can convince the powers
to be to include these changes in the official System V distribution
is a completely different problem.
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrell
-----------------------------
From: "Lawrence V. Cipriani" <lvc@tut.cis.ohio-state.EDU>
Subject: a ksh script for safe removal
Date: 12 Dec 87 19:02:30 GMT
Keywords: globbing
To: unix-wizards@SEM.BRL.MIL
Here is a Korn shell function I wrote for safe file removal.
I suppose it can be done is csh too.
If the arguments are wildcards it asks if you really want to
remove the files. Type in y to proceed. A delete or any non-y
character to not do it.
Now can we stop debating about globbing in the shell please.
-------------------------------cut here-------------------------
# This function checks if the arguments to it contain shell
# wildcards. If so, it asks the user if they really want to
# proceed to remove their files named. If there are not wild
# cards it just proceeds to remove them.
function callitwhatyouwant
{
set -o noglob
x='echo eval $*'
set +o noglob
y=$*
if [ "$x" != "$y" ]
then
echo really: $y
read response
fi
if [ "y${response#y}" = "${response}" ]
then
/bin/rm $y
fi
}
------------------------------cut here--------------------------
--
Larry Cipriani AT&T Network Systems at
cbosgd!osu-cis!tut!lvc Ohio State University
-----------------------------
From: Dave Cornutt <dcornutt@murphy.uucp>
Subject: Re: login prompt not staying set
Date: 10 Dec 87 14:09:26 GMT
To: unix-wizards@SEM.BRL.MIL
In article <142700007@occrsh.ATT.COM>, rjd@occrsh.ATT.COM writes:
>
> > > (Lots of stuff concerning the getty - login sequence)
> >
> > Believe me, Im a novice at this. But it occurred to me . . .
> >
> > Does it make sense for login, after an invalid password, to exec getty
> > rather than issue its own login: prompt? This would eliminate the two
> > login: prompts (surely a goodness), but would it tie login too closely
> > to getty?
You run into a problem with modems. If login exits, it has to close the
tty fd so that getty can re-open it. This will cause modems to hang up.
I suppose getty could be modified to take an arg telling it not to open
the tty; instead, just use the fd that is already open. But there must
be a better way...
> Sounds good to me, especially for the guy who asked the original question...
> To actually implement would be slightly harder, as getty expects the gettydefs
> line to get the parameters to set the port to, which the login program does not
> know. Maybe change both login and getty to check another file for the login
> prompt and keep the sequence the same, or have just login only prompt for it
> (which I see problems with), or........ EDUCATE the users to not be bothered
> by it......Na, thats too easy...
EDUCATE THE USERS?? Heaven forbid! What's wrong with your telepathy
hardware? :-) :-) :-)
Seriously, it doesn't really make sense that getty should do one thing
when issuing the prompt and login do another. Actually, it doesn't make
sense (at least to me) that the functions of getty and login are split
among two programs. I think they should be merged into one program.
What kinds of problems would this cause? Right off hand, I can't think
of any, but others may know better. Comments?
---
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP: ...!{sun,pur-ee,brl-bmd,uunet,bcopen,rb-dc1}!gould!dcornutt
or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcornutt@gswd-vms.arpa
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."
-----------------------------
From: "Dennis L. Mumaugh" <dlm@cuuxb.ATT.COM>
Subject: Re: `rm -rf dir' fails with Directory not empty
Date: 10 Dec 87 15:49:33 GMT
To: unix-wizards@brl-sem.arpa
In article <125@Edvax.UUCP> edward@comp.vuw.ac.nz (Edward Wilkinson) writes:
>Sometimes, when I do a `rm -rf dir', every so often rm complains about
>a `directory not empty' error somewhere down the hierarchy. This
>propagates to the higher levels & leaves an empty directory structure
>behind. Another `rm -rf dir' results in the same, even when executed
>as super-user. I once tried using unlink(2) with less than best
>results: as me, it didn't work, while as superuser, the following fsck
>fell over. We then had to do a restore, which left us with the dud
>`empty' directory again.
>
>Does anyone know what I'm doing wrong? We run Ultrix 1.2 on a Vax 750
>if it's any use. Any ideas would be most gratefully received.
>
I haven't seen any response posted and since this is from Down Under
the person may not get any other answer so here goes:
One of the more nasty habits of programs is to use a so-called
dot file. This is a file beginning with a period. The purpose
of these files is to save information and at the same time
suppress any evidence of their existence. This is because of the
fact there are ALWAYS (or almost always) two such files in any
directory ("." and ".."). To avoid always see those files with
an ls command and using their name in a global (as in rm *) the
software in the shell and ls ignore all file names beginning with
period. (Ls -la will change this).
The problem with the dot files is that when it comes time to
remove the directory (with rmdir or rm -rf) it appears the
irectory is empty but it really isn't and thus the program balks.
Solution:
cd to the directory that can't be removed and do an
ls -la
You ought to see some files. Then do a
rm -f .*
This is okay since rm won't remove directories. Then continue as
previously.
Why does rm -rf bitch? Because it does a fork and then execs the
command rm -rf * (which won't pick up the dot files). After
which it will do an rmdir * (to cleanup the sub-directories).
--
=Dennis L. Mumaugh
Lisle, IL ...!{attunix,ihnp4,cbosgd,lll-crg}!cuuxb!dlm
-----------------------------
From: Brandon Allbery <allbery@ncoast.uucp>
Subject: Re: ACCESS TO SHARED TAPEDRIVES
Date: 9 Dec 87 23:45:54 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <6802@brl-smoke.ARPA> by gwyn@brl-smoke.ARPA (Doug Gwyn ):
+---------------
| I think a talk and perhaps BOF session would be valuable; UNIX has
| needed some facility like this for ages and it would be good to have
| one (and ONLY one, which must therefore be well-designed) available
| as a standard part of the product. There are a lot of uses for it
| even in a single-user environment.
+---------------
I hate to say this, but the Xenix V/386 machine at work already has such
a facility, and as far as I can tell it will work over the manufacturer's
proprietary network file system as well.
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
-----------------------------
From: Brandon Allbery <allbery@ncoast.uucp>
Subject: Re: login prompt not staying set
Date: 10 Dec 87 00:01:04 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <16848@topaz.rutgers.edu> by ron@topaz.rutgers.edu (Ron Natalie):
+---------------
| No, it would be far better if getty didn't attempt to pretend
| it was login at all. However, it likes to do so so it can do
| things like autobauding and trying to guess what you want for
| terminal modes.
+---------------
So why can't getty print "Press RETURN" until it gets a recognizeable
RETURN with a 1 second gap around it, then exec login with no arguments?
This could be implemented now by changing only getty source (see uutty
for one such PD source); "login" will work right without arguments. Then
change "login" to look for a prompt in a control file of some kind.
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
-----------------------------
From: Brandon Allbery <allbery@ncoast.uucp>
Subject: Re: AT&T attitude to educational source
Date: 10 Dec 87 23:16:08 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <4651@well.UUCP> by wolf@well.UUCP (Dwight Leu):
+---------------
| "Will your XENIX application run next year when Microsoft drops XENIX and
| switches to UNIX? Not even Microsoft guarantees it.
+---------------
...but why would anyone run Unix/Xenix on a machine designed for MS-DOS?
(If you can make comments, so can I....) [I know of at least one Xenix ->
Unix change that *is* guaranteed portable. Sorry, folks.]
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
-----------------------------
From: Phil Smith <allbery@ncoast.uucp>
Subject: Re: globbing in the shell (Was Re: more rm insanity)
Date: 10 Dec 87 23:34:58 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <1975@bloom-beacon.MIT.EDU> by wesommer@athena.mit.edu (William Sommerfeld):
+---------------
| In article <6356@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:
| >In article <12441@think.UUCP> by barmar@think.COM (Barry Margolin) writes:
| >So, how many times have you abbreviated a filename which you know is unique
| >with a well-placed "*"?
| Rarely; it all depends on what you are used to. On unix, using tcsh,
| I hit 'TAB', and have the shell or emacs complete the filename for me.
+---------------
"On unix"?! We run Unix on ncoast. No tcsh, no GNU Emacs (won't fit).
AT&T UNIX System III is just as much Unix as 4BSD is... so I cope. The
use of wildcards is the *only* way to do it here; that, or type the full
pathname (even with only 14 characters max. per component, this can be
painful).
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
-----------------------------
From: Brandon Allbery <allbery@ncoast.uucp>
Subject: Re: /dev/swap - possibility of it being a ramdisk
Date: 11 Dec 87 17:39:34 GMT
Followup-To: comp.unix.wizards
To: unix-wizards@brl-sem.arpa
As quoted from <4821@spool.wisc.edu> by dave@spool.wisc.edu (Dave Cohrs):
+---------------
| In article <712@qetzal.UUCP> rcw@qetzal.UUCP (Robert C. White) writes:
| >Watching my poor little unix boxes swap, it occurred to me:
| >why not utilize some extra ram to implement /dev/swap?
|
| The idea is that when you add memory, you shouldn't *have* to swap. I
| know that when my workstation goes up to 10meg (oh where, oh where did
| that purchase order go?), I'm not going to be worrying about what kind
| of device implements /dev/swap, at least until I expand to using more
| than 10meg at the same time. Are there really brain-dead UNIX-like
| things out there that can't see all of memory?
+---------------
Tandy 16/6000 series can only address 1MB presently due to a brain-damaged
MMU (recent hardware mod, hopefully soon to be released, raises that to 4MB
at the expense of having larger memory segments); however, it's capable of
*physical* addressing 7MB. So the Wizard of TRS (aka Bob Snapp) sells a
6MB RAM board and ramdisk software for it....
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
-----------------------------
From: "Lawrence V. Cipriani" <lvc@tut.cis.ohio-state.EDU>
Subject: Re: a ksh script for safe removal
Date: 12 Dec 87 22:25:05 GMT
Keywords: globbing
To: unix-wizards@SEM.BRL.MIL
In article <3150@tut.cis.ohio-state.edu> I wrote:
> # This function checks if the arguments to it contain shell
> # wildcards. If so, it asks the user if they really want to
> # proceed to remove their files named. If there are not wild
> # cards it just proceeds to remove them.
>
[buggy function removed]
This doesn't work and can't work. The set -o noglob command inside
a function doesn't work the way I thought it would. The reason
I thought I had it right had to do with the "set"tings on my login
shell. Sigh.
--
Larry Cipriani AT&T Network Systems at
cbosgd!osu-cis!tut!lvc Ohio State University
-----------------------------
From: John Chambers <jc@minya.uucp>
Subject: Re: more rm insanity
Date: 12 Dec 87 14:28:41 GMT
To: unix-wizards@SEM.BRL.MIL
> Explain to a user, please, why the user can get a list of filenames beginning
> with "cel" by typing
> ls cel*
> ...but in order to get a list of adjacent network nodes beginning with "cel",
> using the hypothetical "netlist" command, the user must type
> netlist cel\*
> ...makes no sense to me.
Nor to me. Ane there are "network" Unix systems where it works. For example,
with the Newcastle Connection, you can find out about network nodes at the
same level as your system by typing:
ls /../*
Other wildcard expansions work similarly, because "/../" is implemented as
a normal directory. (It is actually a special file, of course, within which
is hidden the network.)
On a more general note, part of the problem is the widespread violation of
the object-oriented design of Unix. Objects are, of course, called "files",
and operators are called "processes". If you have a set of objects, you
make them a set by linking them into a directory. You can then use various
operators (such as ls or find or wildcard expansion) to extract subsets.
There is no reason that this can't be used for network nodes, as it can
be used for programs, directories, source files, object files, disk drives,
or anything else whose name can be entered in a directory.
Instead, most network implementations are kludges that violate this useful
design, usually by introducing some sort of special syntax for network nodes
(host:file, host!user, something@host, etc.) which the standard Unix library
programs don't understand, and which doesn't follow the model of a tree of
directories. Then we go through the process of "reinventing the wheel",
trying all sorts of ways to use a bad design, when we already had one that
works well.
It's really another case of Henry Spencer's .signature: Those who don't
understand Unix are re-inventing it, poorly. Eventually, people might
realize that networked systems, like multi-disk file systems, should
simply be combined in the same heirarchy that looks the same from any
vantage point. Anything else (like Sun's NFS) is simply an interim kludge
that interferes with effective applications of simple tools.
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
-----------------------------
From: George Leach <reggie@pdnbah.uucp>
Subject: Re: spell
Date: 11 Dec 87 13:32:01 GMT
Sender: usenet@pdn.uucp
To: unix-wizards@SEM.BRL.MIL
In article <501@srs.UUCP> dan@srs.UUCP (Dan Kegel) writes:
>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.
But that is counter to the UNIX philosophy of each tool performing a
simple task. Too many simple commands have taken on such bulk in terms of
added utility that they become too complex. Take for example cat (see the
discussion of why cat should have no options (as in v8 UNIX) by Kernighan
and Pike in "Program Design in the UNIX Environment", AT&T Bell Laboratories
Technical Journal, Oct. 1984, V. 63 N. 8 Part 2.
Spell does just what it says. It checks for misspelled words!!! That
is all! If you want to do other types of checking then you should be looking
at the other Writers Workbench (wwb) utilities, like diction(1), style(1) and
proofr(1). Being a former AT&T and Bellcore employee I have always had these
tools at my disposal on any machine I work with. I understand that these
utilities have been unbundled from the basic UNIX system and sold as a seperate
package (as is true with documentors workbench tools as well). This is a most
unfortunate situation. I think AT&T could better promote the acceptance of
UNIX in the marketplace by bundling these utilities along with the basic OS
software!!!
George W. Leach Paradyne Corporation
{gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207
Phone: (813) 530-2376 P.O. Box 2826
Largo, FL 34649-2826
-----------------------------
From: Eric Van Tassell <eric@eddie.MIT.EDU>
Subject: signal handling,c-shell,hp840
Date: 13 Dec 87 04:45:26 GMT
Posting-Front-End: GNU Emacs 18.41.3 of Wed Apr 15 1987 on eddie (berkeley-unix)
To: unix-wizards@SEM.BRL.MIL
Ok, c-shell/bsd-wizards I give up.
suppose you have a binary foo who does a signal(SIGINT,mysighndlr) and the
following script.
foo.csh:
foo
in other words foo.csh merely calls foo. Why does the parent c-shell catch
the ^C and terminate foo instead of letting mysighndlr handle it? How do I
enable my application to handle the signal? Please email. Oh yeah the system
involved is an HP9000/840 running HP-UX.
Thanks in advance!
eric@eddie.mit.edu
-----------------------------
End of UNIX-WIZARDS Digest
**************************allbery@ncoast.UUCP (Brandon Allbery) (12/19/87)
Is it me, or is BRL.ARPA sending out multiple copies of articles originating
locally? (Such as the one I'm "following up" to.)
--
Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc