From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id TAA00398 for <mason@primenet.com.au>; Wed, 7 Aug 1996 19:02:31 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id EAA13869; Wed, 7 Aug 1996 04:59:15 -0400 (EDT)
Resent-Date: Wed, 7 Aug 1996 04:59:15 -0400 (EDT)
Message-Id: <199608070857.KAA23899@hydra.ifh.de>
To: Jeff Blank <jfblank@mtu.edu>,
        zsh-workers@math.gatech.edu (Zsh hackers list)
Subject: Re: 3.0-pre6 expansion bug 
In-reply-to: "jfblank@mtu.edu"'s message of "Tue, 06 Aug 1996 21:45:08 MET."
             <Pine.LNX.3.93.960806213124.31054A-100000@bullwinkle.tc.it.mtu.edu> 
Date: Wed, 07 Aug 1996 10:57:55 +0200
From: Peter Stephenson <pws@ifh.de>
Resent-Message-ID: <"LAnw6.0.eO3.Zh52o"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1930
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

jfblank@mtu.edu wrote:
> I first noticed this in 2.6b13...
> 
> bullwinkle<275>:Src/zsh -f
> bullwinkle% cat ~/file
> [...]
> bullwinkle% <!$<TAB>
> correctly expands to
> bullwinkle% <~/file
> [...]
> bullwinkle% less<!$
> incorrectly expands to
> bullwinkle% less~/.zlogin
> 
> Then, right before my next prompt, I get
> 
> Attempt to inungetc() at start of input.

This fixes this particular bug, at any rate.

What's happening is that after expanding !$ to the filename, the lexer
decides the next character isn't a digit, so it's not interested in
parsing a numeric glob; it therefore pushes the first filename
character back into the input.  Then the fun starts: since it's a
redirection, the lexer decides it can stop and return the first word
on the line, so it tries to push the `<' back onto the input as well.
Unfortunately it couldn't because the input stack has just had the
history expansion pushed onto it so there was no way of pushing back
the `<', hence the message.

I've handled this as a special case:  the character is itself pushed
onto the stack for rereading.  This doesn't happen very often ---
judging by the lack of previous bug reports --- so this should be fine.

*** Src/input.c.unget	Wed Aug  7 10:39:23 1996
--- Src/input.c	Wed Aug  7 10:47:11 1996
***************
*** 359,369 ****
  	    inbufleft++;
  	}
  #ifdef DEBUG
!         else {
  	    /* Just for debugging */
  	    fprintf(stderr, "Attempt to inungetc() at start of input.\n");
  	}
  #endif
      }
      if (inalstacktop > inalstack)
  	inalrestore();
--- 359,380 ----
  	    inbufleft++;
  	}
  #ifdef DEBUG
!         else if (!(inbufflags & (INP_ALIAS|INP_CONT))) {
  	    /* Just for debugging */
  	    fprintf(stderr, "Attempt to inungetc() at start of input.\n");
  	}
  #endif
+ 	else {
+ 	    /*
+ 	     * The character is being backed up from a previous input stack
+ 	     * layer.  However, there was an expansion in the middle, so we
+ 	     * can't back up where we want to.  Instead, we just push it
+ 	     * onto the input stack as an extra character.
+ 	     */
+ 	    char *cback = (char *)zcalloc(2);
+ 	    cback[0] = (char) c;
+ 	    inpush(cback, INP_FREE|INP_CONT);
+ 	}
      }
      if (inalstacktop > inalstack)
  	inalrestore();

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.