Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!bionet!csd4.milw.wisc.edu!indri!uflorida!novavax!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: news.software.b
Subject: Re: Minor problems with C news
Message-ID: <1989Jun30.143355.21661@twwells.com>
Date: 30 Jun 89 14:33:55 GMT
References: <1989Jun22.061942.1751@twwells.com> <1989Jun23.193547.1641@utzoo.uucp>
Organization: None, Ft. Lauderdale, FL
Lines: 87

In article <1989Jun23.193547.1641@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
: In article <1989Jun22.061942.1751@twwells.com> bill@twwells.com (T. William Wells) writes:
: >Some Makefiles have some lines like:
: >
: >     test ! -r file
: >
: >These, not having a shell metacharacter, get exec'ed instead of sh
: >-c'ed. Unfortunately, while test is a builtin, there is no /bin/test
: >on my system. So those lines fail.
:
: This is a bug in your system.  Makefile command lines are supposed to be
: run AS IF by the shell.  The best fix, probably, is a /bin/test with
: functionality matching that of the builtin.

I know it is a bug. Unfortunately, I'm not the only one afflicted by
this particular bit of brain damage. And it's such a trivial fix!

: The former is a System V bug; they broke the -s option of grep.  The
: latter is indeed our fault.  The official patch just released fixes both.

: This is a difference in "find" behavior that we overlooked; the ones we
: have don't do that.  Fixed in the patch.

Thanks for the bug fixes.

: >Another gripe: I understand using shell scripts all over the place,
: >though they really slow some things down...
:
: The only thing we're aware of that is seriously hurt by being a shell file
: is inews (which we're reluctant to do in C because so much of it is
: potentially subject to change to enforce local policies).  Most everything
: else just uses the shell files for outermost-level control, with the real
: work all being done in C.  (The batcher, for example, is totally dominated
: by the batchmake|compress|uux pipeline, 100% C.)

What happens is that, on some systems, the main overhead is not in
CPU, it is in disk access. Inews is, as you note, slow, but not only
because of the CPU consumed but because of the amount of disk
overhead. But what really hits me is that, when those complicated
shell scripts are running, my disk goes seeking all over the place,
really slowing everything else down.

The big pipelines don't cause this problem because they are somewhat
CPU limited; I run them niced and have little problem. But nice
doesn't do squat for disk seeks and it it disk seeks that impact the
rest of my system.

: >but did you *have* to use
: >awk? It's awkfully slow! And, I think, unnecessary in many places.
: >For example, I use expr instead in my version of spacefor...
:
: Awk is indeed a bit slow.  However, it wins big on flexibility and
: portability.  Expr does only 16-bit arithmetic on 16-bit machines, for
: example, while awk copes properly.

Uk. I didn't know that expr was that brain-damaged. Perhaps you could
extract expr from ash, modify it if necessary to use longs, and use
that? Heck, I'd be willing to add that to my list of things to do if
it would actually be used. (Which means that it would get done
sometime in the next year, but I'm sure you know all about that. :-)

: >And a third gripe: putting tab characters anywhere except at the
: >start of a line causes lots of problems with certain editors (like
: >mine). These editors have a nasty habit of changing the tabs into
: >spaces or of displaying them as ^I, in either case causing
: >difficulties.
:
: We do not think it is our responsibility to fix bugs in your editors.
: Mid-line tabs are common in C source and shell files everywhere.

Mid-line tabs are common; _Significant_ mid-line tabs are not so.

The company I work for has long been shipping portable source code;
one of the common complaints we got (till we fixed it) was that we
had control characters in the text. It seems that all too many
systems just can't deal with anything other than leading tabs and
newline line terminators.

I understand that this might be a headache to fix, but it would be a
Good Thing if you could. Not remove all the tabs, just the significant
ones, the ones that would cause bugs if changed to spaces. That way,
those people who have tab problems could just run the text through a
simple program without worrying about what they broke.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com