BUGS list

BUGS list

[Geoff Wing]

Heyla, how much of Etc/BUGS is still valid?

>From BUGS:
"single_line_zle does not go to the next line after return."

What machine is this on?  Works fine for me.


"Only waste is stored in the variable given to read -k if there is a
 character immediately avaible for reading. In this case that character
 is not even removed from the input buffer. Try
 % sleep 1 ; read -k ch
 and press a key while it's sleeping then examine $ch."

What machine? What situations? Also works fine for me.
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: BUGS list

[Zoltan Hidvegi]

Geoff Wing wrote:
> >From BUGS:
> "single_line_zle does not go to the next line after return."
> 
> What machine is this on?  Works fine for me.
> 
> 
> "Only waste is stored in the variable given to read -k if there is a
>  character immediately avaible for reading. In this case that character
>  is not even removed from the input buffer. Try
>  % sleep 1 ; read -k ch
>  and press a key while it's sleeping then examine $ch."
> 
> What machine? What situations? Also works fine for me.

These bugs are already fixed.  I have posted several updates to the BUGS file
but they did not find their way to the distribution.

Bye,

  Zoltan

Re: BUGS list

[Richard Coleman]

> > What machine is this on?  Works fine for me.
> > 
> > "Only waste is stored in the variable given to read -k if there is a
> >  character immediately avaible for reading. In this case that character
> >  is not even removed from the input buffer. Try
> >  % sleep 1 ; read -k ch
> >  and press a key while it's sleeping then examine $ch."
> > 
> > What machine? What situations? Also works fine for me.
> 
> These bugs are already fixed.  I have posted several updates to the BUGS file
> but they did not find their way to the distribution.

oops...  sorry about that.  I'll update it now.  Sometimes it difficult
to keep all this straight.

rc

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