ast@cs.vu.nl (Andy Tanenbaum) (01/23/89)
As a reward for working so hard on revising SCO-2, I decided to give myself a little reward: I could hack on MINIX for a few days. What I decided to do is take a look at some of the stuff I'd saved since 1.3 to see what was usable and what was not. A surprising amount was not. A lot of programs didn't compile or work at all. Maybe they were compiled with Turbo C or something else, but in any event, I ended up throwing out a lot. Another class of stuff worked, but didn't seem very useful. What I have done is collected some include files, libraries, and commands from the postings that I intend to include in 2.0 eventually. I have cleaned them up a bit where necessary and installed them on my disk, so they are now part of my "current" system in some sense. I will now post all the programs or cdif listings relative to 1.3, as seems appropriate. This batch contains ten postings: ----- 22 Jan 1989 ----- 0: intro 1: include 2: lib/1 3: lib/2 4: commands/1 (new programs) 5: commands/2 (new programs) 6: commands/3 (cdifs, general) 7: commands/4 (cdifs to make and sh) 8: helpfile/1 9: helpfile/2 I would suggest that everyone incorporate all these changes into his or her system since they will all be part of the "official" system later. However, to avoid the transitive closure problem we had with 1.3a -> 1.3b -> 1.3c -> 1.3d I will post all subsequent fixes relative to the original 1.3, even though that means repeating some stuff. I urge everyone else also to post cdifs relative to 1.3. This will mean that people who don't have time to install this stuff now will be able to skip it if it turns out to be superseded by another posting in half a year (or whatever). Just so we can talk about it, let's call this batch of 10 files V1.4a. (I don't want to call it V2.0a since I regard the main point of 2.0 to go to POSIX, and this stuff is not related to POSIX.) Whatever you do, please keep 1.3 around somewhere, as a base for subsequent cdiffs. The helpfile (2 parts) was derived from the troff input for the revised Appendix C, which I am not going to post. It uses underlining for italics. Bold is lost, but otherwise it seems ok. I deleted all blank lines. I haven't looked at the other directories yet. I am not posting kermit because it is large and probably most people have it. I am not posting stevie because it doesn't work. Has anyone successfully compiled and run stevie on the PC? (It compiles, but acts weird, scrolling pieces of the screen, etc.) Below is my current crc list of "new" stuff: 06967 11902 commands/cc.c 39789 10963 commands/cgrep.c 38268 3504 commands/crc.c 18466 3553 commands/df.c 00854 28023 commands/dosread.c 14404 10277 commands/fdisk.c 47777 2163 commands/fortune.c 44030 1236 commands/id.c 25212 5555 commands/inodes.c 05903 6232 commands/leave.c 18269 3803 commands/look.c 14421 7657 commands/lorder.c 56127 13490 commands/ls.c 18912 1803 commands/make/ReadMe 05068 2100 commands/make/check.c 14691 2457 commands/make/h.h 36629 6577 commands/make/input.c 30757 2366 commands/make/macro.c 32093 4332 commands/make/main.c 05145 7681 commands/make/make.c 02395 500 commands/make/makefile 12045 1795 commands/make/reader.c 06575 5144 commands/make/rules.c 14360 37910 commands/more.c 62793 12224 commands/pr.c 58305 127 commands/sh/makefile 62544 7780 commands/sh/sh.h 15781 14427 commands/sh/sh1.c 33600 11569 commands/sh/sh2.c 12657 17329 commands/sh/sh3.c 62322 12719 commands/sh/sh4.c 05701 10830 commands/sh/sh5.c 26188 92 commands/sh/sh6.c 56930 11497 commands/tar.c 08385 1178 commands/tee.c 32021 7757 commands/term.c 63238 4282 commands/test.c 33210 6668 commands/tsort.c 06541 6422 commands/ttt.c 16741 2472 commands/users.c 54677 919 include/ctype.h 62678 150 include/dir.h 17404 730 include/dirent.h 48518 2336 include/string.h.proto 32943 1310 include/sys_dirent.h 01150 283 include/varargs.h 41860 2552 lib/Makefile.strin 41972 19922 lib/StringTest.c 33354 243 lib/bcmp.c 32674 211 lib/bcopy.c 31389 167 lib/bzero.c 35382 630 lib/closedir.c 51929 934 lib/ctype.c 44383 571 lib/ctype.note 06632 4095 lib/curses.c 18729 621 lib/fdopen.c 45521 4719 lib/fortune.dat 38655 7950 lib/getdents.c 47921 4133 lib/getopt.c 12372 874 lib/help.more 59375 242 lib/index.c 30326 903 lib/lock.c 07002 1061 lib/lrand.c 63728 656 lib/memccpy.c 37913 595 lib/memchr.c 20198 367 lib/memcmp.c 02350 450 lib/memcpy.c 30241 524 lib/memset.c 35610 1541 lib/opendir.c 44386 1122 lib/popen.c 53347 266 lib/rand.c 23754 991 lib/readdir.c 31886 242 lib/rename.c 21848 746 lib/rewinddir.c 49463 245 lib/rindex.c 31934 2965 lib/seekdir.c 42200 1135 lib/signal.c 51754 1024 lib/sleep.c 15321 301 lib/strcat.c 52438 418 lib/strchr.c 05024 637 lib/strcmp.c 63840 257 lib/strcpy.c 38590 444 lib/strcspn.c 54504 317 lib/strerror.c 10923 218 lib/strlen.c 00895 404 lib/strncat.c 10816 755 lib/strncmp.c 61066 387 lib/strncpy.c 53945 422 lib/strpbrk.c 60203 410 lib/strrchr.c 34306 460 lib/strspn.c 10888 635 lib/strstr.c 15885 1103 lib/strtok.c 27132 781 lib/system.c 26851 794 lib/telldir.c 22139 5908 lib/termcap.c 45946 459 lib/utime.c 03799 318 lib/vsprintf.c Please report bugs large and small by posting appropriate messages (and fixes, where possible) to the newsgroup. Andy Tanenbaum (ast@cs.vu.nl)
worsley@ditmela.oz (Andrew Worsley) (01/24/89)
From article <1945@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > I will now post all the programs > or cdif listings relative to 1.3, as seems appropriate. This batch contains Do you mean 1.3a or 1.3c (To me it sounds like you mean 1.3a??) > I am not posting stevie because it doesn't work. Has anyone successfully > compiled and run stevie on the PC? (It compiles, but acts weird, scrolling > pieces of the screen, etc.) The uuencoded version works well on my 1.3c system almost perfect vi (you need to set TERM=minix). All the source I just compiled down to .s files with no problems but then "asld: out of memory" stopped me dead. Things that I did that might have made a difference are 1. remove -O flag, 2. unshar'ed it on my Sun - unsharing it under minix got the file misccmds.c truncated somehow. Andrew Worsley
evans@ditsyda.oz (Bruce Evans) (01/26/89)
I have been running the modified sh for several months and strongly
recommend it. The only new bug I know of is that sh -x does not print
assignment statements properly (try sh -x $HOME/.profile with both shells).
I found the following problems.
Packaging
---------
The diffs for commands/make/* were reversed.
No crc was posted for helpfile. Please use shar even for single files,
since even with perfect communications it's hard to tell how many newlines
are added by news.
Same for floppy.c.cdif. This is actually the full floppy.c with the diff
appended.
Packaging - string functions
----------------------------
Makefile.strin and StringTest.c are in the crc list but were not posted.
I recovered them from the previous posting.
Running make is supposed to produce string.h and memory.h for /usr/include.
This was not done. Instead there is string.h.proto in the include directory.
This needs to be run through sed to produce the other files. Sed doesn't
work with multiple commands separated by ';', so the makefile doesn't work
directly.
The makefile needs to be edited for cc to produce the tester program. It
still has .o files.
This is always a pain when porting Unix programs. Why not just modify cc
and (preferably not) friends so that
.o file == packed assembler file
.s file == human readable assembler file
I won't be doing it since I only use cc for testing.
Lib
---
fdopen.c appears to have 2 fresh bugs. It no longer seeks to the end
for the append case, and sets the IOMYBUF flag even for a null buffer.
termcap.c appears to have some of the bugs fixed by EFTH. I think it
is based on an old ST version.
utime.c doesn't compile. It has an undeclared argument.
The library order is still hard to get right. Now index calls strchr and
rindex calls strrchr. I had to move strchr and strrchr later in the
library to match. Same for time which is now called by utime.
I forgot the -LIB flag when recompiling this library. Why does asld
distinguish extern symbols in the library? I understand why .define is
needed for the library, but why is .globl good enough elsewhere?
The CFLAGS for the library are getting out of hand:
-Di8088 -DCONST='' -DSIZET=int -DVOIDSTAR='char *' -LIB
The strings package really belongs in a directory by itself.
The helpfile for more is called more.help in more.c, but help.more in the
distribution.
I think lib should be reserved for source files and not cluttered up with
help files. It is already too large. On a hard disk I use /usr/sys/lib for
source so there's plenty of room in /usr/lib. It is not clear how to
organize it for floppies. Does anyone still care?
Commands
--------
pr.c clears the L_BUF pointers before it allocates them. The bug shows
up in commands like
ls | pr -t -l1 -5
(same before this supposed fix). It looks like a botched diff - the
indentantion is wrong too. I'm posting my 1 line fix again rather than
mess around with this 5 line fix.
Old cc bugs
-----------
The string tester program showed 2 problems. One involving strerror() is
system-dependent and doesn't matter. The other is that memchr() is broken.
This is because cc is broken. Cc incorrectly thinks
(unsigned char) *"\203" == 0xFF83.
(unsigned char) 0203 is OK. The program ccbug.c shows the bug and its
effect on memchr. I've been bitten by this before when "porting" to cc.
cc -D/user/include -c somefile.c
gives an amusing error message. The -D is a mistyped -I.
#! /bin/sh
# Contents: ccbug.c pr.c.cdif
# Wrapped by sys@besplex on Thu Jan 26 23:00:25 1989
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'ccbug.c' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'ccbug.c'\"
else
echo shar: Extracting \"'ccbug.c'\" \(619 characters\)
sed "s/^X//" >'ccbug.c' <<'END_OF_FILE'
X/* show bug (unsigned char) *"\203" == 0xFF83 */
X
Xchar one[10];
Xchar *scan = "\203";
Xint uc;
Xint ucharwanted;
X
Xmain()
X{
X strcpy(one, "a\203b");
X if (memchr(one, 0203, 3) != one+1) {
X printf("something wrong with memchr:\n");
X printf("memchr(one, 0203, 3) = %04x\n", memchr(one, 0203, 3));
X printf("one + 1 = %04x\n", one + 1);
X }
X ucharwanted = 0203;
X uc = (unsigned char) ucharwanted;
X if ((unsigned char) *scan != uc) {
X printf("no, something wrong with cc:\n");
X printf("(unsigned char) *\"\\203\" = %04x\n",
X (unsigned char) *"\203");
X printf("(unsigned char) 0203 = %04x\n",
X (unsigned char) 0203);
X }
X}
END_OF_FILE
if test 619 -ne `wc -c <'ccbug.c'`; then
echo shar: \"'ccbug.c'\" unpacked with wrong size!
fi
# end of 'ccbug.c'
fi
if test -f 'pr.c.cdif' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'pr.c.cdif'\"
else
echo shar: Extracting \"'pr.c.cdif'\" \(269 characters\)
sed "s/^X//" >'pr.c.cdif' <<'END_OF_FILE'
X*** /user/sys/commands/pr.c Thu Oct 6 02:08:47 1988
X--- pr.c Thu Oct 6 02:15:49 1988
X***************
X*** 468,473 ****
X--- 468,474 ----
X fprintf(stderr,"malloc returned %d\n",ptr);
X exit(1);
X }
X+ memset(ptr, 0, (unsigned)size);
X return (char *) ptr;
X }
X
END_OF_FILE
if test 269 -ne `wc -c <'pr.c.cdif'`; then
echo shar: \"'pr.c.cdif'\" unpacked with wrong size!
fi
# end of 'pr.c.cdif'
fi
echo shar: End of shell archive.
exit 0
Dhall@nosc.NOSC.MIL (Robert R. Hall) (01/27/89)
> Please report bugs large and small by posting appropriate messages (and fixes, > where possible) to the newsgroup. > > Andy Tanenbaum (ast@cs.vu.nl) Ok here is what I have encountered: help doesn't find the man page entry for chgrp. If you delete the underscore, back space characters in the # tag line help will then print the chgrp description. What became of the examples: entries, they disappeared. Since help displays the man_pages on the screen I think all line should be limited to 80 columns. The man_page entry for dosdir says the new dosread.c now works on drive C and D as will as drives A and B, so I tried it on and empty subdirectory on drive C: and got the error message: I/O error: Error 0 This is on a machine which has a RLL disk on drive C, On a machine which as a MFM disk on drive C, I could read the empty subdirector just fine. Next I tried it on drive D: (also a MFM disk) and got: DISK is not DOS Format
rtregn@immd3.informatik.uni-erlangen.de (Robert Regn) (01/27/89)
From article <3907@ditmela.oz>, by worsley@ditmela.oz (Andrew Worsley): > From article <1945@ast.cs.vu.nl>, by ast@cs.vu.nl (Andy Tanenbaum): > >> I am not posting stevie because it doesn't work. Has anyone successfully >> compiled and run stevie on the PC? (It compiles, but acts weird, scrolling >> pieces of the screen, etc.) > > The uuencoded version works well on my 1.3c system almost perfect vi > (you need to set TERM=minix). All the source I just compiled down to > .s files with no problems but then "asld: out of memory" stopped me > dead. Things that I did that might have made a difference are > 1. remove -O flag, 2. unshar'ed it on my Sun - unsharing it under > minix got the file misccmds.c truncated somehow. You shurely have to chmem the stack of asld to maximum value. When compiling with the -O flag, cg (1.2) says Bombed out of codegen on some files (WHATS THAT ??). I have these files compiled withOUT the -O and all others WITH -O flag. The space of asld is even enough to generate a Version with termcap use - the posted binary was without help and termcap. I had never problems with "weird acting" - except probably if I read a big file and add stuff until reaching the buffer limit. Robert Regn rtregn@faui32.uucp rtregn@immd3.informatik.uni-erlangen.de
willy@idca.tds.PHILIPS.nl (Willy Konijnenberg) (01/31/89)
In article <821@faui10.informatik.uni-erlangen.de> rtregn@immd3.informatik.uni-erlangen.de (Robert Regn) writes: >When compiling with the -O flag, cg (1.2) says > Bombed out of codegen >on some files (WHATS THAT ??). I have these files compiled withOUT the -O and >all others WITH -O flag. I found the problems that caused this message. One is struct assignments, the other is complex references, like c->p->s[c->i]. I think this is a pretty nasty bug in the minix c compiler, especially since it doesn't give any decent error messages. (Andy? listening?) I guess the problem is in the optimizer, since Robert says it works without -O. I edited both of these constructs out of the source, and then it compiled fine. I worked with stevie quite a bit, and never had any problems with weird behaviour, except that it will sometimes get stuck when you overflow some or other buffer, that several "nice-to-have" commands are missing and that some commands don't do what they really should. But these are all minor problems that I can live with. When I get my patches cleaned up, I will post a shar of cdiffs. -- Willy Konijnenberg <willy@idca.tds.philips.nl>
poole@forty2.UUCP (Simon Poole) (02/05/89)
ast writes >> Please report bugs large and small by posting appropriate messages (and fixes, >> where possible) to the newsgroup. >> Ok, well `more' won't run as posted on a ST, but the diffs I posted a couple of weeks ago fix that. The diffs to `sh' nearly work on the ST-Minix with a bit of work to get the patches applied properly, except that there is a change in the `eval' function that causes `isassign' (in sh1.c) to be called with a NULL pointer which promptly gets dereferenced, I haven't analysed the problem in depth, but simply changing `isassign' to check for NULL and return the proper return code seems to fix it (at last fast here files!). Some more ST.Minix related bugs: regexp expects a third argument as distributed with ST-Minix, but I yet have to find a program other than `more' that actually sets it, this results in unpredicable behaviour in all programs that use regexp (example: grep '^Subject' * dosen't work). Matter of fact the `cgrep' that is distributed with 1.4 doesn't call regexp with the third argument either! -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------