test patches

test patches

[Zoltan Hidvegi]

You can find patches for zsh-3.1.2-test1 and zsh-3.0.3-test5 on
ftp://ftp.cs.elte.hu/pub/zsh/testing/, in files

  45860 May  9 09:14 zsh-3.0.3-test5.diff.gz
 145337 May  9 09:09 zsh-3.1.2-test1.diff.sh.gz

zsh-3.1.2-test1.diff.sh.gz is a script which should be run in the zsh-3.1.1
top directory (you can use zsh <(zsh-3.1.2-test1.diff.sh.gz) to run the
script).

An interesting change is that commands like ((echo foo); echo bar) now work
(zsh used to think that this is an arithmetic expansion).

I have made an other change I'm not completely sure about.  I removed the
errflag = 1 assignment on interrupt of the foreground process from
printjob().  This is handled in update_job().  I do not understand why was
it there in printjob() (and from the deleted comments it seems that Peter
did not know it either).

This version of zsh now seems to run debian startup/shutdown scripts
without problems, but I haven't tried any dpkg runs yet.  Unfortunately
some Linux programs assume that /bin/sh has brace expansion so I'm thinking
about making ignorebraces off by default even in sh mode.  bash, ksh93 and
pdksh all do brace expansion by default.  The problem is that in zsh if
ignorebraces is not set, commands like `{foo' or `foo bar}' do not work.

Zoltan

Re: test patches

[Hrvoje Niksic]

Zoltan Hidvegi <hzoli@ny.frontiercomm.net> writes:

> This version of zsh now seems to run debian startup/shutdown scripts
> without problems, but I haven't tried any dpkg runs yet.  Unfortunately
> some Linux programs assume that /bin/sh has brace expansion so I'm thinking
> about making ignorebraces off by default even in sh mode.  bash, ksh93 and
> pdksh all do brace expansion by default.  The problem is that in zsh if
> ignorebraces is not set, commands like `{foo' or `foo bar}' do not
> work.

Would it be too much work (or too much braindamage, for that matter),
to do what bash does in cases of `{foo' and `foo bar}' -- i.e. pretend
the expansion is not there.

bash$ {foo
bash: {foo: command not found
bash$ foo bar}
bash: foo: command not found

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Good pings come in small packets.

Re: test patches

[Bart Schaefer]

On May 9,  3:42am, Zoltan Hidvegi wrote:
} Subject: test patches
}
} I have made an other change I'm not completely sure about.

While we're on that subject, when did integer-typed variables start to
prefix their values with their base?

E.g. I had some old, working shell functions that assumed that:

zsh% typedef -i 16 x
zsh% x=255
zsh% echo $x
FF

But I happened to run one of those functions in 3.0.3-test4 and got `16#FF'
instead of `FF'.  Everything else was downhill from there.  Is there some
way to prevent this behavior?  (Other than the bizarre-looking ${x#*#}.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts        http://www.nbn.com/people/lantern

Re: test patches

[Zefram]

Zoltan Hidvegi wrote:
>                                                          Unfortunately
>some Linux programs assume that /bin/sh has brace expansion so I'm thinking
>about making ignorebraces off by default even in sh mode.

Please don't.  Those Linux programs are assuming that sh is really bash,
and are therefore broken.  In my experience, considering how simple they
are to fix, authors are usually willing to fix them.

-zefram

Re: test patches

[Zoltan T. Hidvegi]

Hrvoje Niksic wrote:
> Would it be too much work (or too much braindamage, for that matter),
> to do what bash does in cases of `{foo' and `foo bar}' -- i.e. pretend
> the expansion is not there.
>
> bash$ {foo
> bash: {foo: command not found
> bash$ foo bar}
> bash: foo: command not found

No, it would not be too much work.  In fact, zsh now contains extra code to
aupport {foo and bar}.  There was a beta release before 3.0.0 where I tried
to drop this but there were too much complains.  Maybe we need an option
like BROKEN_ZSH_BRACES :-).  The problem is that some old zsh scripts
define functions as foo(){echo bar} instead of foo () { echo bar; }.

Zoltan

Re: test patches

[Zoltan T. Hidvegi]

Zefram wrote:
> Zoltan Hidvegi wrote:
> >                                                          Unfortunately
> >some Linux programs assume that /bin/sh has brace expansion so I'm thinking
> >about making ignorebraces off by default even in sh mode.
>
> Please don't.  Those Linux programs are assuming that sh is really bash,
> and are therefore broken.  In my experience, considering how simple they
> are to fix, authors are usually willing to fix them.

You are right, but if I want to tell people that here is zsh, just link it
to sh and use it, they will complain that it brakes this and that.  Fixing
a program is easy, but finding all programs depending on this feature is
difficult, and even if you do find everything, old installations will still
have some old broken binaries.  For the same reason has zsh so much obscure
bug compatibility code.  And some Linux developers simply tell you, that if
/bin/sh is not bash, then your Linux system is broken anyway.

Perhaps there are'n too many programs using brace expansion, but I have
even seen a program using this in a system() libc call )-:.

Zoltan

Re: test patches

[Zefram]

Zoltan T. Hidvegi wrote:
>You are right, but if I want to tell people that here is zsh, just link it
>to sh and use it, they will complain that it brakes this and that.

Having brace expansion on in sh mode potentially breaks some programs that
depend on POSIX.  We do intend zsh to be a POSIX conformant sh, don't we?

>                         And some Linux developers simply tell you, that if
>/bin/sh is not bash, then your Linux system is broken anyway.

Anyone that tells you that is mistaken.  Even the Linux kernel Makefiles
don't assume that /bin/sh is bash.

-zefram

Re: test patches

[Zoltan T. Hidvegi]

Zefram wrote:
> Having brace expansion on in sh mode potentially breaks some programs that
> depend on POSIX.  We do intend zsh to be a POSIX conformant sh, don't we?

Yes.  Unfortunately I do not have the final POSIX.2, just an early draft.
bash, pdksh and ksh93 also intend to be POSIX conformant, and they all have
brace expansion by default.

> >                         And some Linux developers simply tell you, that if
> >/bin/sh is not bash, then your Linux system is broken anyway.
>
> Anyone that tells you that is mistaken.  Even the Linux kernel Makefiles
> don't assume that /bin/sh is bash.

You do not have to convice me, I was probably the first who started using
zsh as /bin/sh more than two years ago.  There was a long thread about
related issues in the Debian development mailing list (which I do not read,
I just saw this thread on the web mirror of the list), and there I saw
posts expressing such opimions.  The thread was about the bash-2.0 upgrade,
and mostly concerned about the broken ((foo); bar) syntax in bash-2.0
(which will be fixed in the next bash as well as the next zsh release).

Zoltan

Re: test patches

[Bart Schaefer]

Some remarks on the 3.0.3-test5 patch:

The FAQ diff isn't included.  No biggie, but people should be aware that
they'll still have last December's FAQ if all they do is patch.

I'm curious:  What's the point of removing functions like setcurjob()
and inlining their code in the function that calls them?  We're surely
not all that worried about function call overhead, and it seems to me
that it makes future changes more difficult (or at least potentially
larger diffs).  Even if the function is only called in one place, it's
preferable to work towards small, single-purpose functions, isn't it?
(It also makes stack traces without full debugging symbols easier to
interpret.)  [setcurjob happened a while ago, but I just noticed it.]

There still doesn't appear to be a test in init.c for the case where
the system supports TIOCGWINSZ but the rows and columns value in the
shttyinfo.winsize structure are both zero.  In that case we ought to
be using the row and column sizes from the termcap or terminfo entry?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts        http://www.nbn.com/people/lantern

Re: test patches

[Zoltan Hidvegi]

> Some remarks on the 3.0.3-test5 patch:
> 
> The FAQ diff isn't included.  No biggie, but people should be aware that
> they'll still have last December's FAQ if all they do is patch.

The FAQ diff is bigger than the FAQ itself, and that's only a test patch.
I'll include it in the final patch.

> I'm curious:  What's the point of removing functions like setcurjob()
> and inlining their code in the function that calls them?  We're surely

It was not removed, just moved to jobs.c.  You can notice that pieces of
builtins.c are trying to find new place.  In zsh-3.0.3 builtin.c is 145464
bytes long, while in 3.1.2 it is only 84611 bytes.

> There still doesn't appear to be a test in init.c for the case where
> the system supports TIOCGWINSZ but the rows and columns value in the
> shttyinfo.winsize structure are both zero.  In that case we ought to
> be using the row and column sizes from the termcap or terminfo entry?

The test is done in zlevarsetfn() in params.c.

Zoltan

Re: test patches

[Bart Schaefer]

On May 10,  1:48pm, Zoltan Hidvegi wrote:
} Subject: Re: test patches
}
} > There still doesn't appear to be a test in init.c for the case where
} > the system supports TIOCGWINSZ but the rows and columns value in the
} > shttyinfo.winsize structure are both zero.  In that case we ought to
} > be using the row and column sizes from the termcap or terminfo entry?
} 
} The test is done in zlevarsetfn() in params.c.

Yeah, but all it does is pretend the terminal is very narrow and set the
imaginary columns and lines to 80 and 24.

A zero value in shttyinfo.winsize is a special indicator from the driver
that it doesn't know what the window size is.  The actual window shape
in that case is read from the termcap by most applications.  It doesn't
mean that the window is actually zero sized.

I should have remembered this when I was fiddling with this code some
months ago; I remembered it a few weeks later when Geoff was hacking on
the zle refresh stuff, and mentioned it on the list.

The same test should probably go in adjustwinsize, but I don't think the
driver ever sends SIGWINCH when it doesn't know the window shape, so it
isn't as important there.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts        http://www.nbn.com/people/lantern

Re: test patches

[Zoltan Hidvegi]

> } > There still doesn't appear to be a test in init.c for the case where
> } > the system supports TIOCGWINSZ but the rows and columns value in the
> } > shttyinfo.winsize structure are both zero.  In that case we ought to
> } > be using the row and column sizes from the termcap or terminfo entry?

The patch below implements this.  It does not work for non-interactive
shells since termcap initialisation is delayed in that case.  There is no
perfect solution for that: early termcap initialisaton can cause SIGTTOU on
some operating systems when the shell is backgrounded.  We cannot adjust
COLUMNS/LINES later when termcap is actually initialised since that will
unexpectedly change the values set by the user (for example the telnetd on
Solaris does not support window size and the li terminfo entry is 60 for
xterm, so one may want to set LINES to 24 on startup and does not want to
change it back to the wrong termcap value).

Zoltan


--- Src/globals.h	1997/05/05 07:17:48	3.1.2.9
+++ Src/globals.h	1997/05/04 05:18:36
@@ -644,6 +644,10 @@
 EXTERN int tclen[TC_COUNT];
  
 EXTERN char *tcstr[TC_COUNT];
+
+/* Values of the li and co entries */
+
+EXTERN int tclines, tccolumns;
  
 /* names of the strings we want */
 #ifdef GLOBALS
--- Src/init.c	1997/05/05 06:17:46	3.1.2.9
+++ Src/init.c	1997/05/11 04:12:59
@@ -360,6 +360,9 @@
 	/* check whether terminal has automargin (wraparound) capability */
 	hasam = tgetflag("am");
 
+	tclines = tgetnum("li");
+	tccolumns = tgetnum("co");
+
 	/* if there's no termcap entry for cursor up, use single line mode: *
 	 * this is flagged by termflags which is examined in zle_refresh.c  *
 	 */
@@ -519,8 +522,9 @@
     setiparam("COLUMNS", shttyinfo.winsize.ws_col);
     setiparam("LINES", shttyinfo.winsize.ws_row);
 #else
-    setiparam("COLUMNS", 80);
-    setiparam("LINES", 24);
+    /* Using zero below sets the defaults from termcap */
+    setiparam("COLUMNS", 0);
+    setiparam("LINES", 0);
 #endif
 
 #ifdef HAVE_GETRLIMIT
--- Src/params.c	1997/05/06 05:31:12	3.1.2.10
+++ Src/params.c	1997/05/11 04:05:43
@@ -1253,14 +1253,14 @@
 {
     if ((long *)pm->u.data == & columns) {
 	if(x <= 0)
-	    x = 80;
+	    x = tccolumns > 0 ? tccolumns : 80;
 	if (x > 2)
 	    termflags &= ~TERM_NARROW;
 	else
 	    termflags |= TERM_NARROW;
     } else if ((long *)pm->u.data == & lines) {
 	if(x <= 0)
-	    x = 24;
+	    x = tclines > 0 ? tclines : 24;
 	if (x > 2)
 	    termflags &= ~TERM_SHORT;
 	else

Re: test patches

[Andrej Borsenkow]

On Fri, 9 May 1997, Zoltan Hidvegi wrote:

> You can find patches for zsh-3.1.2-test1 and zsh-3.0.3-test5 on
> ftp://ftp.cs.elte.hu/pub/zsh/testing/, in files
> 

Doc/zshmodules.1 is missed from zsh-3.1.2-test1 (I haven't tried 3.0.3); 
thus, make fails if yodl is not installed (and of course no manual to
modules :-(

Also, is zle builtin documented anywhere?

There remains the long-standing problem: our system doesn't have shared
libtermcap, and libzsh doesn't compile. Any real arguments against linking
libzsh with $(LIBS)?

greetings

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Re: test patches

[Zefram]

Andrej Borsenkow wrote:
>Also, is zle builtin documented anywhere?

In zshbuiltins(1), for the moment.

-zefram

Re: test patches

[Andrej Borsenkow]

On Mon, 12 May 1997, Zefram wrote:

> Andrej Borsenkow wrote:
> >Also, is zle builtin documented anywhere?
> 
> In zshbuiltins(1), for the moment.
> 

To be shure, it is in Doc/Zsh/builtins.yo. No chance to get it without
yodl :-(

greetings

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Re: test patches

[Zefram]

Andrej Borsenkow wrote:
>To be shure, it is in Doc/Zsh/builtins.yo. No chance to get it without
>yodl :-(

I thought zshbuiltins.1 was being distributed in the source releases.

And yodl source is pretty readable anyway.

-zefram

Re: test patches

[Zoltan T. Hidvegi]

Zefram wrote:
> Andrej Borsenkow wrote:
> >To be shure, it is in Doc/Zsh/builtins.yo. No chance to get it without
> >yodl :-(
>
> I thought zshbuiltins.1 was being distributed in the source releases.
>
> And yodl source is pretty readable anyway.

The test patch does not contain patches to the generated manual.  The final
patch and the source distribution will of course include the patches for
zshbuiltins.1.  Of course you can always get yodl from
ftp://ftp.icce.rug.nl/pub/unix/ and format the documentation yourself.  It
is really easy to install.

Zoltan

Re: test patches

[Zoltan Hidvegi]

I wrote:
> > } > There still doesn't appear to be a test in init.c for the case where
> > } > the system supports TIOCGWINSZ but the rows and columns value in the
> > } > shttyinfo.winsize structure are both zero.  In that case we ought to
> > } > be using the row and column sizes from the termcap or terminfo entry?
> 
> The patch below implements this.  It does not work for non-interactive

That patch does not work apply for zsh-3.0.3-test5.  Here is a patch for
zsh-3.0.3-test5.

Zoltan


--- Src/globals.h	1997/04/25 05:53:45	3.0.2.4
+++ Src/globals.h	1997/05/11 05:04:53
@@ -603,6 +603,10 @@
 EXTERN int tclen[TC_COUNT];
  
 EXTERN char *tcstr[TC_COUNT];
+
+/* Values of the li and co entries */
+
+EXTERN int tclines, tccolumns;
  
 /* names of the strings we want */
 #ifdef GLOBALS
--- Src/init.c	1997/04/20 07:24:12	3.0.2.4
+++ Src/init.c	1997/05/11 05:04:53
@@ -441,6 +441,9 @@
 	/* check whether terminal has automargin (wraparound) capability */
 	hasam = tgetflag("am");
 
+	tclines = tgetnum("li");
+	tccolumns = tgetnum("co");
+
 	/* if there's no termcap entry for cursor up, use single line mode: *
 	 * this is flagged by termflags which is examined in zle_refresh.c  *
 	 */
@@ -599,8 +602,9 @@
     setiparam("COLUMNS", shttyinfo.winsize.ws_col);
     setiparam("LINES", shttyinfo.winsize.ws_row);
 #else
-    setiparam("COLUMNS", 80);
-    setiparam("LINES", 24);
+    /* Using zero below sets the defaults from termcap */
+    setiparam("COLUMNS", 0);
+    setiparam("LINES", 0);
 #endif
 
     /* create hash table for multi-character emacs bindings */
--- Src/params.c	1997/04/25 05:18:50	3.0.2.7
+++ Src/params.c	1997/05/11 05:13:35
@@ -1235,23 +1235,19 @@
 zlevarsetfn(Param pm, long x)
 {
     if ((long *)pm->data == & columns) {
+	if(x <= 0)
+	    x = tccolumns > 0 ? tccolumns : 80;
 	if (x > 2)
 	    termflags &= ~TERM_NARROW;
-	else {
+	else
 	    termflags |= TERM_NARROW;
-	    if (x <= 0)
-		x = 80;		/* Arbitary, but same as init.c */
-	    else
-		x = 2;
-	}
     } else if ((long *)pm->data == & lines) {
+	if(x <= 0)
+	    x = tclines > 0 ? tclines : 24;
 	if (x > 2)
 	    termflags &= ~TERM_SHORT;
-	else {
+	else
 	    termflags |= TERM_SHORT;
-	    if (x <= 0)
-		x = 24;		/* Arbitrary, but same as init.c */
-	}
     }
 
     *((long *)pm->data) = x;