housel@ea.ecn.purdue.edu (Peter S. Housel) (07/19/88)
I've had pretty good luck with installing the new 1.3. Using SVC, patch, and a few shell scripts, I was able to almost automate the entire process. Here are a few things I've noted, in addition to what everyone else has said. 1. /bin/mv is still the old, broken one. Try the following, ON A THROWAWAY FILESYSTEM (like the ramdisk in /tmp or a scratch floppy): mkdir dir; mkdir dir/sub1; mv dir dir/sub1 touch foo; mv foo . mv ./. glack! I'm posting a fixed version in the next article which fixes all three of these problems. (The patch in March only fixed the first and third, which are the most serious.) 2. Most of the programs that ran fine with a stack allocation of 2048 bytes before 1.3 now seem to require more than that. (I'm using 3072.) Anybody have any idea why? (These are ordinary programs, most of which don't even use exec().) 3) On the same note, why does the new /bin/sh makefile require 20000 stack instead of 8000? (I've left it at 8000; memory is tight enough already.) 4) /bin/sh globs filenames that begin with "." in a nonstandard way, and always has. "echo *" will include names that begin with "." as long as they aren't named "." or "..", unlike Unix /bin/sh which doesn't include dot-files at all. The fix is trivial. Kind of late to be mentioning this, but... 5) The F9 key ought to require one or more shift keys - it's too easy to hit accidentally all by itself. 6) Here is a shell script to put in /usr/include/MAKELINKS to make the links to the source directory include files. Change the "minix=" line for your source directory. -------------cut------------- #!/bin/sh minix=/usr/src/minix rm -f sgtty.h signal.h minix/callnr.h minix/com.h minix/const.h minix/type.h rm -f sys/stat.h fs/buf.h fs/const.h fs/super.h fs/type.h ln $minix/h/sgtty.h sgtty.h ln $minix/h/signal.h signal.h ln $minix/h/callnr.h minix/callnr.h ln $minix/h/com.h minix/com.h ln $minix/h/const.h minix/const.h ln $minix/h/type.h minix/type.h ln $minix/h/stat.h sys/stat.h ln $minix/fs/buf.h fs/buf.h ln $minix/fs/const.h fs/const.h ln $minix/fs/super.h fs/super.h ln $minix/fs/type.h fs/type.h -------------cut------------- 7) scanf() is still broken. I found a problem with my fix (from January); the latest (a patch relative to 1.3) is also included in my next posting. It looks correct now, but please test it for bugs and manual-page conformance. 8) On all of the UNIX machines I've ever used (various and sundry types), division by zero causes SIGFPE instead of SIGILL. Also, as Marty Leisner pointed out some time ago, the '286 has an illegal-instruction trap vector which could be signaled in this routine. 9) James da Silva's full V7-compatible chmod, which understands symbolic modes as well as octal ones, ought to be included. 10) BE CAREFUL, and set your root password to null after recompiling and installing login.c with the new libc. crypt() has changed (It's much faster, thank goodness) and the encodings are now incompatible with the 1.2 crypt() encodings. You might find yourself without a usable root password. Recompile everything that needs it (login, su, and passwd) and make sure to change things properly. 11) In commands/at.c, there is a line containing fprintf(..., "umask %d", ...). This should be "umask %o". 12) Spell-checking this article, I found that "minix" isn't in /usr/lib/words. Hmmm.... -Peter S. Housel- housel@ei.ecn.purdue.edu ...!pur-ee!housel
ast@cs.vu.nl (Andy Tanenbaum) (07/20/88)
In article <4193@ea.ecn.purdue.edu> housel@ea.ecn.purdue.edu (Peter S. Housel) writes:
[lots of things]
All of Peter's comments seem right on the mark. I'll incorporate them into
the final version as best I can.
One of them is important enough to mention explicitly, however. The shell
stack size was changed to 20000 (see tools/changemem) in 1.3 because I
thought that was needed to handle large shar files. In retrospect, that
may not be the case. I chmem'ed the shell back to 8K, and it seems to
work. This is important because with multiple terminals, shervers, and the
like, there are many more shells around than there used to be and the extra
memory consumed is nontrivial.
I would suggest that everyone set the shell stack to 8K and see what happens.
If problems arise, please post a description of them. If no one runs across
any for a few weeks, I'll use 8K in the final version.
As to chmem of 3072 for small programs, it is possible that the issue here
is a command like ls *.c in, say, commands. The shell expands *.c into a
long list, and puts in on ls' stack. If that is too short==>crash. In 1.2,
ls *.c didn't work in commands; now it does. Thus I am inclined to follows
Peter's lead and change all the 2K stacks to 3k.
Andy Tanenbaum (ast@cs./vu.nl)