bill@twwells.com (T. William Wells) (06/22/89)
I have had several minor problems with C news. Following is a summary
and suggested fixes.
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.
The trivial fix is to put a semicolon at the end of those lines. The
affected Makefiles are in batch, conf, expire, input, and libstdio.
Another set of bugs is in inews. When grepping for Approved:, it does
not redirect the output to /dev/null. Moreover, it tries to remove a
nonexistent temp file immediately after and the rm does not have a -f
flag after it to inhibit an error message. So, moderators get
spurious messages when posting.
In newsrun, the find bad... command prints an error message if there
have been no bad batches in seven days because it tries to rm the
`bad' directory. Since I never get corrupted batches (yay, Telebit!)
this starting giving me a bogus message a week after installation. The
find needs a -type f.
Finally, the stdio stuff provided does not work on my Microport
SysV/386 3.0e. Alternately, there is some, as yet undiscovered bug
elsewhere, that ceases to be apparent when I stop using the stdio.
A gripe: I want to run doexpire when I'm particularly low on disk
space but I want it to do a different expire than is specified by
explist; the script mentions explist explicitly. I might be able to
get a similar effect by fiddling with the parameters in the explist
file, but the documentation left me confused.
Another gripe: I understand using shell scripts all over the place,
though they really slow some things down, 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. Following
is the relevant part of my spacefor (for Microport SysV/386 3.0e):
dfunit=512 # default unit (bytes)
case "$2" in
incoming) arg="$NEWSARTS/in.coming" ; desire=500 ;;
articles) arg="$NEWSARTS" ; desire=2000 ;;
control) arg="$NEWSCTL" ; desire=2000 ;;
outbound) arg="/usr/spool/uucp" ; desire=2000 ;;
archive) arg="$NEWSARTS" ; desire=1 ;;
*) echo "$0: bad type argument \`$2'!!" >&2
exit 2 ;;
esac
req=`expr \( $1 + $dfunit - 1 \) / $dfunit`
size=`expr \( "\`df $arg\`" : '.*: *\([0-9]*\).*' - $desire \) / $req`
if [ $size -lt 0 ]; then
echo 0
elif [ $size -gt 10000 ]; then
echo 10000
else
echo $size
fi
exit 0
(Note another difference: the original does the computation in terms
of bytes, mine converts the numbers to dfunits and does the
computation in terms of that; this is a minor difference, though one
could argue that mine is the more consistent with reality.)
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.
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.comhenry@utzoo.uucp (Henry Spencer) (06/24/89)
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. >Another set of bugs is in inews. When grepping for Approved:, it does >not redirect the output to /dev/null. Moreover, it tries to remove a >nonexistent temp file immediately after and the rm does not have a -f... 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. >In newsrun, the find bad... command prints an error message if there >have been no bad batches in seven days because it tries to rm the >`bad' directory... This is a difference in "find" behavior that we overlooked; the ones we have don't do that. Fixed in the patch. >A gripe: I want to run doexpire when I'm particularly low on disk >space but I want it to do a different expire than is specified by >explist; the script mentions explist explicitly... Arguably a bug; doexpire perhaps should take the file name as an argument. Just modify it. (See why all that upper-level control is shell files?) >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.) >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. >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. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bill@twwells.com (T. William Wells) (06/30/89)
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
epsilon@wet.UUCP (Eric P. Scott) (07/09/89)
In article <1989Jun30.143355.21661@twwells.com> bill@twwells.com (T. William Wells) writes: >Mid-line tabs are common; _Significant_ mid-line tabs are not so. Gee, I guess you don't use troff... -=EPS=-