ast@cs.vu.nl (Andy Tanenbaum) (10/05/89)
When people post mail messages, it always takes some editing to remove
all the headers and get to the message. It has ocurred to me that the
computer ought to be able to do this, so I wrote a program called cleanit
(given below), that searches a file for a line like
----------------------------- cut here --------------------------------
and throws out everything up to and including this line. Then it keeps
lines until it hits another such line. What do people think of the suggestion|
of defining a posting standard in which everything before the cut line is
junk and can be discarded? One disadvantage is that if you have some
comments telling what you did, if you put them before the cut line, they
get zapped. If you put them after, that's ok, and I think patch can live
with that. The definition of a cut line is any line beginning with 20
hyphens starting in column 1. This leaves 60 columns for rugged individualists
to express their feelings on cut lines.
Even if you think this is a dumb idea, PLEASE install this program on your
system since I am going to try and automate the 1.4b postings, and they will
use cleanit. See next message for more.
Andy Tanenbaum (ast@cs.vu.nl)
/* cleanit - clean up mail message Author: Andy Tanenbaum */
/* When a program comes in over USENET, it has a header on the front
* and (usually) a signature at the end. This program strips off this
* junk to get at the program (or shar file or whatever). It uses the
* concept of a "cut line", which is a line beginning with >= 20 hyphens,
* like this:
------------------------- cut here -------------------------
* Cleanit assumes that the program being sent starts with a cut line and
* ends with a cut line. It strips off everything up to and including
* the first cut line and everything from the second cut line to the end.
* What is left is the program being transmitted. The original file is
* left intact on a file whose name is the original name with # attached.
*
* Examples:
* cleanit x y z # three files are cleaned up
* cat x | cleanit > y # clean x and write it on y
*/
#include <stdio.h>
#define MAX_NAME 14
#define BUF_SIZE 1024
#define CUT_LINE "--------------------"
main(argc, argv)
int argc;
char *argv[];
{
int i;
FILE *in, *out;
char buf[BUF_SIZE], *p, *q;
if (argc == 1) {
clean(stdin, stdout);
exit(0);
} else {
for (i = 1; i < argc; i++) {
/* For each file, open it, rename it, and copy it. */
p = argv[i];
in = fopen(p, "r");
if (in == NULL) {
fprintf(stderr, "cleanit: cannot open %s\n", p);
continue;
}
/* Build string to pass to system to rename file. */
strcpy(buf, "mv ");
strcat(buf, p);
strcat(buf, " ");
q = buf + strlen(buf);
strcat(buf, p);
if (strlen(argv[i]) >= MAX_NAME) {
*(q + MAX_NAME - 1) = 0;
}
strcat(buf, "#");
system(buf); /* rename the file */
if ( (out = fopen(p, "a")) == NULL) {
fprintf(stderr, "cleanit: cannot create %s\n", p);
continue;
}
clean(in, out, p);
fclose(in);
fflush(out);
fclose(out);
}
}
exit(0);
}
clean(in, out, file)
FILE *in, *out;
char *file;
{
/* Copy the file. */
char buffer[BUF_SIZE];
int size;
size = strlen(CUT_LINE);
while (1) {
if (fgets(buffer, BUF_SIZE, in) == NULL) return;
if (buffer[0] != '-') continue;
if (strncmp(buffer, CUT_LINE, size) == 0) break;
}
/* First cut line has been found. Start copying with next line. */
while (1) {
if (fgets(buffer, BUF_SIZE, in) == NULL) return;
if (strncmp(buffer, CUT_LINE, size) == 0) return;
if (fputs(buffer, out) == NULL) {
fprintf("cleanit: write error on %s\n", file);
return;
}
}
}maart@cs.vu.nl (Maarten Litmaath) (10/05/89)
ast@cs.vu.nl (Andy Tanenbaum) writes:
\... clean(stdin, stdout);
\... clean(in, out, p);
Bug! clean() isn't a varargs function. Even thou shalt use lint, Mr T.!
And why write a 73 line C program when a 17 line shell script can do the
task equally fast?
----------8<----------8<----------8<----------8<----------8<----------
:
CUT_LINE="--------------------"
SED="
1,/^$CUT_LINE/d
/^$CUT_LINE/,\$d
"
test $# = 0 && exec sed "$SED"
for i
do
backup=`expr "$i" : '\(.............\)' \| "$i"`'#'
mv "$i" "$backup" &&
sed "$SED" < "$backup" > "$i"
done
----------8<----------8<----------8<----------8<----------8<----------
--
Did Andy Tanenbaum get his programming |Maarten Litmaath @ VU Amsterdam:
instruction from a Cereal box? (Sam McCrea)|maart@cs.vu.nl, mcvax!botter!maartbroman@schroeder.nosc.mil (Vincent Broman) (10/05/89)
> What do people think of the suggestion of defining a posting standard > in which everything before the cut line is junk and can be discarded? Not very useful. There is already a standard way to separate posting headers from the text of the message: they are separated by the first blank line in the article. "Cut here" lines do not separate junk from good stuff, they separate the contents of a file from non-contents of that file, giving it a well-defined boundary. If AST is going to be posting stuff in uuencoded form, notice that uudecode already ignores things before "begin" and after "end", if there is only one uuencoded piece in the article. I would suggest this: 1. create humungous compressed tar or shar file, 2. split it into small binary chunks, 3. uuencode each chunk and post it individually. It's too bad that floppy-only systems seem to be excluded from any of this action, because the big compressed archive probably won't fit on a floppy. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
maart@cs.vu.nl (Maarten Litmaath) (10/06/89)
I wrote: \... \ backup=`expr "$i" : '\(.............\)' \| "$i"`'#' So MINIX's `expr' seems not to recognize the `:' operator: big deal. backup=`echo "$i" | sed 's/\(.............\).*/\1/'`'#' -- Did Andy Tanenbaum get his programming |Maarten Litmaath @ VU Amsterdam: instruction from a Cereal box? (Sam McCrea)|maart@cs.vu.nl, mcvax!botter!maart
ast@cs.vu.nl (Andy Tanenbaum) (10/06/89)
In article <3498@solo10.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >Bug! clean() isn't a varargs function. Even thou shalt use lint, Mr T.! ^ ^ ^ | | | 1 2 3 1. Yes indeed. add "stdin" as the third argument. Thanks. 2. Correct. clean() is not a varargs function. Even aside from the bug above, it would not be a varargs function. A varargs function is one in which a single formal parameter is used to fetch multiple actual parameters by doing address arithmetic or some such on the address of the actual parameter. This was a case of calling a function that was declared with three formal parameters with two actual parameters, i.e. just leaving out the last actual parameter. Given the C calling sequence of pushing the last parameter first, this is legal, and in any event, is not related to varargs at all. 3. If you promise to write a lint for MINIX, I promise to use it. Andy Tanenbaum (ast@cs.vu.nl)
ast@cs.vu.nl (Andy Tanenbaum) (10/06/89)
In article <BROMAN.89Oct5083603@schroeder.nosc.mil> broman@nosc.mil writes: >uudecode already ignores things before "begin" and after "end", I didn't realize that. In any case, the cut line mechanism is more general than only uudecode files. It is quite common to see messages posted with some sort of cut line (also nonencoded ones), so if we could standardize the format of the cut line, we could make the files suitable for computer processing. 60 characters has got to be enough to allow everyone to express their personal thoughts on cut lines. >It's too bad that floppy-only systems seem to be excluded from any of this >action, because the big compressed archive probably won't fit on a floppy. I think that will be increasingly the case. The /usr/bin + /usr/lib directories are already approaching 2 megabytes together, which means that a floppy based system can only run a small fraction of the binaries, let alone having the increasingingly large documentation directory, man files etc. online. Not to mention sources. While I will continue to make boot diskettes etc to actually come up on floppies, I think that the number of floppy-only users is rapidly decreasing, as hard disks keep coming down in price. Andy Tanenbaum (ast@cs.vu.nl)
n62@nikhefh.nikhef.nl (Klamer Schutte) (10/06/89)
In article <3540@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <BROMAN.89Oct5083603@schroeder.nosc.mil> broman@nosc.mil writes: >>It's too bad that floppy-only systems seem to be excluded from any of this >>action, because the big compressed archive probably won't fit on a floppy. > >boot diskettes etc to actually come up on floppies, I think that the number >of floppy-only users is rapidly decreasing, as hard disks keep coming down >in price. Are they? An atari ST, 1meg, monochrome monitor cost Hfl 1499,- A hard disk, 30 meg (normal size) cost Hfl 1299,- I see this as almost doubling the price -- and i don't have the money. > >Andy Tanenbaum (ast@cs.vu.nl) Klamer. -- _____________________Yes, mail address changed again :-(________________________ Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhef.nl
root@grieg.CS.ColoState.Edu (the root) (10/06/89)
In article <3540@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <BROMAN.89Oct5083603@schroeder.nosc.mil> broman@nosc.mil writes: >>It's too bad that floppy-only systems seem to be excluded from any of this >>action, because the big compressed archive probably won't fit on a floppy. >While I will continue to make >boot diskettes etc to actually come up on floppies, I think that the number >of floppy-only users is rapidly decreasing, as hard disks keep coming down >in price. I applaud your plans to continue building floppy bootable versions of Minix. I suspect that there are several Minix user communities: the personal computer owner who has invested in hard-disks, the student on a floppy-only personal computer studying operating systems, and owners of lap-top computers. In the former group, it's likely that a department has equipped a lab with the minimum cost system (and floppies are still cheaper than hard disks). In the last group, hard disks strongly limit how long you can be away from a power source.
maart@cs.vu.nl (Maarten Litmaath) (10/07/89)
ast@cs.vu.nl (Andy Tanenbaum) writes:
\... This was a case of calling a function that was declared with
\ three formal parameters with two actual parameters, i.e. just leaving out
\ the last actual parameter. Given the C calling sequence of pushing the
\ last parameter first, this is legal, [...]
I think it's always illegal: there might exist machines with `weird' calling
conventions which would choke over such mis-invocations (while still allowing
varargs functions). (Aside: could you comment on that, Henry?)
Anyway, what's wrong with the shell script?
(I hope you don't feel offended by my .signatures: I'm just quoting funny
remarks.)
--
"Sometimes it seems Marvin wrote MINIX while Andy was playing Donald Duck's
Playground on Suzanne's computer." (Benno van den Brink) | mcvax!botter!maartast@cs.vu.nl (Andy Tanenbaum) (10/07/89)
In article <3554@solo2.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >I think it's [# formals != #actuals] always illegal I don't have K&R here, so I am not sure if it is legal. As I said, it was a bug, but either way, it is not varargs. That has to do with computing the address of one paramter from the address of another, and clean() certainly does not do that. >Anyway, what's wrong with the shell script? People keep calling up P-H asking for the sources to spell and write (shell scripts). Furthermore, I find the shell script somewhat cryptic. >"Sometimes it seems Marvin wrote MINIX while Andy was playing Donald Duck's >Playground on Suzanne's computer." (Benno van den Brink) I wouldn't write Marvin off quite so fast. He's probably smarter than me. I certainly didn't come in 2nd in the Amsterdam (or any other) chess tournament for kids when I was 9. Andy Tanenbaum (ast@cs.vu.nl)
ncoverby@ndsuvax.UUCP (Glen Overby) (10/08/89)
Uudecode on BSD skips everything up to the "begin" line, so stripping the header is unecessary. For shar files, there was a "unshar" program posted to comp.sources.unix several volumes ago that does a really nice job, and tries to make sure that the unshar program doesn't do anything nasty. I resent having to deal with uuencoded files just for Bitnet. Why don't the Bitnet people get together and nominate one person who is on both Usenet (via uucp or something that doesn't trash files) and Bitnet and have them uuencode all the postings? An aside question: has anybody on info-minix via the Internet had checksum problems when unsharing files? The postmaster on the node running the listserv distributing the group has promised me that his IBM won't mung postings for people on non-IBMs. Would asking for a summary of changes (not what lines were changed, but what features were added or "removed" [fixed]) be too much? Even though I blindly trust what Andy posts, I am wary of what other people's quick hacks will break. On the Unix bugs groups people describe the problem, tell how to reproduce it, and then provide the fix. I find the former two missing from this group most of the time. It's a credibility issue: do you really know what you're doing well enough for me to trust your fix? -- Glen Overby <ncoverby@plains.nodak.edu> uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)
henry@utzoo.uucp (Henry Spencer) (10/08/89)
In article <3554@solo2.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >\ ... just leaving out >\ the last actual parameter. Given the C calling sequence of pushing the >\ last parameter first, this is legal, [...] > >I think it's always illegal: there might exist machines with `weird' calling >conventions which would choke over such mis-invocations (while still allowing >varargs functions). (Aside: could you comment on that, Henry?) The order of parameter pushing has never been defined; in fact, order of evaluation of parameters, and stack layout of same, has always been quite explicitly undefined. (Even K&R 1st ed. specifically warns that compilers differ.) In pre-ANSI C, there was no officially-blessed way to call a function with arguments not matching those at the function's definition. (The <varargs.h> header existed in V7 but was not documented.) Printf and friends had to be done *somehow*, with a strong implication that the method was implementation-specific and collaboration with the compiler was needed. ANSI C blesses mismatches specifically and only for varargs functions. In practice, the usual approach to printf was to have the compiler use a push order that put the first argument in a predictable place, which usually meant last-first so that the first argument was at the top of the stack. This had the side effect of making trailing arguments optional in general. Exploiting this is probably not a good idea; the portability problems are substantial and growing. Varargs functions do not necessarily use the same calling sequence as ordinary ones. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ast@cs.vu.nl (Andy Tanenbaum) (10/09/89)
In article <2992@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes: >I resent having to deal with uuencoded files just for Bitnet. On the whole, I agree with you. However, an additional advantage of doing it this way is compress + uuencode saves something like 25% of the bandwidth, and this is going to be very large, so that is definitely worth something. Also, with my cleanit program and install shell script, however redundant they may be, the installation of 1.4b should be relatively easy since the computer will have to do all the work. Andy Tanenbaum (ast@cs.vu.nl)
bill@chinet.chi.il.us (Bill Mitchell) (10/09/89)
AST recently posted a program, cleanit.c, to strip leading junk
ahead of a shar file from a USENET posting.
Problem: The leading junk often contains very useful info about
the shar file.
Problem: Cleanup.c requires posters to discipine themselves to include
a "cut line" with 20 leading dashes. Fat chance.
Problem: Postings often include unshared C programs.
Solution: One is needed. My contribution below.
This is my first cut at a program, comment.c, which is intended
to comment leading junk in a posting containing a shar file or
an unshared C program, leaving the junk intact in case it is useful.
Emphasize that this is a first cut. It has not been used or tested
much at all.
It seems to work OK except for postings I've seen which include the
cute trailer line "#include <disclaimer.std>". The leading '#' causes
comment.c to think a shar file is coming, and it considers all text
before the cute trailer line to be leading junk. The moral of that
story is that it ought to be smarter about identifying shar files.
Anybody care to add the needed smarts?
/*
** comment.c - bill mitchell 07 oct 89
**
** this program reads files and tries to identify an imbedded shar file
** or c program
**
** if a shar file or c program is found, it comments out leading junk
** leaving the commented leading junk in the file for future reference
**
** it announces its conclusions about c programs and shar files on stdout
** it tries to avoid trashing the files if run multiple times
** it has options to test files without modifying them, to back out changes,
** and to force "# " shell comments onto a specified number of lines.
**
** it thinks all c programs begin with "/*"
** and shar files begin with "echo x - "
** or on the line following one or more "#" shell comment lines
**
** usage: comment [options & filenames]
** see the usage() function for details on the options
**
** with Microsoft C -- cl comment.c \msc5\lib\setargv /link /NOE
** under MINIX -- cc -DMINIX -o comment comment.c
**
*/
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#ifdef MSDOS
#include <stdlib.h>
#include <direct.h>
#include <io.h>
#endif
#ifdef MINIX
#define fputs(a, b) fputs(a, b), 0
#endif
#define NOTHING 0
#define CPROG 1
#define SHARFILE 2
#define BUFSZ 256 /* longer than the longest line in a usenet article */
int Line; /* line number starting shar file or c prog */
#ifdef MINIX
main(argc, argv)
int argc;
char **argv;
{
#else
main(int argc, char **argv) {
#endif
FILE *fp;
char *progname = *argv;
char *cp;
int tflag = 0;
int type;
if (--argc) {
while(argc--) {
cp = *++argv;
if (!strncmp(cp, "-t", 2)) {
if (!argc--)
break;
tflag = 1;
cp = *++argv;
}
else if (!strncmp(cp, "-c", 2)) {
if (!argc--)
break;
recomment(*++argv, atoi(cp + 2));
continue;
}
if ((type = scan(cp)) != NOTHING && tflag == 0)
comment(*argv, type);
}
}
else {
usage(progname);
}
exit(0);
}
#ifdef MINIX
usage(name)
char *name;
{
#else
usage(char *name) {
#endif
printf("this program comments out junk ahead of a C program or shar file\n\n");
printf("usage: %s [options & filenames]\n", name);
printf("options: -t tests but does not modify subsequent files\n");
printf(" -c file removes inserted comments\n");
printf(" -clines file inserts \"# \" comments onto lines at the head of file\n");
}
#ifdef MINIX
scan(name)
char *name;
{
#else
scan(char *name) {
#endif
FILE *fp;
char buffer[BUFSZ];
static char starget[] = "echo x - ";
static int slen = sizeof(starget) -1;
static char ctarget[] = "/*";
static int clen = sizeof(ctarget) -1;
int rv = NOTHING;
if (fp = fopen(name, "r")) {
for (Line = 1; fgets(buffer, sizeof(buffer) - 1, fp); Line++) {
if (*buffer == '#') {
rv = SHARFILE;
continue; /* Line++ while the comments last */
}
else if (rv == SHARFILE) {
printf("%s contains a shar file at line %d\n", name, Line);
break;
}
if (!strncmp(buffer, ctarget, clen)) {
rv = CPROG;
if (Line == 1)
continue; /* probably inserted by me - look for another */
printf("%s contains a C comment at line %d\n", name, Line);
break;
}
if (!strncmp(buffer, starget, slen)) {
rv = SHARFILE;
break;
}
}
fclose(fp);
}
else
fprintf(stderr, "unable to open file %s\n", name);
return(rv);
}
#ifdef MINIX
comment(name, type)
char *name;
int type;
{
#else
comment(char *name, int type) {
#endif
FILE *fp1, *fp2;
static char template[9] = "zzXXXXXX";
char tempname[9];
char buffer[BUFSZ];
int line;
if (fp1 = fopen(name, "r")) {
fgets(buffer, sizeof(buffer) - 1, fp1);
if (*buffer == '#' || !strncmp(buffer, "/*", 2)) {
fclose(fp1); /* already commented - bail out */
return;
}
strcpy(tempname, template);
if (mktemp(tempname) == NULL) {
fprintf(stderr, "mktemp() error\n");
exit(1);
}
if ( (fp2 = fopen(tempname, "w")) == NULL) {
fprintf(stderr, "fopen(%s, \"w\") error\n", tempname);
exit(1);
}
for (line = 1; line < Line; line++) {
if (line == 1 && type == CPROG)
my_fputs("/*\n", fp2);
else if (type == SHARFILE) {
if (*buffer == '#')
break;
my_fputs("# ", fp2);
}
my_fputs(buffer, fp2);
fgets(buffer, sizeof(buffer) - 1, fp1);
}
if (type == CPROG)
my_fputs("*/\n", fp2);
my_fputs(buffer, fp2);
while (fgets(buffer, sizeof(buffer) - 1, fp1))
my_fputs(buffer, fp2);
fclose(fp1);
fclose(fp2);
movefile(tempname, name);
}
else
fprintf(stderr, "unable to open file %s\n", name);
}
#ifdef MINIX
recomment(name, nlines)
char *name;
int nlines;
{
#else
recomment(char *name, int nlines) {
#endif
FILE *fp1, *fp2;
static char template[9] = "zzXXXXXX";
char tempname[9];
char buffer[BUFSZ];
int line;
if (fp1 = fopen(name, "r")) {
strcpy(tempname, template);
if (mktemp(tempname) == NULL) {
fprintf(stderr, "mktemp() error\n");
exit(1);
}
if ( (fp2 = fopen(tempname, "w")) == NULL) {
fprintf(stderr, "fopen(%s, \"w\") error\n", tempname);
exit(1);
}
}
if (nlines) {
/* insert "# " comments onto nlines */
for (line = 0; line < nlines; line++) {
if (!fgets(buffer, sizeof(buffer) - 1, fp1))
break;
my_fputs("# ", fp2);
my_fputs(buffer, fp2);
}
while (fgets(buffer, sizeof(buffer) - 1, fp1))
my_fputs(buffer, fp2);
}
else {
fgets(buffer, sizeof(buffer) - 1, fp1);
if (!strncmp(buffer, "/*", 2)) {
/* uncomment C comment block beginning on line 1 */
while (fgets(buffer, sizeof(buffer) - 1, fp1)) {
if (!strncmp(buffer, "*/", 2))
break;
my_fputs(buffer, fp2);
}
while (fgets(buffer, sizeof(buffer) - 1, fp1))
my_fputs(buffer, fp2);
}
else {
/* strip leading "# " from all lines */
do {
if (!strncmp(buffer, "# ", 2))
my_fputs(buffer + 2, fp2);
else
my_fputs(buffer, fp2);
} while (fgets(buffer, sizeof(buffer) - 1, fp1));
}
}
fclose(fp1);
fclose(fp2);
movefile(tempname, name);
}
#ifdef MINIX
movefile(from, to)
char *from, *to;
{
#else
movefile (char *from, char *to) {
#endif
if (remove(to)) {
fprintf(stderr, "problem with remove(\"%s\")\n", to);
exit(1);
}
else if (rename(from, to)) {
fprintf(stderr, "problem with rename(\"%s\", \"%s\")\n", from, to);
exit(1);
}
}
#ifdef MINIX
my_fputs(cp, fp)
char *cp;
FILE *fp;
{
#else
my_fputs(char *cp, FILE *fp) {
#endif
if (fputs(cp, fp)) {
fprintf(stderr, "fputs() error\n");
exit(1);
}
}
#ifdef MINIX
rename(old, new)
char *old, *new;
{
if (link(old, new) < 0)
fprintf(stderr, "problem with link(\"%s\", \"%s\")\n", old, new);
else
unlink(old);
}
remove(old)
char *old;
{
unlink(old);
}
#endifdpi@loft386.UUCP (Doug Ingraham) (10/10/89)
In article <3604@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <2992@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes: > >I resent having to deal with uuencoded files just for Bitnet. > > On the whole, I agree with you. However, an additional advantage of doing > it this way is compress + uuencode saves something like 25% of the bandwidth, > and this is going to be very large, so that is definitely worth something. > Also, with my cleanit program and install shell script, however redundant > they may be, the installation of 1.4b should be relatively easy since the > computer will have to do all the work. > > Andy Tanenbaum (ast@cs.vu.nl) Why not use the btoa and atob programs that come with compress? btoa provides a more compact encoding than uuencode. Is there a problem in using btoa format on bitnet? Here are the numbers on an example I just tried. original length = 82478 compress -b12 = 49454 reduction of 40% uuencode length = 68161 expansion of 27% overall reduction of 17% btoa length = 62673 expansion of 21% overall reduction of 24% It's not a lot better, but it is better. If anyone on a bitnet site that has problems wants to try this out I will get btoa and atob running under minix and give it a shot. -- Doug Ingraham (SysAdmin) Lofty Pursuits (Public Access for Rapid City SD USA) uunet!loft386!dpi
maart@cs.vu.nl (Maarten Litmaath) (10/10/89)
ast@cs.vu.nl (Andy Tanenbaum) writes:
\... As I said, it was
\a bug, but either way, it is not varargs. That has to do with computing
\the address of one paramter from the address of another, and clean() certainly
\does not do that.
Just to set the record straight: I *know* what varargs functions are. When I
read the original article I almost immediately noticed clean() was called once
with 2 parameters and once with 3. My first thought was: hey, is it a varargs
function?
\>Anyway, what's wrong with the shell script?
\People keep calling up P-H asking for the sources to spell and write
I don't get it.
\(shell scripts). Furthermore, I find the shell script somewhat cryptic.
Isn't the spirit of MINIX the spirit of UNIX? Use small, orthogonal tools to
build complex utilities? That includes using existing tools instead of
reinventing wheels.
\>"Sometimes it seems Marvin wrote MINIX while Andy was playing Donald Duck's
\>Playground on Suzanne's computer." (Benno van den Brink)
\I wouldn't write Marvin off quite so fast. He's probably smarter than me.
\I certainly didn't come in 2nd in the Amsterdam (or any other) chess
\tournament for kids when I was 9.
I certainly don't write Marvin off! Besides, wouldn't it be a *compliment*
for him? After all, MINIX *is* quite an achievement. But there is still
work to be done.
Job control. Henry Spencer wrote you didn't object to it *in principle*,
but to the POSIX standard. Perhaps some other scheme would do. Is total
conformance to 1003.1 *that* important to you? I'd rather see an OS with
some job control hooks, than a strictly conforming OS without it.
--
The UNIX Way of doing something [...] is to make it look as much like a filter
as possible. (Richard O'Keefe) | Maarten Litmaath (mcsun!botter!maart)ast@cs.vu.nl (Andy Tanenbaum) (10/10/89)
In article <3630@solo5.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >ast@cs.vu.nl (Andy Tanenbaum) writes: >\>Anyway, what's wrong with the shell script? >\People keep calling up P-H asking for the sources to spell and write > >I don't get it. People call up P-H on the average of perhaps once a week and tell them that MINIX is incomplete because there is no commands/spell.c. My editor then sends me a letter telling what happened and asking me to call or write the customer and help him. I am also instructed to be nice to the customer. All this takes more of my time than I like. Besides, I think the shell script is more cryptic than the program. >Isn't the spirit of MINIX the spirit of UNIX? Use small, orthogonal tools to >build complex utilities? With 160 C programs and 3 shell scripts, I think this principle is stronger in theory than in practice. I think making that 4 instead of 3 does not change much. >Job control. Henry Spencer wrote you didn't object to it *in principle*, >but to the POSIX standard. Perhaps some other scheme would do. Is total >conformance to 1003.1 *that* important to you? If it can be achieved without too much complexity, yes. If there turns out to be some obscure feature which is horrible to implement properly (like Chap 7), I may reconsider. I certainly don't want any extra complexity that isn't required by the standard. Remember, I am a strong believer in St. Exupery's dictum: "Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away." Creeping featurism is what makes Berkeley UNIX ten times bigger than V7, but by no means 10 times better, and certainly not 10 times faster or 10 times easier to understand. However, being a sport, I'll make you the following proposition. If you can write a 1 page procedure to implement some sort of job control like thing, I'll add it. However, there is a catch. You may only add 1 line of code to the rest of the system. You may not add 50 hooks all over the place, in the tty driver, in signal handling, in process termination, in ptrace, in dozens of other places. That is what POSIX requires and what I refuse to touch. Personally, I think a far better and more elgant solution would be virtual screens. You simulate N terminals on one. When you hit ALT-n, the contents of the screen and replaced by that of terminal , and the keyboard is attached to terminal n. In effect, you are timesharing the one screen into n windows. Again, the trick is localize everything so that there are no tentacles all over the place. It won't be easy. Andy Tanenbaum (ast@cs.vu.nl)
thurlow@convex.com (Robert Thurlow) (10/11/89)
ast@cs.vu.nl (Andy Tanenbaum) writes: >Personally, I think a far better and more elgant solution would be virtual >screens. You simulate N terminals on one. When you hit ALT-n, the contents >of the screen and replaced by that of terminal , and the keyboard is attached >to terminal n. In effect, you are timesharing the one screen into n >windows. Again, the trick is localize everything so that there are no tentacles >all over the place. It won't be easy. I wanted to investigate adding this to Minix one point, because I was so pleased with the functionality I could get with it on SCO Xenix. The only thing that is a problem is that the human has to copy text between windows, which is a pain sometimes, but not worth the cruft of trying to automate it. Rob T -- Rob Thurlow - Expatriate Canadian thurlow@convex.com "From the heart of 'The Friendship State'"
rbthomas@athos.rutgers.edu (Rick Thomas) (10/11/89)
> Job control. Henry Spencer wrote you didn't object to it *in principle*, > but to the POSIX standard. Perhaps some other scheme would do. Is total > conformance to 1003.1 *that* important to you? I'd rather see an OS with > some job control hooks, than a strictly conforming OS without it. > -- > Maarten Litmaath (mcsun!botter!maart) Wouldn't multiple login sessions -- each with its own screen image -- implemented in the console driver -- be a much better approach? (What I call "Poor man's windows") What I have in mind is the ability to be working away on something that can't be interrupted and I get an idea that I want to try out, so I hit some key combination like, say, <alt>-F1 and the current screen image is saved away in a RAM buffer. The executing program continues to execute, but it will be put into io-wait state if it attempts to print to the screen or read from the keyboard. I get a brand new clean screen with a "login:" prompt on it. I log in and do my thing. Then if I hit another key combination like, say, <alt>-F2, repeatedly I can cycle thru all the active sessions. Each time a session comes up, it gets it's screen image refreshed from its private RAM buffer. No fuss, no muss, and no need for all the complexity of POSIX job control. What do people think? It should be easy to do. Rick -- Rick Thomas uucp: {ames, att, harvard}!rutgers!jove.rutgers.edu!rbthomas internet: rbthomas@JOVE.RUTGERS.EDU bitnet: rbthomas@zodiac.bitnet Phone: (201) 932-4301
dal@syntel.mn.org (Dale Schumacher) (10/12/89)
rbthomas@athos.rutgers.edu (Rick Thomas) writes... > What I have in mind is the ability to be working away on something that > can't be interrupted and I get an idea that I want to try out, so I hit > some key combination like, say, <alt>-F1 and the current screen image > is saved away in a RAM buffer. The executing program continues to > execute, but it will be put into io-wait state if it attempts to print > to the screen or read from the keyboard. My implementation doesn't suspend the other virtual terminals when you switch. The screen can still be written to even if it is not the one currently being displayed. The keyboard focus is, of course, always tied to the currently visible screen. If you don't want to miss any output while you're looking at another screen, simply ^S (XOFF) the screen before you leave and ^Q (XON) when you get back. I'm not talking about theory here, I actually have this working on the ST. \\ / Dale Schumacher 399 Beacon Ave. \\ / (alias: Dalnefre') St. Paul, MN 55104-3527 >< ...umn-cs!midgard.mn.org!syntel!dal United States of America / \\ "What is wanted is not the will to believe, but the will to find out, / \\ which is the exact opposite." -Bertrand Russell
s1h@sppy00.UUCP (Steven J. Husting) (10/12/89)
-- Steven Husting "What?" OCLC Inc. -Richard Nixon sppy00!s1h.UUCP slh@rcsh.oclc.org
cpm@datlog.co.uk (Paul Merriman) (10/13/89)
>Personally, I think a far better and more elgant solution would be virtual >screens. You simulate N terminals on one. When you hit ALT-n, the contents >of the screen and replaced by that of terminal , and the keyboard is attached >to terminal n. In effect, you are timesharing the one screen into n >windows. Again, the trick is localize everything so that there are no tentacles >all over the place. It won't be easy. > >Andy Tanenbaum (ast@cs.vu.nl) As a user of the wonderful 'screen' utility for BSD systems I can say I'm wholeheartedly in favour of the Virtual Terminal concept. You have all the benefits of a terminal server connection provided in a more readily usable fashion - I actually have a terminal server connection but prefer to run several sessions from the screens to other machines. 'Screen' was actually posted recently and is PD but as it uses socket technology it probably wouldn't be any use to MINIX users. Paul Merriman (cpm@datlog.co.uk)
steve@ntmtka.mn.org (Steve Wahl) (10/13/89)
In article <3604@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <2992@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes: >>I resent having to deal with uuencoded files just for Bitnet. > >On the whole, I agree with you. However, an additional advantage of doing >it this way is compress + uuencode saves something like 25% of the bandwidth, >and this is going to be very large, so that is definitely worth something. I don't believe this is true; I was under the impression that most sites compress everything before they exchange the news with other sites; I know ours does, and I can't imagine that any long-distance site doesn't. And compressing an already compressed file is most always a lose in terms of bandwidth. Top it off - it is a pain. This has been discussed in many other groups before, and what I state here is usually the conclusion. --> Steve -- Steve Wahl Northern Telecom, Inc. (612) 932-8079 S-100, 9701 Data Park steve@ntmtka.mn.org Minnetonka, MN 55343 {rosevax,bungia}!ntmtka!steve
mike@nixba.UUCP (Mike Lyons) (10/13/89)
In article <3539@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >3. If you promise to write a lint for MINIX, I promise to use it. won't any old lint do, or do you try to do all minix development exclusively within minix? by the way, although fprintf *does* take a variable number of args, line 92 is *still* bogus :-) fprintf("cleanit: write error on %s\n", file); (a new first arg stderr should be inserted) Peace, Mike -- Michael D. Lyons phone: +49 911 6415 609 Nixdorf Computer AG fax: +49 911 6415 105 Geschaeftstelle fuer BA e-mail: mike@nixba.uucp Donaustrasse 36 :: D-8500 Nuernberg 60 :: Federal Republic of Germany