1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
-----------------
KNOWN BUGS IN ZSH
-----------------
When a shell is exited from within a function, the only EXIT trap which is
run is the one for the function itself, if any. In particular, an EXIT
trap set for the shell itself will not be executed in this case.
------------------------------------------------------------------------
On some terminals, display of lines with exactly 80 characters is
problematic. zsh assumes that the terminal does not print an extra
newline in this case, but some terminals (e.g. aixterm) do.
------------------------------------------------------------------------
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.
------------------------------------------------------------------------
If you suspend "man", zle seems to get into cooked mode. It works ok
for plain "less".
It is not specific neither to man nor to zsh.
E.g. call the following program foo:
#include <sys/wait.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int status;
if (!fork()) /* child */
execvp(argv[1], argv + 1);
else /* parent */
wait(&status);
}
Then if you suspend
% foo less something
from zsh/bash, zle/readline gets into cooked mode.
------------------------------------------------------------------------
The pattern %?* matches names beginning with %? instead of names with at
least two characters beginning with %. This is a hack to allow %?foo job
substitution without quoting. This behaviour is incompatible with sh
and ksh and may be removed in the future. A good fix would be to keep
such patterns unchanged if they do not match regardless of the state of
the nonomatch and nullglob options.
------------------------------------------------------------------------
Numeric ranges are still too greedy with using characters; for example,
<1-1000>33 will not match 633 because the 633 matches the range. Some
backtracking will be necessary. (This is believed fixed as of 3.1.6.)
------------------------------------------------------------------------
|
