netnews@wnuxb.UUCP (Heiby) (06/24/85)
Unix Technical Digest Mon, 24 Jun 85 Volume 2 : Issue 12
Today's Topics:
Administrivia
'tablet' line discipline in 4.2 BSD
Callan (v7) losing blocks upon power-up
chroot(2)
make and includes (2 msgs)
Problems with make & sh
----------------------------------------------------------------------
Date: Mon, 24 Jun 85 19:30:22 GMT
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Subject: Administrivia
I have received a few messages suggesting that I change the format of
mod.unix from a digestified format to one where individual messages
would be posted. The primary reason given is that it would be easier
to be selective at lower baud rates. Reasons for digestification include
lower network overhead (uucp and rnews), less disk overhead (partial blocks),
and the ability to send out "back issues" (and to know when you've missed
something). If anyone has strong feelings about this, let me know. So
far, I am not moved. Send any input on this to ihnp4!cbosgd!unix-request.
Thanks. Ron.
------------------------------
Date: Tue, 18 Jun 85 13:54:41 edt
From: allegra!phri!roy (Roy Smith)
Subject: 'tablet' line discipline in 4.2 BSD
I'm trying to get a GTCO Digi-Pad 5 graphics tablet going and am
having trouble with characters getting lost because of the high data
rates (a steady 4800 baud, in my case). I figured I might use the
berknet line discipline to solve this, so I started perusing the tty
driver code to see how it works. Lo and behold, I ran across
/usr/sys/sys/tty_tb.c which purports to be a line discipline designed
specifically for digitizing tablets.
Problem is, there is no documentation that I can find (other
than the occasional comment in the source file). Does anybody know more
about this? Does it work? How do I use it? Any other hints on
interfacing digitizing tablets over RS-232 lines would also be greatly
appreciated.
I suppose you might want to know that I'm running 4.2 BSD on a
VAX 11/750 with a mix of DZ- and DMF-type serial line controllers.
allegra!phri!roy (Roy Smith)
System Administrator, Public Health Research Institute
------------------------------
Date: Sun, 23 Jun 85 21:33:20 mdt
From: ihnp4!lanl!unmvax!nmtvax!djm (The Demented Teddy Bear)
Subject: Callan (v7) losing blocks upon power-up
On my recently acquired Callan Unistar 100, I have noticed an annoying
problem. After a power-up, I have it perform a file system check. It
consistently comes up with about 25-30 blocks misplaced. Does anyone
have any suggestions as to the cause of this (I power-off right after
de-buffering everything with 'sync').
Dieter Muller
ucbvax!unmvax!---V
lanl{.arpa}!---> nmtvax!djm
------------------------------
Date: Fri, 21 Jun 85 12:19:10 mdt
From: seismo!cmcl2!lanl!unmvax!unmg!unmc:ingham (Kenneth Ingham)
Subject: chroot(2)
Have I misunderstood the usage of chroot? We have both 4.2BSD & Ultrix
v1.1 source on-line, and it would be nice when building ultrix stuff
that it look in ultrix's /usr/include. /ultrix is the root of the
ultrix filesystem (we are running 4.2). Shouldn't chroot(2) allow us
to change the root for a shell that we would then use when building
ultrix? Here is the program that I wrote:
main(argc,argv,envp)
char **argv, **envp;
int argc;
{
if (chroot("/ultrix") != 0) {
perror("newroot");
exit(1);
}
execve("/bin/csh", argv, envp);
printf("exec failed. ");
perror("newroot");
}
This is run while I am root. It gives no error messages, yet it also
fails to start a new shell. Can anybody offer any suggestions?
Kenneth Ingham, UNM Computing Center, Albuquerque, NM 87131, 505-277-8044
~{pur-ee!purdue,ucbvax!lbl-csam,philabs!cmcl2}!lanl!unmc!ingham
~{convex,ucbvax,gatech,csu-cs,anl-mcs}!unmvax!unmc!ingham
------------------------------
Date: Fri, 21 Jun 85 21:25:11 edt
From: <ihnp4!decvax!mcnc!rtp47!throopw>
Subject: make and includes
> The difficulties with include' stem from one of Unix's
> fundamental flaws, namely the dependence on strictly syntactic
> mechanisms such as textual substitution for solution of semantic
> problems.
> (Stavros Macrakis)
Maybe I'm being dense, but what difficulties with make and include are
being refered to here? Clearly make is not as "powerful" a notation for
dependancy management as is useful, but I'm at a loss to see how Ada
improves the situation. Quite the reverse, it seems to me. Languages
that have the equivalent of packages and "with" have (usually) more
complicated compilation order dependancies than languages that propagate
data via include files.
Lest you mistake my meaning, let me add that I *strongly favor* using
languages with explicit module interconnections and strong typechecking
(eg, Ada) over languages with only informal module interconnections and
weak typechecking (eg, C). I also prefer languages that have provisions
for "inline procedures", compiler definition of constants, and so on,
over languages that depend on textual substitution to acheive these
ends. So, in my opinion, Ada is clearly an improvement over C in just
the areas mentioned.
(I've been using Ada (or Ada-like languages) for some time now, and I
wouldn't want to do it without a better-than-make automated construction
tool. On the other hand, given a better-than-make automated
construction tool, Ada (or Ada-like languages) are very comfortable
programming environments.)
To summarize: I agree with the proposition that make is not "powerful
enough", and I agree that Ada provides certain facilities in a much
cleaner and more powerful form than C. But I don't see how these two
notions lead to the conclusion that use of Ada makes make any more
useful.
---
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw
------------------------------
Date: Sat, 22 Jun 85 01:40:45 PDT
From: sun!guy (Guy Harris)
Subject: make and includes
> The difficulties with `make' and `include' stem from one of Unix's fundamental
> flaws, namely the dependence on strictly syntactic mechanisms such as textual
> substitution for solution of semantic problems.
You mean "one of C's fundamental flaws"; nothing stops you from running Ada
on UNIX...
Guy Harris
------------------------------
Date: Fri, 21 Jun 85 14:15:48 PDT
From: ihnp4!tektronix!hammer.TEK!seifert
Subject: Problems with make & sh
>From: seismo!munnari!basser.oz!john
>
>I am at a loss to understand why your problem happens. A well-known
>(and documented) feature of the shell is that the exit status of
>a pipeline is the exit status of the last command. Thus, the
>exit status of your grep shouldn't ever be seen by make, -e or no -e.
>No doubt this is just another thing that is broken in 4.2BSD, though.
Try broken in system V. At least it was before they added the
release 2 version 16 modification pi-over-e type IV ++. I found this
out when I switched from sh to ksh and a shell script broke. Turned
out that /bin/sh was returning the *first* exit code from a pipe,
while David Korn actually read the documentation, so ksh correctly
returned the *last* exit code. This fix may have made it into
system V's /bin/sh by now, I don't know. It works correctly on both
sh and csh under Utek (Utek is based on 4.2, with some stuff from
sysV and a distributed filesystem added)
To see if the shell you're running does this right:
for sh and ksh:
(exit 1) | (exit 2) | (exit 3) ; echo $?
for csh:
(exit 1) | (exit 2) | (exit 3) ; echo $status
The echo should print 3.
[Thanks for Tim Knox for the correct variable to echo in
the "let's change things just to change things" csh.]
[If anyone has a good argument I can use to convince management
that we should offer ksh for the 6000 series I'd like to hear it]
Snoopy (victom of ksh withdrawal)
tektronix!hammer!seifert
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)