postmaster@uunet.uu.net (06/18/88)
Reason: local mail handler complained as follows
jmail: HuwR -- unknown user or mailbox
-------- rejected letter ---------
Via: 00004001015218/UCL-CS.FTP.MAIL ; 18 Jun 1988 02:35:06 GMT
Received: from NSS.CS.UCL.AC.UK by NSS.Cs.Ucl.AC.UK via List-Channel
id ab00958; 18 Jun 88 2:53 BST
Received: from sem.brl.mil by NSS.Cs.Ucl.AC.UK via Satnet with SMTP
id aa00917; 18 Jun 88 2:42 BST
Received: from SEM.BRL.MIL by SEM.BRL.ARPA id aa00152; 16 Jun 88 2:58 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa29983; 16 Jun 88 2:45 EDT
Date: Thu, 16 Jun 88 02:45:22 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request@arpa.brl>
To: UNIX-WIZARDS@arpa.brl
Reply-To: UNIX-WIZARDS@arpa.brl
Subject: UNIX-WIZARDS Digest V5#070
Message-ID: <8806160245.aa29983@SEM.BRL.ARPA>
Sender: unix-wizards-request@uk.ac.ucl.cs.nss
UNIX-WIZARDS Digest Thu, 16 Jun 1988 V5#070
Today's Topics:
Re: 4.2bsd memall mfind crash
echo -[ne] and escapes
Re: grep replacement (backref in egrep ?? whoa!)
Re: Tool -flag considered harmful
Re: What do panic messages mean?
Re: back to the (ivory) tower
Re: alloca... (and setjmp/longjmp coroutines)
Re: POSIX Draft for UNIX
Re: lp/lpr interface
Re: grep replacement
Re: Context diffs in diff (was grep replacement)
do we need (or want) context in grep and diff?
Re: grep replacement
Re: lp/lpr interface
Re: Tool -flag considered harmful (was: grep replacement)
Re: Implementation of alloca() and friends
Re: ksh incompatabilities with sh?
Re: yacc and lex tutorials
*USING* systems from DEC/IBM/HP
Re: grep on *.o
Re: grep replacement
Re: redirection before wildcards
Re: 4.2bsd memall mfind crash
-----------------------------------------------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: Re: 4.2bsd memall mfind crash
Date: 15 Jun 88 09:00:02 GMT
To: unix-wizards@SEM.BRL.MIL
In article <339@algol.spp2.UUCP> urban@spp2.UUCP (Michael Urban) writes:
>We have recently added some additional disk drives to a Vax 11/780
>running 4.2bsd (yeah, I know, I know). We have since been crashing
>on a "memall mfind" panic about once a day. At first I thought the
>problem was that we were mounting 17 file systems with NMOUNT set to
>only 15, but increasing NMOUNT to 20 failed to alleviate the problem.
Did you also change cmap.h, and then (as that necessitates) locore.s?
>I note that the clause in memall that is producing the crash is a
>patch that was added (four years ago!) to alleviate another panic, the
>vaguely remembered MUNHASH bug.
That was a workaround for a compiler bug.
>Does anyone know what the problem is here, and how to fix it?
Switch to 4.3BSD.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: echo -[ne] and escapes
Date: 15 Jun 88 11:50:07 GMT
To: unix-wizards@SEM.BRL.MIL
In article <8093@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>What I have suggested is that ALL echo commands be given both -n support
>(for V7/BSD compatibility) and -e support a la V8/V9. That would provide
>a migration path for shell scripts and allow reasonable default behavior
>for some future merged version of "echo" instead of escape mapping a la
>SysV.
What does POSIX say about echo?
As for myself, I use the `printf' command to get formatted/escaped
strings.
What, you say you have no printf command?
This one is largely compatible with the dpANS, although it relies on
the library printf to do the real work; if the library printf
misbehaves, so does this one. It does not implement the (in my opinion
ill-advised) %n formats, nor for the obvious reason the %p format, nor
does it handle %L[eEfgG] and |long double|s, but it does correctly
handle %ld and %hd formats, which our previous printf command did not.
I also replaced Fred's simple and obvious Roman numeral algorithm with
a shorter, more devious one due to Knuth. Deciphering it is left as an
exercise :-) .
Note that we added one backslash convention not in the dpANS, since
string concatenation is not available.
Incidentally, while this version of printf handles more formats, it
is shorter than the old one, and actually compiles to less code.
: Run this shell script with "sh" not "csh"
PATH=/bin:/usr/bin:/usr/ucb:/etc:$PATH
export PATH
all=FALSE
if [ x$1 = x-a ]; then
all=TRUE
fi
echo Extracting printf.c
sed 's/^X//' <<'//go.sysin dd *' >printf.c
X#ifndef lint
Xstatic char rcsid[]= "$Header: printf.c,v 2.2 88/06/15 07:29:48 chris Exp $";
X#endif
X
X/*
X * printf - duplicate the C library routine of the same name, but from
X * the shell command level.
X *
X * This version by Chris Torek, based on an earlier version by Fred Blonder.
X */
X
X#include <stdio.h>
X#include <ctype.h>
X#include <sysexits.h>
X
Xchar *progname;
X
Xchar *ctor(), **doit(), *index();
Xdouble atof();
Xint atoi();
Xlong atol();
X
Xmain(argc, argv)
X int argc;
X char **argv;
X{
X register char *cp, *convp, **ap, **ep;
X register int ch, ndyn, flags;
X char cbuf[BUFSIZ]; /* separates each conversion */
X static char hasmod[] = "has integer length modifier";
X
X /* flags */
X#define LONG 1
X#define SHORT 2
X
X ap = argv;
X ep = &ap[argc];
X progname = *ap++;
X if (argc < 2) {
X (void) fprintf(stderr,
X "%s: Usage: %s <format-string> [ arg1 . . . ]\n",
X progname, progname);
X exit(EX_USAGE);
X }
X
X ctrl(cp = *ap++); /* backslash interpretation of fmt string */
X
X /*
X * Scan format string for conversion specifications.
X * (The labels would be loops, but then everything falls
X * off the right.)
X */
Xscan:
X while ((ch = *cp++) != '%') {
X if (ch == 0)
X exit(EX_OK);
X (void) putchar(ch);
X }
X
X ndyn = 0;
X flags = 0;
X convp = cbuf;
X *convp++ = ch;
X
X /* scan for conversion character */
Xcvt:
X switch (ch = *cp++) {
X
X case '\0': /* unterminated conversion */
X exit(EX_OK);
X
X /* string or character format */
X case 'c': case 's':
X if (flags)
X illfmt(cbuf, convp, ch, hasmod);
X ap = doit(cbuf, convp, ap, ep, ndyn, ch, ch);
X goto scan;
X
X /* integer formats */
X case 'd': case 'i': case 'o': case 'u': case 'x': case 'X':
X if ((flags & (LONG|SHORT)) == (LONG|SHORT))
X illfmt(cbuf, convp, ch, "is both long and short");
X ap = doit(cbuf, convp, ap, ep, ndyn, ch,
X flags & LONG ? 'l' : flags & SHORT ? 'h' : 'i');
X goto scan;
X
X /* floating point formats */
X case 'e': case 'E': case 'f': case 'g': case 'G':
X if (flags)
X illfmt(cbuf, convp, ch, hasmod);
X ap = doit(cbuf, convp, ap, ep, ndyn, ch, 'f');
X goto scan;
X
X /* Roman (well, why not?) */
X case 'r': case 'R':
X if (flags)
X illfmt(cbuf, convp, ch, hasmod);
X ap = doit(cbuf, convp, ap, ep, ndyn, 's', ch);
X goto scan;
X
X case '%': /* boring */
X (void) putchar('%');
X goto scan;
X
X /* short integers */
X case 'h':
X flags |= SHORT;
X break;
X
X /* long integers */
X case 'l':
X flags |= LONG;
X break;
X
X /* field-width or precision specifier, or flag: keep scanning */
X case '.': case '#': case '-': case '+': case ' ':
X case '0': case '1': case '2': case '3': case '4':
X case '5': case '6': case '7': case '8': case '9':
X break;
X
X /* dynamic field width or precision: count it */
X case '*':
X ndyn++;
X break;
X
X default: /* something we cannot handle */
X if (isascii(ch) && isprint(ch))
X cbuf[0] = ch, cbuf[1] = 0;
X else
X (void) sprintf(cbuf, "\\%03o", (unsigned char)ch);
X (void) fprintf(stderr,
X "%s: illegal conversion character `%s'\n",
X progname, cbuf);
X exit(EX_USAGE);
X /* NOTREACHED */
X }
X
X /* 2 leaves room for ultimate conversion char and for \0 */
X if (convp >= &cbuf[sizeof(cbuf) - 2]) {
X (void) fprintf(stderr, "%s: conversion string too long\n",
X progname);
X exit(EX_USAGE);
X }
X *convp++ = ch;
X goto cvt;
X}
X
Xillfmt(cbuf, convp, ch, why)
X char *cbuf, *convp;
X int ch;
X char *why;
X{
X
X *convp++ = ch;
X *convp = 0;
X (void) fprintf(stderr, "%s: format `%s' illegal: %s\n",
X progname, cbuf, why);
X exit(EX_USAGE);
X}
X
X/*
X * Emit a conversion. cch holds the printf format character for
X * this conversion; cty holds a simplified version (all integer
X * conversions, e.g., are represented as 'i').
X */
Xchar **
Xdoit(cbuf, convp, ap, ep, ndyn, cch, cty)
X char *cbuf, *convp;
X register char **ap;
X char **ep;
X register int ndyn;
X int cch, cty;
X{
X register char *s;
X union { /* four basic conversion types */
X int i;
X long l;
X double d;
X char *str;
X } arg;
X int a1, a2; /* dynamic width and/or precision */
X
X /* finish off the conversion string */
X s = convp;
X *s++ = cch;
X *s = 0;
X s = cbuf;
X
X /* verify number of arguments */
X if (&ap[ndyn] >= ep) {
X (void) fprintf(stderr,
X "%s: not enough args for format `%s'\n",
X progname, s);
X exit(EX_USAGE);
X }
X
X /* pick up dynamic specifiers */
X if (ndyn) {
X a1 = atoi(*ap++);
X if (ndyn > 1)
X a2 = atoi(*ap++);
X if (ndyn > 2) {
X (void) fprintf(stderr,
X "%s: too many `*'s in `%s'\n",
X progname, s);
X exit(EX_USAGE);
X }
X }
X
X#define PRINTF(what) \
X if (ndyn == 0) \
X (void) printf(s, what); \
X else if (ndyn == 1) \
X (void) printf(s, a1, what); \
X else \
X (void) printf(s, a1, a2, what);
X
X /* emit the appropriate conversion */
X switch (cty) {
X
X /* string */
X case 's':
X ctrl(arg.str = *ap++);
X goto string;
X
X /* roman (much like string) */
X case 'r': case 'R':
X arg.str = ctor(atoi(*ap++), cty == 'R');
Xstring:
X PRINTF(arg.str);
X break;
X
X /* floating point */
X case 'f':
X arg.d = atof(*ap++);
X PRINTF(arg.d);
X break;
X
X /* character */
X case 'c':
X ctrl(*ap);
X arg.i = *(*ap++);
X goto integer;
X
X /* short integer */
X case 'h':
X arg.i = (short) atoi(*ap++);
X goto integer;
X
X /* integer */
X case 'i':
X arg.i = atoi(*ap++);
Xinteger:
X PRINTF(arg.i);
X break;
X
X /* long integer */
X case 'l':
X arg.l = atol(*ap++);
X PRINTF(arg.l);
X break;
X }
X return (ap);
X}
X
X/*
X * Convert backslash notation to control characters, in place.
X */
Xctrl(s)
X register char *s;
X{
X register char *op = s;
X register int v, c;
X char *p;
X static char oct[] = "01234567";
X static char hex[] = "0123456789abcdefABCDEF";
X
X while ((c = *s++) != 0) {
X if (c != '\\') {
X *op++ = c;
X continue;
X }
X switch (*s++) {
X case '\0': /* end-of-string: user goofed */
X s--;
X break;
X
X case '\\': /* backslash */
X *op++ = '\\';
X break;
X
X case 'n': /* newline */
X *op++ = '\n';
X break;
X
X case 't': /* horizontal tab */
X *op++ = '\t';
X break;
X
X case 'r': /* carriage-return */
X *op++ = '\r';
X break;
X
X case 'f': /* form-feed */
X *op++ = '\f';
X break;
X
X case 'b': /* backspace */
X *op++ = '\b';
X break;
X
X case 'v': /* vertical tab */
X *op++ = '\13';
X break;
X
X case 'a': /* WARNING! DANGER! DANGER! DANGER! */
X *op++ = '\7';
X break;
X
X case '0': case '1': case '2': case '3':
X case '4': case '5': case '6': case '7':
X s--;
X /* octal constant */
X c = 3, v = 0;
X while (--c >= 0 && index(oct, *s)) {
X v <<= 3;
X v += *s++ - '0';
X }
X *op++ = v;
X break;
X
X case 'x': /* hex constant */
X v = 0;
X while ((p = index(hex, *s)) != NULL) {
X if ((c = p - hex) >= 16)
X c -= 6;
X v <<= 4;
X v += c;
X s++;
X }
X *op++ = v;
X break;
X
X /*
X * The name of this object is taken from troff:
X * \z might be better, but this has a precedent.
X * It exists solely so that we can end a hex constant
X * which must be followed by a legal hex character.
X */
X case '&': /* special zero-width `character' */
X break;
X
X default:
X *op++ = s[-1];
X }
X }
X *op = '\0';
X}
X
X/*
X * Convert integer to Roman Numerals. (How have you survived without it?)
X */
Xchar *
Xctor(x, caps)
X int x, caps;
X{
X static char buf[BUFSIZ];
X register char *outp = buf;
X register unsigned n = x;
X register int u, v;
X register char *p, *q;
X
X if ((int)n < 0) {
X *outp++ = '-';
X n = -n;
X }
X p = caps ? "M\2D\5C\2L\5X\2V\5I" : "m\2d\5c\2l\5x\2v\5i";
X v = 1000;
X if (n >= v * BUFSIZ / 2) /* conservative */
X return ("[abortive Roman numeral]");
X for (;;) {
X while (n >= v)
X *outp++ = *p, n -= v;
X if (n == 0)
X break;
X q = p + 1;
X u = v / *q;
X if (*q == 2) /* magic */
X u /= *(q += 2);
X if (n + u >= v) {
X *outp++ = *++q;
X n += u;
X } else {
X p++;
X v /= *p++;
X }
X }
X *outp = 0;
X return (buf);
X}
//go.sysin dd *
if [ `wc -c < printf.c` != 7586 ]; then
made=FALSE
echo error transmitting printf.c --
echo length should be 7586, not `wc -c < printf.c`
else
made=TRUE
fi
if [ $all = TRUE ]; then
echo ' Changing owner to bin'
chown bin printf.c
else
echo ' Original owner was bin'
fi
if [ $made = TRUE ]; then
chmod 444 printf.c
echo -n ' '; ls -ld printf.c
fi
echo Extracting printf.1
sed 's/^X//' <<'//go.sysin dd *' >printf.1
X.\" @(#)printf.1 8-Jan-1987
X.\"
X.TH PRINTF 1 "8-Jan-1987"
X.UC 4
X.SH NAME
Xprintf \- formatted output at shell command level
X.SH SYNOPSIS
X.B printf
X.I format-string
X[
X.I arg1
X] [
X.I arg2
X] ...
X.SH DESCRIPTION
X.I Printf
Xduplicates (as far as possible) the standard C library routine of the
Xsame name, at the shell command level. It is similar to
X.IR echo ,
Xexcept that it formats its arguments according to conversion specifications
Xgiven in the
X.I format-string
Xbefore writing them to the standard output.
XFor a thorough explanation of format specifications, see
X.IR printf (3s).
X.PP
XFor the sake of perversity,
X.I printf
Ximplements one format conversion
X.B not
Xsupported by the standard printf subroutine: the
X.I %r
Xand
X.IR %R
Xconversions, which print integers as Roman numerals. The
Xfirst format produces lowercase, and the second uppercase.
X.PP
XAs a convenience, within the
X.I format-string
Xand any string or character arguments,
X.I printf
Xconverts ``backslash notation'' \- as defined in the
Xdraft proposed ANSI C Standard X3J11 \- into the
Xappropriate control characters.
XThe Standard provides for hexadecimal escapes as ``\ex1a2F3c4...'', in
Xwhich the only way to terminate the escape is with a non-hexadecimal
Xcharacter. This is not always suitable outside the C language, so
X.I printf
Xprovides one additional escape,
X.BR \e& ,
Xwhich expands to nothing, but in so doing serves to terminate a
Xhexadecimal escape.
X.SH EXAMPLES
X.nf
X.na
X.ta 0.6i
X.sp 2
X% printf 'Today is %s the %d of %s.\en' Monday 1 April
XToday is Monday the 1 of April.
X.sp 3
X% printf 'Interesting Numbers\en\en\etPie: %*.*f\en\etFoo: %g\en' \e
X 6 4 3.14159265 42
XInteresting Numbers
X
X Pie: 3.1416
X Foo: 42
X.sp 3
X% printf '%s %d, %R\en' July 4 1776
XJuly 4, MDCCLXXVI
X.sp 3
X% printf 'in ASCII this prints dd: \ex64\e&d.\en'
Xin ASCII this prints dd: dd.
X.sp 2
X.fi
X.ad
X.SH AUTHORS
XFred Blonder <fred@mimsy.umd.edu>
X.sp
XChris Torek <chris@mimsy.umd.edu>
X.SH "SEE ALSO"
Xecho(1), printf(3s)
X.SH BUGS
XThe Roman conversions are not strictly correct.
XZero produces no text;
Xvery large values give the complaint ``abortive Roman numeral''.
XNegative Roman numerals are printed with a leading minus sign.
XIt is unclear what the Romans did in such cases,
Xalthough zero could perhaps be written as ``nihil''.
XValues in the millions were sometimes written
Xusing an M with an overbar,
Xbut there is no bar-M character in ASCII.
X.sp
XThe ``%n'' conversion is unimplementable.
XThe number of characters written is not returned.
XLong double formats are not supported.
//go.sysin dd *
if [ `wc -c < printf.1` != 2521 ]; then
made=FALSE
echo error transmitting printf.1 --
echo length should be 2521, not `wc -c < printf.1`
else
made=TRUE
fi
if [ $all = TRUE ]; then
echo ' Changing owner to bin'
chown bin printf.1
else
echo ' Original owner was bin'
fi
if [ $made = TRUE ]; then
chmod 444 printf.1
echo -n ' '; ls -ld printf.1
fi
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Ozan Yigit <oz@yunexus.uucp>
Subject: Re: grep replacement (backref in egrep ?? whoa!)
Date: 14 Jun 88 17:58:49 GMT
To: unix-wizards@SEM.BRL.MIL
In article <7962@alice.UUCP> andrew@alice.UUCP writes:
>
>21) subroutine versions of the pattern matching stuff.
> ....
> .... the other two are egrep and back-referencing egrep.
> lastly, regexp will be reimplemented.
>
>Andrew Hume
Just how do you propose to implement the back-referencing trick in
a properly constructed (nfa and/or nfa->dfa conversion static or
on-the-fly) egrep ?? I presume that after each match of the
\(reference\) portion, you would have to on-the-fly modify the \n
portion of the fsa. Gack! Do you have a theoretically solid algorithm
[say, within the context of Aho/Sethi/Ullman's Dragon Book chapter on
regular expressions] for this ?? I would be much interested.
oz
--
The DeathStar rotated slowly, | Usenet: ...!utzoo!yunexus!oz
towards its target, and sparked | ....!uunet!mnetor!yunexus!oz
an intense SUNbeam. The green world | Bitnet: oz@[yulibra|yuyetti]
of unics evaporated instantly... | Phonet: +1 416 736-5257x3976
-----------------------------
From: Barry Shein <bzs@bu-cs.bu.edu>
Subject: Re: Tool -flag considered harmful
Date: 15 Jun 88 15:12:09 GMT
To: unix-wizards@brl-sem.arpa
From Doug Gwyn
>In article <23325@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>>Another anti-filename:linenum argument is what if I want to limit the
>>output to LESS than a single line, like printing only the exact text
>>matched? &c.
>
>Hey, while we're at it, have an option to highlight the matched
>pattern(s) in STANDOUT MODE (i.e. add control characters based on
>getenv("TERM") or a -Tname option). You have to admit that would
>sometimes be useful, and it depends even more than context on
>what grep "has it's hands on".
>
>How far do you want to go with this?
Doug, you've missed the point so completely it sends a shiver down my
spine.
The point is that if grep had a reasonable context-printer added
everything I suggest would simply be doable with *that*, no options
needed, while trying to build a back-end filter would probably be the
thing demanding all the special cases since significant amounts of
information have been lost once it went out the pipe.
Besides, if the context printer were powerfully enough designed
it could print STANDOUT mode with no mods, taking literal strings
to echo should be natural enough:
grep -P /\"^[[7m\"&/,/\"^[[0m\"/ pat file
(-P start,end printing context, default is ".,.+1", syntax similar to
ed) that is, & as in ed, \"..\" print (literally), the ANSI standout
mode string, then the matched string, then the ANSI end-standout mode
string.
Tho it would be hardly necessary (better to backquote the grep into an
xargs/echo), as was the criticism.
A general purpose print specifier in grep could be a handy tool.
-Barry Shein, Boston University
-----------------------------
From: brian chapman <chapman@sco.com>
Subject: Re: What do panic messages mean?
Date: 14 Jun 88 21:41:04 GMT
To: unix-wizards@SEM.BRL.MIL
In article <2375@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes:
< In article <6132@cup.portal.com> Eric_D_Davis@cup.portal.com writes:
< >
< >The lady at SCO asked me where I was touching the computer
<
< i went off and did a strings on /xenix. i didn't find anything labeled
< `[Tt]riple' anything, and here are the only `trap' things:
<
< Reschedule trap
< DNA trap in kernel mode
<
< now, what i want to know is what is a DNA trap? does this mean the
< machine has been genetically mutated?
On the chance that this is a serious question I will attempt
to answer it.
DNA is Device Not Availible (floating point device, that is)
Meaning the kernel is executing *87 instructions. Or trying to.
--
Brian Chapman uunet!sco!chapman
-----------------------------
From: Jack Jansen <jack@cwi.nl>
Subject: Re: back to the (ivory) tower
Date: 11 Jun 88 15:00:52 GMT
To: unix-wizards@SEM.BRL.MIL
I think alloca() should be implementable on all architectures, even
those with a 'virtual stackpointer' (i.e. those where the compiler
knows that the stackpointer will always be fp+NNN (or the other way
around, for that matter)).
I trick I once used was to allocate the memory on the heap,
allocate two extra words, use one of them to build a linked list of
all alloca-blocks within the scope and (here comes the trick) store the
original return address in the other one, and replace the return address
by the address of a routine that will free alloca() blocks and then
really return.
The only problem is setjump/longjump, but these can probably be
massaged to handle the alloca blocks.
--
Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
The shell is my oyster.
-----------------------------
From: Henry Spencer <henry@utzoo.uucp>
Subject: Re: alloca... (and setjmp/longjmp coroutines)
Date: 13 Jun 88 21:05:21 GMT
To: unix-wizards@brl-sem.arpa
> I'm no C wizard... but it seems to me that longjmp is the most suitable
> technique going, by default... What else is there? You could use [abuse?]
> sigvec and kill...
In the same way that you're abusing longjmp, you mean? The fact is, there
is -->**NO**<-- portable way to accomplish what you're trying to do. None.
Coroutines simply cannot be done without some degree of cooperation from
the language or the compiler. C doesn't cooperate on the language level,
so you're stuck. Yes, you can write code that will more-or-less work, so
long as the compiler doesn't spring any surprises on you. Portable it isn't.
That being the case, the proper approach is to admit defeat, study your
compiler carefully, and write twenty lines of assembler to do things right.
--
Man is the best computer we can | Henry Spencer @ U of Toronto Zoology
put aboard a spacecraft. --Von Braun | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
-----------------------------
From: Donn Terry <donn@hpfcdonn.hp.com>
Subject: Re: POSIX Draft for UNIX
Date: 13 Jun 88 23:13:37 GMT
To: unix-wizards@SEM.BRL.MIL
Caution:
The Trial-Use Standard is a quite different document from the Draft
that is currently being balloted. (Among other things it's about
1/2 as thick as the draft, due as much to formatting changes as
to content).
The current draft is not generally available at this time, as it is
not a published document. It is still an "internal use only" draft.
When it is approved (very soon, I hope) and the printing process
completes, it will be available as an IEEE and ANSI standard.
The addresses given here are correct to order the Trial-Use standard.
Donn Terry
-----------------------------
From: dewey henize <dewey@execu.uucp>
Subject: Re: lp/lpr interface
Date: 15 Jun 88 16:13:51 GMT
To: unix-wizards@SEM.BRL.MIL
Regarding the lp/lpr connects, could you please pass on any info you get?
We have exactly the same problem coming up (if HP ever gets the Ethernet
connectors :-)
I tried to mail this, but our mailer isn't smart enough to handle the
path. Sigh.
Dewey
--
===============================================================================
| execu!dewey Dewey Henize @ Execucom Systems Corp 512/346-3008 |
| You don't think my employer APPROVES of these ideas, do you?? Sheesh! |
===============================================================================
-----------------------------
From: Guy Harris <guy@gorodish.sun.com>
Subject: Re: grep replacement
Date: 15 Jun 88 18:32:12 GMT
Sender: news@sun.uucp
Keywords: grep, nm, unix consistency
To: unix-wizards@SEM.BRL.MIL
> grep -l is a tool which is supposed to tell me whether one or more files
> contain a string.
No, it isn't. "grep -l" is a tool that is supposed to tell you whether one or
more *text* files contain a string; if your file doesn't happen to contain
newlines at least every N characters or so, too bad. If you want to improve
this situation by writing a "grep" that doesn't have this restriction, feel
free.
> The fact that it refuses to do so for a class of magic files is a
> gratuitous violation of the unix paradigm.
"ed is a tool that is supposed to let me modify files. The fact that it
refuses to do so for a class of magic files is a gratuitous violation of the
unix paradigm." Sorry, but the fact that you can't normally use "ed" to patch
binaries doesn't bother me one bit.
-----------------------------
From: Lloyd Zusman <ljz@fxgrp.uucp>
Subject: Re: grep replacement
Date: 15 Jun 88 21:14:58 GMT
To: unix-wizards@SEM.BRL.MIL
In article <7962@alice.UUCP> andrew@alice.UUCP writes:
The following is a summary of the somewhat plausible ideas
suggested for the new grep. ...
...
2) matching multi-line patterns (\n as part of pattern)
this actually requires a lot of infrastructure support and thought.
i prefer to leave that to other more powerful programs such as sam.
^^^
...
Since I'm one of the people who suggested the ability to match multi-line
patterns, I'm a bit disappointed about this ... but such is life. So
where can I find 'sam'? Is it in the public domain? Is source code
available?
You can try to reply via email ... it might actually work, but don't
be surprised if your mail bounces, in which case I'd appreciate
replies here.
Thanks in advance.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."
-----------------------------
From: Brian Matthews <blm@cxsea.uucp>
Subject: Re: Context diffs in diff (was grep replacement)
Date: 14 Jun 88 16:23:25 GMT
To: unix-wizards@brl-sem.arpa
Doug Gwyn (VLD/VMB) <gwyn> (gwyn@brl.arpa) writes:
|Removing the ability to get context diffs when they are wanted WOULD
|be a bad idea. Removing this feature from "diff" itself is not a
|bad idea; I hate for "diff" to do extra work every time I run it when
|I virtually never use the context feature. Consider
| diff a b | diffc a b
|where "diffc" reads the "diff" information in parallel with the two
|files "a" and "b" to produce the context-diff output. By separating
|the two functions, it is not only likely to speed up non-context use
|of "diff" but also it is more likely to get the answer right, and it
|is easier to work on improving "diffc". (Existing context diff output
|is sometimes pretty horrible, for example larger than the inputs.)
In general I agree, the problem I have using diffc (I'm running System V
and use diffc quite regularly) is that one of it's arguments can't be
stdin. You could fix diffc to copy its input to a temporary file, but
you still couldn't do something like
diff - b | diffc - b
(and generate a context diff of stdin and file b).
--
Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm
+1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises
-----------------------------
From: Paul Gluckauf Haahr <haahr@phoenix.princeton.edu>
Subject: do we need (or want) context in grep and diff?
Date: 15 Jun 88 22:33:20 GMT
To: unix-wizards@SEM.BRL.MIL
there has been quite a lot of discussion following research!andrew's
outline of gre (and his comment that v9 diff no longer has -c) on
whether grep and diff should provide context. my two cents worth follows.
context printing might not be hard with grep. it may also require grep
to do some extra work that it doesn't do right now, that is, figuring
out the previous n lines. from andrew's description of the one limit
that exists in gre (64k lines), and some knowledge of how one does
a boyer-moore style grep (find the pattern then backup to find the
beginning of the line rather than searching each line individually)
leads me to believe that getting context right, at least in the presence
of very long lines, isn't as easy as one would expect.
on context, by the way, i can't think of a simple definition. if i
am printing a context of 2 (2 lines before and after, plus the given
line), what should a context grep (assume each character is a line)
for X in the file "abcXdXefgXhi" print? "bcXdX XdXef fgXhi" or "bcXdXefgXhi"?
and should the matched line be flagged, ala diff -c? i like having this
in a separate program which could handle those questions as options.
for handling pipe, yes it does mean putting the input somewhere. is that so
awful? remember, context grep output would largely be for humans, and in this
case i don't see the harm in using /tmp (besides, if it's small, it will all
be in the buffer cache anyhow). here is a quickly hacked cgrep:
#! /bin/sh
case $# in
0|1) echo >&2 "usage: cgrep nlines pattern [file...]"; exit 2;;
esac
n="$1"
pattern="$2"
shift; shift
case $# in
0)
tee /tmp/cgrep$$ |
grep -n "$pattern" |
context "$n" /tmp/cgrep$$
rm -f /tmp/cgrep$$
;;
*)
for i
do
grep -n "$pattern" "$i" | context "$n" "$i"
done
;;
esac
ideally it would do some argument processing and pass that along to
grep or context and a default nlines. context is easy and left as an
exercise for the reader, but several more than capable ones have been
floating around over the past couple of days. anyway, this is just an
outline.
on the argument for whether or not diff should support context, first
note that the problem of input from a pipe being lost is a chimera:
all a context diff produced needs is diff output and one of the
filenames (and knowledge of whether that was the first or second file
from the diff command line).
[ that is for conventional diff. the diff i run supports input from
two pipes (by enclosing the filename in parentheses it is passed as a
command to sh -c, allowing
$ diff '(first command)' '(second command)'
works rather nicely. i've been thinking of hacking together a shell
that takes (command) as a command argument and changing it to a named
pipe or /dev/fd/n and executing the command at the other end of the
pipe. rm '(cat file)' might isn't what one really expects. i heard
that one of the research shells, maybe it was one of korn's supported
this, but never saw it in a release. and there are very few commands
which this would be useful with other than diff, although awk -f
(command) might be nice every once in a while). by the way, my diff
doesn't have -c, and i haven't really missed it. but i don't send out
patches often. ]
for those of you who are complaining about writing a /tmp file, look
at what diff does if it's input is from a pipe. if we had good vm
implementations, diff could get away with reading everything into core.
alas, we don't, and that would cause large files to make diff thrash.
my personal feeling is that it is probably not harder for any reasonable
diff to handle context, and there are enough programs that look for context
diffs that it isn't unreasonable to keep it there. patch fudge factors
sound like a good argument for keeping them around, though a diffc might
provide a good place to start for playing with new, more readable forms
of context diffc, allowing some new creatures to feep into context diffs
(standout mode or nice output for troff, side-by-side format)
on the other hand, there is very little reason that i see to put context
in grep, and a good context tool would probably make us all forget that
anyone had ever asked for it.
but then again, i'm from the school of thought that doesn't use cat -v.
[ by the way, cat -v would be useful if it gave a one to one mapping of
it's output. but, if your file contains "M-" or "^", it won't. my own
vis program is reversible (with an unvis) that is useful for editing
binary files (ever needed to change a hard coded pathname?) though, of
course, many editors handle binary files ok ]
paul haahr
princeton!haahr or haahr@princeton.edu
-----------------------------
From: "Bruce G. Barnett" <barnett@vdsvax.steinmetz.ge.com>
Subject: Re: grep replacement
Date: 15 Jun 88 13:44:44 GMT
To: unix-wizards@brl-sem.arpa
In article <7962@alice.UUCP> andrew@alice.UUCP writes:
|
| The following is a summary of the somewhat plausible ideas
|suggested for the new grep.
|4) print one(first matching) line and go onto the next file.
| most of the justification for this seemed to be scanning
| mail and/or netnews articles for the subject line; neither
| of which gets any sympathy from me. but it is easy to do
| and doesn't add an option; we add a new option (say -1)
| and remove -s. -1 is just like -s except it prints the matching line.
| then the old grep -s pattern is now grep -1 pattern > /dev/null
| and within epsilon of being as efficent.
-----------
Actually this is extremely wrong.
Given the command
grep -1 Subject /usr/spool/news/comp/sources/unix/* >/dev/null
and
grep -s Subject /usr/spool/news/comp/sources/unix/* >/dev/null
I would expect the first one to read *every* file.
The second case ( -s ) should terminate as soon as it finds the first
match in the first file.
Unless I misunderstand the functionality of the -s command.
--
Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>
uunet!steinmetz!barnett
-----------------------------
From: "William E. Davidsen Jr" <davidsen@steinmetz.ge.com>
Subject: Re: lp/lpr interface
Date: 15 Jun 88 20:36:00 GMT
To: unix-wizards@SEM.BRL.MIL
The LP spooling as implemented in SysV (I haven't looked on SUNod but
I think it's the same) just executes a shell script with some arguments
defined and the file to be printed as stdin. I have a system setup to
use another systems printer, and the script uucp's the data to a special
directory on the machine with the printer. You can also do this by Enet,
and by allowing LPR in L.cmds so that it can be executed remotely. You
could cross mount directories if you have NFS.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
-----------------------------
From: Andrew Klossner <andrew@frip.gwd.tek.com>
Subject: Re: Tool -flag considered harmful (was: grep replacement)
Date: 15 Jun 88 20:22:30 GMT
Sender: andrew@tekecs.tek.com
To: unix-wizards@brl-sem.arpa
[]
"I've yet to hear an argument here against putting the context
function into grep other than weak bleatings of parsimony."
How about "because the people writing the tool think it doesn't
belong." This strikes me as a strong argument. If you have a
contrasting vision of what a pattern matcher can be, implement it
yourself; don't go beating on a toolmaker who isn't responsible to you.
(I'll admit that some of the beating is appropriate because Andrew
asked for comments, but this lambasting of his philosophy is out of
line.)
I think the exciting part of Andrew's announcement about gre (NOT
grep!) is that the sophisticated pattern matching code will be
encapsulated into library routines. The gre utility itself will just
be a wrapper. Those of us tool builders who can make slingshots but
aren't good enough to make scalpels will be able to produce whatever we
think a pattern matching tool should be, since the hard part will be
done and packaged for us. (Of course, none of us peons outside the
Labs will ever see this, unless they export it via the Toolkit.)
I have worked in software foundries where tool-building consisted of
library routine building, not filter process building, and I found it
to be a more powerful, more easily exploited approach to the crafting
of wonderful programs. I like a locally-developed tool called
"paragrep" which searches (English text) paragraphs instead of lines.
It was written by a C novice, thanks to the re_comp/re_exec library
routines.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
-----------------------------
From: David Goodenough <dg@lakart.uucp>
Subject: Re: Implementation of alloca() and friends
Date: 10 Jun 88 16:26:34 GMT
To: unix-wizards@brl-sem.arpa
From article <16072@brl-adm.ARPA>, by enag@ifi.uio.no:
> This discussion on alloca at least gave me something to chew on.
> I'm concerned with the implementation of a declaration like this, and
> the associated code:
>
> kaflunk(n, m)
> int n, m;
> {
> int array[n];
> int matrix[n][m];
> long something;
> }
>
> array is easy: make it a pointer, and allocate memory for it (by this
> stack allocation feature, or malloc, or something more ingenious), and
> use it transparently.
>
> matrix is worse: of course, it is still a pointer, and memory is
> allocated, but you need to hold the size of all but the first dimension
> to make the access algorithm work right.
I would suggest the following:
int **matrix;
int i;
matrix = alloca(n * sizeof(int *));
for (i = 0; i < n; i++)
matrix[i] = alloca(m * sizeof(int));
Now accessing matrix APPEARS to be normal: matrix[foo][blurf] will work,
althought the internals of the code generated will be different. Whatever
the case using a memory allocator for a multidimensional array is never
too pretty. However, in my humble opinion, I would rather get the messy
part out of the way when things are set up, and then have useages look
normal.
--
dg@lakart.UUCP - David Goodenough +---+
| +-+-+
....... !harvard!cca!lakart!dg +-+-+ |
+---+
-----------------------------
From: "Lawrence V. Cipriani" <lvc@tut.cis.ohio-state.edu>
Subject: Re: ksh incompatabilities with sh?
Date: 16 Jun 88 01:59:58 GMT
To: unix-wizards@brl-sem.arpa
In article <16183@brl-adm.ARPA> rbj@ICST-CMR.ARPA (Root Boy Jim) writes:
... discussion of the origin and use of ^ vs. | canned
>OK. I will grant you that `^' preceded '|'. But why do `many of (y)our
>customers still use ^ for pipes'? The original CACM paper, which I
>believe appeared in 74, predated most people's exposure to UNIX, and
>it used the symbol '|' for piping. So why would anyone have used `^'?
I suppose the ^ was considered archaic even in '74.
Our customers are phone companies and have been using our product
for over 16 years. Many of the *users* that were involved with our
product back then are still using it. Their exposure to UNIX predated
the CACM paper by a few years (see "Advanced UNIX Programming" by
Rochkind pg 156-157 for a brief glimpse of Columbus UNIX, which is
what several of AT&T's (older) internal products ran under).
The documentation for sh that was distributed way back showed ^ and |.
Before divesture of the RBOCS our customers could, at their option,
get source listings of our product for a modest printing fee.
They certainly are capable of understanding it, even code as obtuse as
sh. Also, the shell scripts that were part of the product ocassionally
used ^. The training classes might have infected them with ^.
Wherever they picked it up from, they've got and have a hard time kicking
the habit.
The ^ problem"is like the <> redirection operator. Its not documented
but it is in most versions of the Bourne shell. It means open for
read *and* write. I've seen it used only once. <> will be part of
the next ksh release.
>I can see people at TPC using `^' out of habit, but customers?
What's TPC, "The Phone Company" ? It doesn't exist any more.
--
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
-----------------------------
From: "John C. Sucilla" <jcs@tarkus.uucp>
Subject: Re: yacc and lex tutorials
Date: 14 Jun 88 00:47:53 GMT
Keywords: yacc, lex, tutorials
To: unix-wizards@brl-sem.arpa
In article <817@unioncs.UUCP> boehmr@unioncs.UUCP (Richard Boehm) writes:
>In article <184@asiux1.UUCP> wjm@asiux1.UUCP (Bill Mania) writes:
>>I am looking for a tutorial/textbook for yacc and for
>>lex. Something similar to 'The C Programming Language'
>I, also, would be interested in such references.
>
Try:
Introduction to Compiler Construction with UNIX
Axel T. Schreiner
H. George Friedman, Jr.
Prentice Hall
--
John "C". Sucilla, A silicon based life form.
{ihnp4,chinet,ddsw1}!tarkus!jcs
You have a better idea? Now's the time..
-----------------------------
From: Jamie Watson <jw@pan.uucp>
Subject: *USING* systems from DEC/IBM/HP
Date: 13 Jun 88 20:09:01 GMT
To: unix-wizards@brl-sem.arpa
The discussions so far of OSF and its impact on the future of unix systems
has been entirely concerned with perceptions of the motives of the founders.
As I have a fair amount of experience working with systems from three of the
major founders of OSF, and with AT&T and Sun, I would like to comment on the
the issue from a different perspective. Based on past experience, what are
we likely to get for a product from OSF.
First, a short background. Over the past ten years, I have worked in some
depth with Unix systems from (in somewhat chronological order) DEC, Momentum,
Plexus, HP, Sun, Opus, Arete, NCR, DEC (again) and IBM. For three years I
was the (usually only) software engineer for the Swiss distributor for Sun
and Plexus.
I am now working primarily with DEC (Ultrix) and RT/PC (AIX) systems. I have
been consistently satisfied with both. Each has significant advantages, and
significant problems. I have never worked with a Unix system that didn't have
significant problems (although I've worked with a few that didn't have any
significant advantages).
If, instead of pulling wild speculation out of thin air about the possible
motives and future actions of the OSF members, you examine their past record,
I think you will find considerable cause for optimism. Ultrix, AIX and HP/UX,
in their current releases, are all good Unix implementations. More important,
they have all been improved steadily over the recent past, and all show clear
signs of continuing to be improved in the future. Interstingly, all three of
these implementations either currently have, or have announced firm dates for,
extensive SysV *and* BSD compatibility, and significant generally accepted
extensions such as NFS.
If the members of the OSF continue to supply an operating system of the
quality that they have supplied in the past, I think we will all survive
what has been forced on us by commercial circumstances that are far beyond
our control.
jw
-----------------------------
From: Sjoerd Mullender <sjoerd@cs.vu.nl>
Subject: Re: grep on *.o
Date: 14 Jun 88 16:14:31 GMT
To: unix-wizards@brl-sem.arpa
In article <16082@brl-adm.ARPA> ted%nmsu.csnet@relay.cs.net writes:
From: Tim Bray <tbray@watsol.waterloo.edu>
You're on berklix. ld sez: "undefined: _memcpy". You say: "who's
doing that?". The source is scattered inconveniently. The
obvious thing to do is:
grep -l _memcpy *.o
That this often will not work is irritating.
Tim Bray, New Oxford English Dictionary Project, U of Waterloo
True, grep only works on readable files, the next most obvious thing
to do is produce ascii output, then grep:
nm $i | egrep '_memcpy|:'
Since we are on berklix, there is an even better way:
nm -o *.o | grep _memcpy
The -o flag tells nm to prepend the file name to each line.
This even works on Version 7.
--
Sjoerd Mullender
sjoerd@cs.vu.nl
When this doesn't work try sending via uunet.uu.net or mcvax.uucp.
-----------------------------
From: Tim Bray <tbray@watsol.waterloo.edu>
Subject: Re: grep replacement
Date: 14 Jun 88 13:34:55 GMT
Sender: daemon@watdragon.waterloo.edu
Keywords: grep, nm, unix consistency
To: unix-wizards@brl-sem.arpa
>In article <7207@watdragon.waterloo.edu> I wrote:
>}Grep should, where reasonable, not be bound by the notion of a 'line'.
...
>}The source is scattered inconveniently. The obvious thing to do is:
>}grep -l _memcpy *.o
>}That this often will not work is irritating.
At least a dozen people have sent me alternate ways of doing this, the
most obvious using 'nm'. Look, I KNOW ABOUT NM! But you're missing the
point - suppose the item in the .o files was another type of string, e.g.
an error message.
The point is: There are some files. One or more may contain a string in
which I am interested. grep -l is a tool which is supposed to tell me whether
one or more files contain a string. The fact that it refuses to do so for
a class of magic files is a gratuitous violation of the unix paradigm.
Tim Bray, New Oxford English Dictionary Project, U of Waterloo
-----------------------------
From: Rick Schubert <rns@se-sd.sandiego.ncr.com>
Subject: Re: redirection before wildcards
Date: 15 Jun 88 19:08:09 GMT
To: unix-wizards@SEM.BRL.MIL
In article <7979@alice.UUCP> andrew@alice.UUCP writes:
>
>
>it is not that wildcards are expanded after redirection;
>rather it is that bourne screwed the grammar. the grammar fo rthe shell
>(such that it is) says essentially:
> redir word
>rather than
> redir list
>and then check that list generates just one thing. (wildcard expansion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!!!^^^^^^
>is only done for lists.)
Maybe (notice that I qualified this -- I do not know for a fact) this is
the key. Although wildcards are sometimes used for filename completion
(I assume this means "use the name of the FILE that matches this pattern"),
wildcards in general mean "use the NAMES of ALL the FILES that match this
pattern". Since there can only be one filename per redirection, MAYBE
Steve Bourne (or John Mashey before him, if the Mashey shell exhibited
this behavior) reasoned that conceptually wildcard expansion didn't make
sense (even though it could sometimes work if the expansion matched exactly
one filename) for redirection and INTENTIONALLY wrote the grammar this way.
-- Rick Schubert (rns@se-sd.sandiego.NCR.COM)
-----------------------------
From: "Peter H. Berens" <phb@dcdwest.uucp>
Subject: Re: 4.2bsd memall mfind crash
Date: 15 Jun 88 23:09:45 GMT
Sender: root@dcdwest.uucp
To: unix-wizards@brl-sem.arpa
From article <339@algol.spp2.UUCP>, by urban@spp2.UUCP (Michael Urban):
> We have recently added some additional disk drives to a Vax 11/780
> running 4.2bsd (yeah, I know, I know). We have since been crashing
> on a "memall mfind" panic about once a day. At first I thought the
> problem was that we were mounting 17 file systems with NMOUNT set to
> only 15, but increasing NMOUNT to 20 failed to alleviate the problem.
> I note that the clause in memall that is producing the crash is a
> patch that was added (four years ago!) to alleviate another panic, the
> vaguely remembered MUNHASH bug.
>
> Does anyone know what the problem is here, and how to fix it? This is
> starting to cost us big bucks.
>
> --
> Mike Urban
> ...!trwrb!trwspp!spp2!urban
>
We came accross this problem about a year ago and suffered with it
for a long time before finding the problem. If you have too many
mounted file systems then the core map structure has a bit field
that is no longer bit enough to store the index into the mount table.
I belive the only thing we had to change was cmap.h, which I will
provide the diff to below, but I also remember some other define
that has to be changed when you bump NMOUNT. In param.h you may need
to increase MSWAPX as well.
Hope this helps.
Pete Berens
ITT Defense Communictions
(619) 578-3080 x240
*** /tmp/,RCSt1001638 Wed Jun 15 15:42:24 1988
--- cmap.h Tue Nov 17 15:51:35 1987
***************
*** 1,4
- static char RCSid[] = "$Header: cmap.h,v 1.1 87/10/31 23:44:13 phb Exp $";
/*
* $Log: cmap.h,v $
* Revision 1.1 87/10/31 23:44:13 phb
--- 1,3 -----
/*
* $Header: cmap.h,v 1.2 87/11/17 15:50:50 phb Exp $
*
***************
*** 1,5
static char RCSid[] = "$Header: cmap.h,v 1.1 87/10/31 23:44:13 phb Exp $";
/*
* $Log: cmap.h,v $
* Revision 1.1 87/10/31 23:44:13 phb
* Initial revision
--- 1,6 -----
/*
+ * $Header: cmap.h,v 1.2 87/11/17 15:50:50 phb Exp $
+ *
* $Log: cmap.h,v $
* Revision 1.2 87/11/17 15:50:50 phb
* Increased c_mdev field to 5 bits. Decreased c_blkno to 19 bits from
***************
*** 1,6
static char RCSid[] = "$Header: cmap.h,v 1.1 87/10/31 23:44:13 phb Exp $";
/*
* $Log: cmap.h,v $
* Revision 1.1 87/10/31 23:44:13 phb
* Initial revision
*
--- 2,11 -----
* $Header: cmap.h,v 1.2 87/11/17 15:50:50 phb Exp $
*
* $Log: cmap.h,v $
+ * Revision 1.2 87/11/17 15:50:50 phb
+ * Increased c_mdev field to 5 bits. Decreased c_blkno to 19 bits from
+ * 20. Rearragned entries to avoid problems with locore.s.
+ *
* Revision 1.1 87/10/31 23:44:13 phb
* Initial revision
*
***************
*** 14,21
{
unsigned int c_next:13, /* index of next free list entry */
c_prev:13, /* index of previous free list entry */
! c_mdev:4, /* which mounted dev this is from */
! c_lock:1, /* locked for raw i/o or pagein */
c_want:1, /* wanted */
c_page:16, /* virtual page number in segment */
c_hlink:13, /* hash link for <blkno,mdev> */
--- 19,25 -----
{
unsigned int c_next:13, /* index of next free list entry */
c_prev:13, /* index of previous free list entry */
! c_mdev:5, /* which mounted dev this is from */
c_want:1, /* wanted */
c_page:16, /* virtual page number in segment */
c_hlink:13, /* hash link for <blkno,mdev> */
***************
*** 23,29
c_free:1, /* on the free list */
c_gone:1, /* associated page has been released */
c_type:2, /* type CSYS or CTEXT or CSTACK or CDATA */
! c_blkno:20, /* disk block this is a copy of */
c_ndx:10; /* index of owner proc or text */
};
--- 27,34 -----
c_free:1, /* on the free list */
c_gone:1, /* associated page has been released */
c_type:2, /* type CSYS or CTEXT or CSTACK or CDATA */
! c_lock:1, /* locked for raw i/o or pagein */
! c_blkno:19, /* disk block this is a copy of */
c_ndx:10; /* index of owner proc or text */
};
-----------------------------
End of UNIX-WIZARDS Digest
**************************