Suggested PATCH: Reorder README a little

Suggested PATCH: Reorder README a little

[Bart Schaefer]

Generally, bug reports should not include "reporter" output unless the bug
can *not* be reproduced with "zsh -f".  Anybody disagree?

Index: README
===================================================================
diff -c -r1.2 README
--- README	2001/06/01 16:44:28	1.2
+++ README	2001/06/11 16:51:13
@@ -141,15 +141,15 @@
 and coordinated by Peter Stephenson <coordinator@zsh.org>.  Please send
 any feedback and bugs reports to <zsh-workers@sunsite.dk>.
 
-There is a script "reporter" in the subdirectory Util which will print
-out your current shell environment/setup.  If you report a bug, please
-use this script and include the output from sourcing this file.  This way,
-the problem you are reporting can be recreated.
-
-You can help even more if you can reproduce the bug starting zsh with
+Reports are most helpful if you can reproduce the bug starting zsh with
 the -f option.  This skips the execution of local startup files except
 /etc/zshenv.  If a bug occurs only when some options set try to locate
 the option which triggers the bug.
+
+There is a script "reporter" in the subdirectory Util which will print out
+your current shell environment/setup.  If you cannot reproduce the bug
+with "zsh -f", use this script and include the output from sourcing this
+file.  This way, the problem you are reporting can be recreated.
 
 The known bugs in zsh are listed in the file Etc/BUGS.  Check this as
 well as the Frequently Asked Questions (FAQ) list before sending a bug

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Bugs list

[Andrej Borsenkow]

Bart Schaefer wrote:

>  The known bugs in zsh are listed in the file Etc/BUGS.


This one is gone AFAIK:

When interrupting code like the following with ^C:
   while true; do
     sh -c '...'
   done
if the `sh' is executing, zsh does not know that the sh received a ^C and
continues with the next iteration.  This happens for any program which
handles the interrupt, then exits after tidying up; it does not happen for
zsh, which exits directly from the signal handler.  The workaround is to
use ^Z which forks the shell and makes the loop a separate job, then kill
the suspended loop.


-andrej

Re: Bugs list

[Bart Schaefer]

On Jun 11, 10:38pm, Andrej Borsenkow wrote:
} Subject: Bugs list
}
} Bart Schaefer wrote:
} 
} >  The known bugs in zsh are listed in the file Etc/BUGS.

Bart Schaefer quoted the README file, just so it's clear ...
 
} This one is gone AFAIK:
} 
} When interrupting code like the following with ^C:
}    while true; do
}      sh -c '...'
}    done
} if the `sh' is executing, zsh does not know that the sh received a ^C and
} continues with the next iteration.

It still happens for me on RH5.2 where /bin/sh is bash.  The loop

	while true; do
	  sh -c 'more /etc/termcap'
	done

can only be interrupted if you happen to hit bash with the signal before
"more" gets started.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net