Re: yet another undesired 3.1.5-pws-15 change

Re: yet another undesired 3.1.5-pws-15 change

[Sven Wischnowsky]

Timothy J Luoma wrote:

> 3.1.5-pws-15
> 
> #cd $la[tab] gives me
> 
> # cd $lapps[spacehere][cursor here]
> 
> how can I get the 3.1.4 behavior back?

By applying the patch below.

> ps -- there seem to be a LOT of these types of changes in 3.1.5....

Please name them, because...

> I wish  
> there were more consideration given to keeping things consistent for those  
> who upgrade... changing the way things behave and making the user reconfigure  
> everything is not a good thing...

...of course, we (w.r.t. the completion code: I) tried to keep the old
behavior, but there were a lot of changes in the code needed for the
new features (and there are many of them) and so I didn't manage to do
so in some cases.

Again: if you find things that behave differently now, and if the
change isn't a good thing, please let us know and I'll attempt to fix
it.


As for your other message: I need some more help here since I can't
reproduce it. Can you complete the names that don't appear in the
list? By giving an unambiguous prefix? Only with menucompletion? This
is NextStep (right?): did you get any compiler warnings in
Zle/zle_tricky.c? (Weird question, but I have no idea how what you
described can happen...)


The patch: it's do_single() again, failing to build the expanded path
for the parameter just completed.

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Apr 13 10:32:15 1999
+++ Src/Zle/zle_tricky.c	Fri Apr 23 12:45:52 1999
@@ -6970,10 +6976,20 @@
 		t = 1;
 	    else {
 		/* Build the path name. */
-		p = (char *) zhalloc(strlen(prpre) + strlen(str) +
-				 strlen(psuf) + 3);
-		sprintf(p, "%s%s%s", (prpre && *prpre) ? prpre : "./", str, psuf);
+		if (m->ripre && !*psuf) {
+		    int ne = noerrs;
 
+		    p = (char *) zhalloc(strlen(m->ripre) + strlen(str) + 1);
+		    sprintf(p, "%s%s", m->ripre, str);
+		    noerrs = 1;
+		    parsestr(p);
+		    singsub(&p);
+		    noerrs = ne;
+		} else {
+		    p = (char *) zhalloc(strlen(prpre) + strlen(str) +
+				 strlen(psuf) + 3);
+		    sprintf(p, "%s%s%s", (prpre && *prpre) ? prpre : "./", str, psuf);
+		}
 		/* And do the stat. */
 		t = (!(sr = ztat(p, &buf, 0)) && S_ISDIR(buf.st_mode));
 	    }

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: yet another undesired 3.1.5-pws-15 change

[Timothy J Luoma]

Replying to message of Fri, 23 Apr 1999 12:59:46 +0200 (MET DST)
	from Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
	regarding ``Re: yet another undesired 3.1.5-pws-15 change''
	
> > ps -- there seem to be a LOT of these types of changes in 3.1.5....
>
> Please name them, because...

OK, I will make sure to mention them.

Earlier OLDPWD didn't behave the same way (it seems to now though)

There's still a problem with my PROMPT:

PROMPT='
---------------------------------------- %t/%T  
----------------------------------------
%S[OLDPWD: $OLDPWD]
   [PWD: %~]%s
%B%n$LOCAL_HOST%b $REMOTE_HOST
'

it produces an extra blank line at the end (unlike 3.1.4)


> > I wish there were more consideration given to keeping things
> > consistent for those who upgrade... changing the way things
> > behave and making the user reconfigure everything is not a good
> > thing...
>
> ...of course, we (w.r.t. the completion code: I) tried to keep the old
> behavior, but there were a lot of changes in the code needed for the
> new features (and there are many of them) and so I didn't manage to do
> so in some cases.

It was my misunderstanding then.  From some offlist replies I got to earlier  
comments, it sounded like "Things change, get over it."  I realize now that  
I should have guessed they were not the voice of authority.



> As for your other message: I need some more help here since I can't
> reproduce it. Can you complete the names that don't appear in the
> list? By giving an unambiguous prefix? Only with menucompletion? This
> is NextStep (right?): did you get any compiler warnings in
> Zle/zle_tricky.c? (Weird question, but I have no idea how what you
> described can happen...)

I don't remember any warnings... well, there were warnings, but I don't  
remember what they were.

I cannot solve it by giving unambiguous filenames:

# ls /
CDROM/              Users/              mach_kernel
LocalApps@          bin/                mach_kernel.OS42
LocalLibrary@       dev@                mach_kernel.nonY2K
Net/                drives/             private/
NextAdmin/          etc@                tmp@
NextApps/           lib/                usr/
NextDeveloper@      lost+found/
NextLibrary/        mach@

(note there is only one "/U")

# ls /U[tab]
# ls /U

# ls /drives/
IBM3/   win95/

# ls /drives/I[tab]
# ls /drives/I

NOTE: I can't build zsh again, I keep getting errors about files that end  
with .pro not existing (ie prompt.pro) and it dies.

I don't know how I did it before.

TjL

Re: yet another undesired 3.1.5-pws-15 change

[Peter Stephenson]

Timothy J Luoma wrote:
> There's still a problem with my PROMPT:
> 
> PROMPT='
> ---------------------------------------- %t/%T  
> ----------------------------------------
> %S[OLDPWD: $OLDPWD]
>    [PWD: %~]%s
> %B%n$LOCAL_HOST%b $REMOTE_HOST
> '
> 
> it produces an extra blank line at the end (unlike 3.1.4)

I didn't dare fix this when I originally spotted it, but I think the answer
is the following.  It doesn't have any immediately obvious ill effects.

--- Src/Zle/zle_refresh.c.pw	Mon Apr 19 09:59:35 1999
+++ Src/Zle/zle_refresh.c	Sun Apr 25 15:30:02 1999
@@ -327,7 +327,7 @@
             vcs = 0;
         else if (!clearflag && lpromptbuf[0]) {
             zputs(lpromptbuf, shout);
-	    if (lpromptw == 0)
+	    if (lpromptw == 0 && lprompth == 1)
 		zputs("\n", shout);	/* works with both hasam and !hasam */
 	}
 	if (clearflag) {
@@ -947,7 +947,7 @@
 		zputc('\r', shout);
 	    tc_upcurs(lprompth - 1);
 	    zputs(lpromptbuf, shout);
-	    if (lpromptw == 0)
+	    if (lpromptw == 0 && lprompth == 1)
 		zputs("\n", shout);	/* works with both hasam and !hasam */
 	}
 	i = lpromptw;

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: yet another undesired 3.1.5-pws-15 change

[Geoff Wing]

Peter Stephenson <pws@ibmth.df.unipi.it> typed:
:Timothy J Luoma wrote:
:> There's still a problem with my PROMPT:
:> PROMPT='
:> ---------------------------------------- %t/%T  
:> ----------------------------------------
:> %S[OLDPWD: $OLDPWD]
:>    [PWD: %~]%s
:> %B%n$LOCAL_HOST%b $REMOTE_HOST
:> '
:> it produces an extra blank line at the end (unlike 3.1.4)
:
:I didn't dare fix this when I originally spotted it, but I think the answer
:is the following.  It doesn't have any immediately obvious ill effects.
:-	    if (lpromptw == 0)
:+	    if (lpromptw == 0 && lprompth == 1)
: 		zputs("\n", shout);	/* works with both hasam and !hasam */

This can't really work, can it.  Say your term width is 80 and your prompt
is 80 chars long, then lpromptw == 0 && lprompth == 2.  Now the cursor is
sitting at the right column and wants to be in the left column, but you've
just avoided putting it there and if you don't have automargin (hasam == 1)
then you're stuffed.  There needs to be a method to differentiate between
having your cursor at 0 and at 80 which probably isn't in there now but
shouldn't be hard to add.  I'll look at doing a patch for this now.

Regards,
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : (Australia) 0413 431 874 <<<new
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

PATCH: 3.1.5-pws-15: multiline prompt

[Geoff Wing]

Heyla,
see discussion under "yet another undesired 3.1.5-pws-15 change"

This should do what you want:

*** prompt.c.org	Thu Nov 12 03:04:38 1998
--- prompt.c	Mon Apr 26 01:15:25 1999
***************
*** 232,238 ****
  		    break;
  		case 'l':
  		    *bp = '\0';
! 		    countprompt(bufline, &t0, 0);
  		    if (t0 >= arg)
  			test = 1;
  		    break;
--- 232,238 ----
  		    break;
  		case 'l':
  		    *bp = '\0';
! 		    countprompt(bufline, &t0, 0, 0);
  		    if (t0 >= arg)
  			test = 1;
  		    break;
***************
*** 678,688 ****
  
  /**/
  void
! countprompt(char *str, int *wp, int *hp)
  {
      int w = 0, h = 1;
      int s = 1;
      for(; *str; str++) {
  	if(*str == Meta)
  	    str++;
  	if(*str == Inpar)
--- 678,692 ----
  
  /**/
  void
! countprompt(char *str, int *wp, int *hp, int overf)
  {
      int w = 0, h = 1;
      int s = 1;
      for(; *str; str++) {
+ 	if(w >= columns) {
+ 	    w = 0;
+ 	    h++;
+ 	}
  	if(*str == Meta)
  	    str++;
  	if(*str == Inpar)
***************
*** 694,705 ****
  	else if(s) {
  	    if(*str == '\t')
  		w = (w | 7) + 1;
! 	    else if(*str == '\n')
! 		w = columns;
! 	    else
  		w++;
  	}
! 	if(w >= columns) {
  	    w = 0;
  	    h++;
  	}
--- 698,712 ----
  	else if(s) {
  	    if(*str == '\t')
  		w = (w | 7) + 1;
! 	    else if(*str == '\n') {
! 		w = 0;
! 		h++;
! 	    } else
  		w++;
  	}
!     }
!     if(w >= columns) {
! 	if (!overf || w > columns) {
  	    w = 0;
  	    h++;
  	}
*** Zle/zle_refresh.c.org	Tue Apr 13 18:07:18 1999
--- Zle/zle_refresh.c	Mon Apr 26 01:11:29 1999
***************
*** 96,101 ****
--- 96,102 ----
      olnct,			/* previous number of lines		    */
      ovln,			/* previous video cursor position line	    */
      lpromptw, rpromptw,		/* prompt widths on screen                  */
+     lpromptwof,			/* left prompt width with real end position */
      lprompth,			/* lines taken up by the prompt		    */
      rprompth,			/* right prompt height                      */
      vcs, vln,			/* video cursor position column & line	    */
***************
*** 141,148 ****
  	    *obuf[ln] = '\0';
      }
  
!     countprompt(lpromptbuf, &lpromptw, &lprompth);
!     countprompt(rpromptbuf, &rpromptw, &rprompth);
  
      if (lpromptw) {
      	memset(nbuf[0], ' ', lpromptw);
--- 142,155 ----
  	    *obuf[ln] = '\0';
      }
  
!     countprompt(lpromptbuf, &lpromptwof, &lprompth, 1);
!     countprompt(rpromptbuf, &rpromptw, &rprompth, 0);
!     if (lpromptwof != winw)
! 	lpromptw = lpromptwof;
!     else {
! 	lpromptw = 0;
! 	lprompth++;
!     }
  
      if (lpromptw) {
      	memset(nbuf[0], ' ', lpromptw);
***************
*** 327,333 ****
              vcs = 0;
          else if (!clearflag && lpromptbuf[0]) {
              zputs(lpromptbuf, shout);
! 	    if (lpromptw == 0)
  		zputs("\n", shout);	/* works with both hasam and !hasam */
  	}
  	if (clearflag) {
--- 334,340 ----
              vcs = 0;
          else if (!clearflag && lpromptbuf[0]) {
              zputs(lpromptbuf, shout);
! 	    if (lpromptwof == winw)
  		zputs("\n", shout);	/* works with both hasam and !hasam */
  	}
  	if (clearflag) {
***************
*** 947,953 ****
  		zputc('\r', shout);
  	    tc_upcurs(lprompth - 1);
  	    zputs(lpromptbuf, shout);
! 	    if (lpromptw == 0)
  		zputs("\n", shout);	/* works with both hasam and !hasam */
  	}
  	i = lpromptw;
--- 954,960 ----
  		zputc('\r', shout);
  	    tc_upcurs(lprompth - 1);
  	    zputs(lpromptbuf, shout);
! 	    if (lpromptwof == winw)
  		zputs("\n", shout);	/* works with both hasam and !hasam */
  	}
  	i = lpromptw;

-- 
Geoff Wing   <gcw@pobox.com>            Mobile : (Australia) 0413 431 874 <<<new
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

success (mostly) pws 17 under NeXTStep 3.3

[Timothy J Luoma]

Using regular NeXT 3.3 'cc' and 'make'

	configure ok
	
	make dies with '.pro' errors

(see http://www.peak.org/~luomat/misc/zsh/zsh-failed.log.gz if you want to  
see all output)
	

Then I had a thought: "try gnumake"

That seemed to work (GNU Make version 3.74)!!

(it failed at the end, after making 'zsh' -- I think because I don't have  
the 'yodl' program -- shouldn't it recognize that and not try and build the  
documentation?)


1) it fixed the $lapps thing (ie I get a / at the end with I do 'cd $la[tab]'

2) it fixed the $PROMPT problem (no more blank space at the end of $PROMPT)



However

It still did not fix the completion problem where directories are being ignored:

#  /bin/ls -F /
LocalApps/              etc/
LocalLibrary/           lib/
Net/                    lost+found/
NextAdmin/              mach@
NextApps/               mach_kernel
NextDeveloper/          mach_kernel.OS42
NextLibrary/            mach_kernel.nonY2K
Users/                  private/
bin/                    tmp/
dev/                    unlabeled/
drives/                 usr/

# /bin/ls -F /U[tab]
# /bin/ls -F /U[cursor still here]

(ALL of the other files in / complete successfully)

BUT maybe there is a clue!

# df /Users
Filesystem            Size  Used  Avail  Capacity Mounted on
/dev/sd1b             994M  437M   457M     49%   /Users

You will notice that /Users is not on / but is a separate partition

Notice that this problem ALSO occurs with /drives/IBM3 which is ALSO a  
mounted directory:

# /bin/ls -F /drives/
IBM3/   win95/

# /bin/ls -F /drives/I[tab]
# /bin/ls -F /drives/I[cursor here]

(note: /drives/win95 is a vmount'd drive)

Now unfortunately this theory dies for /usr/local and /usr/local/Archive  
which are also not on the same partition as / but I still think it is a clue  
of some sort:

Here's my 'df' output:

Filesystem            Size  Used  Avail  Capacity Mounted on
/dev/rsd0h            984M  866M   118M     88%   /drives/win95
/dev/sd2a             392M  128M   225M     36%   /private/swapdisk
/dev/sd1b             994M  437M   457M     49%   /Users
/dev/sd3b             1.3G  840M   359M     70%   /usr/local/Archive
/dev/sd1a             994M  701M   194M     78%   /
/dev/sd3a             1.3G  835M   364M     70%   /usr/local
/dev/sd3c             1.3G   32M   1.1G      3%   /drives/IBM3

And here's something still more interesting.

After I printed that 'df' I then did this:

# mount -t 4.3 /dev/sd0a /drives/kickdisk

and then look what happens now:

# /bin/ls -F /drives/[tab]
# /bin/ls -F /drives/kickdisk/

I don't claim to understand this, but that's all the information I can give  
you.  Here's the final 'df' output:

Filesystem            Size  Used  Avail  Capacity Mounted on
/dev/rsd0h            984M  866M   118M     88%   /drives/win95
/dev/sd0a             6.6M  241K   6.0M      4%   /drives/kickdisk
/dev/sd1a             994M  701M   194M     78%   /
/dev/sd1b             994M  437M   457M     49%   /Users
/dev/sd2a             392M  128M   225M     36%   /private/swapdisk
/dev/sd3a             1.3G  835M   364M     70%   /usr/local
/dev/sd3b             1.3G  840M   359M     70%   /usr/local/Archive
/dev/sd3c             1.3G   32M   1.1G      3%   /drives/IBM3


Any clues appreciated

TjL

Re: success (mostly) pws 17 under NeXTStep 3.3

[Peter Stephenson]

Timothy J Luoma wrote:
> Using regular NeXT 3.3 'cc' and 'make'
> 
> 	configure ok
> 	
> 	make dies with '.pro' errors

That's a strange make, since it hasn't built the .pro files at all, which
are in the dependencies for zsh.mdh.

> (it failed at the end, after making 'zsh' -- I think because I don't have  
> the 'yodl' program -- shouldn't it recognize that and not try and build the  
> documentation?)

In the released version, the documentation is up to date, so that yodl is
only necessary if you alter the files.  You can avoid this here by getting
hold of the .doc.tar file from the same place and untarring it on top of
the source code.

> Users/                  private/
> 
> # /bin/ls -F /U[tab]
> # /bin/ls -F /U[cursor still here]
> 
> (ALL of the other files in / complete successfully)

The code in question is in get_matches_files() in Src/Zle/zle_tricky.c.
The main possibilities are that either zreaddir() and hence readdir() are
missing out Users, in which case ls probably wouldn't show it up, or that
the stat() call later on fails and the directory is skipped.  You can test
the effect of stat() if you have compiled zsh with dynamically loaded
libraries, by using `zmodload stat; stat -rs /Users', or see the main
README file about how to get the file stat.so compiled into the base
executable.  Maybe ls -ld /Users would give a clue, since that's basically
a stat() as well.

Another possibility is that the macro access(..., F_OK) is failing.  The
following shell code should do exactly the same check:

[[ -e /Users ]] && print file exists || print file doesn\'t exist

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy