[comp.os.minix] 1.3c /bin/sh bug? + update notes

bob@dhw68k.cts.com (Bob Best) (10/13/88)

Minix 1.3c is up and running on an AT-286 clone (Atronics) using a 4 Mb
partition on a Seagate 4038 (fsck and fdisk patched for 5 heads.)
The installed system should be up to date (using the fix for bootblok.s and
the closing comment on console.c.)
The library is fully 1.3c and was used to generate the full set of 1.3c
commands as well as the entire boot floppy.

All compilation was done using the 1.1 compiler passes except for asld 1.2.
Has ast ever posted .uue formatted copies of the other 1.2 compiler
passes?  Apart from the nuisance of having to manually patch cc.c to
restore the V_FLAG support, I am concerned about bugs and relative
inefficiency of the 1.1 compiler.  The posting of Erik Baalbergen
(1573@botter.cs.vu.nl) bears this out.  With the recent barrage of
updates, I don't think that it is unreasonable to 'complete the upgrade' by
posting these compiler passes.  If this has already been done, could someone
please indicate the message-id for retrieval at bugs.nosc.mil.  The last
I heard, the only way for 1.1 users to receive the 1.2 compiler passes
was by purchasing the entire 1.2 compiler sources for $99.95.

Anyway, using the above configuration, I have encountered the following
bug using sh.  In a seemingly random fashion, the shell will occasionally
(about 33% of the time) fail to properly parse the 'for' keyword.  After
typing in a 'for i in ...' line at the PS1 prompt and hitting return, instead
of PS2 I get 'for: not found'.  Has anybody else encountered this?  I
have reached the point where I cringe at the mere thought of entering
a long 'for i in ...' at the prompt in anticipation of having to type
it in all over again.  I don't want to have to invoke the editor to handle
every little 'for' script.  This is using crc verified 1.3c shell sources.

On the subject of crc verification, here is a listing of the status of my
1.3c update:

commands/file.c		size 2878 should be 3220 (patch says missing 19 lines)
	I started with the original posting (707@ast.cs.vu.nl) - runs ok
commands/ls.c		size ok - bad crc (27927 should be 49285)
	This compiled and runs - must be mangled white space (I hope!)
	I started with ls.c on the 1.1 distribution disks
commands/vol.c		size 2965 should be 2966
	The 2nd posting of this failed like the first - there must be
	a control character that was stripped by the net - compiled ok
tools/fsck.c		size 45446 should be 45901 (missing 19 lines)
	Does anybody have a verified copy of this - I manually applied
	the patches but came up 19 lines short - runs ok

That's not too bad.  Of course, I've spent perhaps 25 hours applying patches,
transferring files, building the library, compiling sources, installing
the system.  Did I say 25, it's probably closer to 100.  Of course, I
saved $39.95 :-)  Well, I never thought my time was very valuable in a
monetary sense.  This proves I'm right.  It should go faster next time,
having picked up a few tricks on the way to help automate the process, and
Larry Wall's patch program didn't hurt any.
In all seriousness, I feel that minix has pioneered the future for
the process of supporting the maintenance and upgrade of developing
systems.  The many hours spent have been well worth the effort and I would
gladly do it again.  I express my gratitude to Andy and all the rest of
the dedicated minix supporters who have made this possible.

Thanks, Bob
-- 
Bob Best
uucp: ...{trwrb,hplabs}!felix!dhw68k!bob	InterNet: bob@dhw68k.cts.com

bob@dhw68k.cts.com (Bob Best) (10/14/88)

As a follow-up to my previous posting regarding the /bin/sh bug, I
have isolated the problem to the following sequence of keystrokes:

I am at the PS1 prompt and hit 'DEL', that is, generate a SIGINT.  I
receive a new PS1 prompt.  I type 'for i in ...' and RETURN, and get
'for: not found'.  It is immaterial whether I typed anything prior to hitting
'DEL'.  The same thing happens for other keywords such as while, until,
etc.  It seems that the SIGINT handler leaves the parser in an unusual
state.  In any event, this is the only sequence that seems to cause the
problem.  Hitting '@' = KILL does not cause a problem and provides a
temporary work around.

Bob
-- 
Bob Best
uucp: ...{trwrb,hplabs}!felix!dhw68k!bob	InterNet: bob@dhw68k.cts.com