Another patch to compctl-examples CVS compctl, and a bug?

Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

It's now possible to avoid several external processes in generating the
list of CVS-controlled files in the `cvstargets' function.  The key is
this wonderful "parameter" (boy, is that misnamed) subsitution:

	"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"

This almost bears explaining in and of itself.  The {...} are needed
around the nullcmd input redirection, so that the 2> redirection won't
be improperly parsed as part of the file name (see my previous report).
The $(...) substitution grabs the contents of the CVS/Entries file to
get a list of all files in the current directory that CVS knows about.
This is wrapped in ${(f@)...} to force each line to be interpreted as
a separate word; this works because of the outer double quotes.  Next
is ${...#/} to strip a leading slash from every line of the CVS/Entries
file.  Finally, this is wrapped in ${...%%/*} to strip from each line
everything following the file name itself.

If there's a better way than `for f in ... do echo ... done' to prefix
every element of the resulting array with ${pref}, I'd love to see it.

Now for the bug:  If the ${pref}CVS/Entries file exists, all of this
works fine.  However, if no CVS directory exists at all, the above
subsitution prints a newline to the terminal -- which messes up zle.
The newline is not going into $reply, because using <redisplay> or
<clear-screen> and then continuing a menu completion cycles through
the other choices without further zle confusion.

Where is that newline coming from?

The other interesting (and the slow) part of $reply is:

	${pref}*/**/CVS(:h)

which returns names of any directories below the ${pref} directory that
in turn contain a CVS subdirectory.

Hmm, maybe all that should get added to the comments in the file. :-}

*** Misc/compctl-examples.0	Fri Jul  5 10:57:42 1996
--- Misc/compctl-examples	Sat Jul 13 16:50:40 1996
***************
*** 439,447 ****
  	pref=
      fi
      [[ -n "$pref" && "$pref" != */ ]] && pref=$pref/
!     reply=($(for f in $(cat ${pref}CVS/Entries 2>/dev/null | \
!     		sed 's/^\/\([^\/]*\).*/\1/'); do echo $pref$f; done)
! 	   $(echo ${pref}**/CVS(:h) | sed 's/CVS//'))
  }
  #------------------------------------------------------------------------------
  # RedHat Linux rpm utility
--- 439,448 ----
  	pref=
      fi
      [[ -n "$pref" && "$pref" != */ ]] && pref=$pref/
!     reply=($(for f in \
! 		"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}" \
!     		do echo $pref$f; done)
! 	   ${pref}*/**/CVS(:h))
  }
  #------------------------------------------------------------------------------
  # RedHat Linux rpm utility

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

On Jul 13,  5:34pm, Bart Schaefer wrote:
} Subject: Another patch to compctl-examples CVS compctl, and a bug?
}
} Now for the bug:  If the ${pref}CVS/Entries file exists, all of this
} works fine.  However, if no CVS directory exists at all, the above
} subsitution prints a newline to the terminal -- which messes up zle.
} The newline is not going into $reply, because using <redisplay> or
} <clear-screen> and then continuing a menu completion cycles through
} the other choices without further zle confusion.
} 
} Where is that newline coming from?
} 
} !     reply=($(for f in \
} ! 		"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}" \
} !     		do echo $pref$f; done)
} ! 	   ${pref}*/**/CVS(:h))

There's one too many backslashes in the above.  Take out the one just
before the "do".  With that backslash removed, everything works as
intended.  I still don't know why the extra newline is going straight
to the terminal, but this works:

    reply=($(for f in \
		"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"
		do echo $pref$f; done)
	   ${pref}*/**/CVS(:h))


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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

On Jul 13,  6:55pm, Bart Schaefer wrote:
} Subject: Re: Another patch to compctl-examples CVS compctl, and a bug?
}
} } !     reply=($(for f in \
} } ! 		"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}" \
} } !     		do echo $pref$f; done)
} } ! 	   ${pref}*/**/CVS(:h))
} 
} There's one too many backslashes in the above.  Take out the one just
} before the "do".  With that backslash removed, everything works as
} intended.

Sigh.  I take it back; it still generates the stray newline.  However, the
backslash does need to be removed for the completion to work properly in
directories that do have a CVS subdirectory.

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Zoltan Hidvegi]

> It's now possible to avoid several external processes in generating the
> list of CVS-controlled files in the `cvstargets' function.  The key is
> this wonderful "parameter" (boy, is that misnamed) subsitution:
> 
> 	"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"

There are two problems with that.  First I've modified the lexer so that
!, [[, { and } are reserved words now.  This means that these must be
delimited.  So {echo} no longer works, { echo } should be used instead.
Similarily [[-z $foo]] does not work, [[ -z $foo ]] should be used.

The other problem is that this depends on READNULLCMD being cat.
$(<...) always works since it is always recognized as a special command
substitution.  That's why the 2> redirection does not work in that case
(but a space between `(' and `<' fixes that problem).

> If there's a better way than `for f in ... do echo ... done' to prefix
> every element of the resulting array with ${pref}, I'd love to see it.

It's simply

 	"${pref}${^${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"

> works fine.  However, if no CVS directory exists at all, the above
> subsitution prints a newline to the terminal -- which messes up zle.

Are you sure that there is not empty element in the reply?  The above
`parameter expansion' always produces at least one element.

Zoltan

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

On Jul 15,  3:02am, Zoltan Hidvegi wrote:
} Subject: Re: Another patch to compctl-examples CVS compctl, and a bug?
}
} > 	"${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"
} 
} There are two problems with that.  First I've modified the lexer so that
} !, [[, { and } are reserved words now.  This means that these must be
} delimited.  So {echo} no longer works, { echo } should be used instead.
} Similarily [[-z $foo]] does not work, [[ -z $foo ]] should be used.

Hmm.  I don't think anything else I've done depends on that, but given
that we're already at 3.0-preN for N >1, it seems a rather bad time to
make the change.

} The other problem is that this depends on READNULLCMD being cat.

It depends on READNULLCMD being something that knows when its output
is not a terminal, at least; "less" and "more" both work just as well
as "cat".

} $(<...) always works since it is always recognized as a special command
} substitution.  That's why the 2> redirection does not work in that case

Still seems like a bug to me.

} > If there's a better way than `for f in ... do echo ... done' to prefix
} > every element of the resulting array with ${pref}, I'd love to see it.
} 
} It's simply
} 
}  	"${pref}${^${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"

I thought something like that should work, but I never tried the carat
in that particular spot.

} > works fine.  However, if no CVS directory exists at all, the above
} > subsitution prints a newline to the terminal -- which messes up zle.
} 
} Are you sure that there is not empty element in the reply?

Why should that make a difference?  It still shouldn't output a newline.

} The above `parameter expansion' always produces at least one element.

Here's the behavior I see in a directory that has no CVS subdirectory:

If I replace my `for ... echo' loop with your ${^...} solution above,
then *every* time I hit TAB I get a newline on the terminal, and I
never see any completions.  (Your solution works normally in a dir
that *does* have a CVS subdir.)

If I use my `for ... echo' loop, I get a newline the first time I hit
TAB.  The second time I hit TAB I get the leading hyphen from the -k
array of option letters, followed by a newline, followed by `A' (the
first option letter).  From that point on I get no stray newlines, and
the options cycle normally (though zle is confused if I don't do a
<redisplay> at some point.

If I use your solution with an explicit "cat", I don't get any newlines,
but I also don't get any completions -- not even the -k ones.

If I switch back to an explicit "cat" and use my original `for' loop,
everything works exactly as I would expect -- no stray newlines at all,
and all the expected -k completions appear.

So it has something to do with READNULLCMD, and there's something else
broken about your solution.  (Maybe that's where the empty element in
the array is involved?)

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Zoltan Hidvegi]

> Hmm.  I don't think anything else I've done depends on that, but given
> that we're already at 3.0-preN for N >1, it seems a rather bad time to
> make the change.

But I think that such a change would be even worse after 3.0 is out.

Zoltan

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

Here's a patch, to be applied on top of my last patch, that incorporates
some of the changes suggested by the discussion.  It avoids using $(<...)
construct on nonexistent files because of the stray newline that appears.
I'd still like to know where that's coming from.

*** Misc/compctl-examples.1	Sat Jul 13 16:50:40 1996
--- Misc/compctl-examples	Sun Jul 14 23:57:31 1996
***************
*** 439,447 ****
  	pref=
      fi
      [[ -n "$pref" && "$pref" != */ ]] && pref=$pref/
!     reply=($(for f in "${${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}" \
!     		do echo $pref$f; done)
! 	   ${pref}*/**/CVS(:h))
  }
  #------------------------------------------------------------------------------
  # RedHat Linux rpm utility
--- 439,451 ----
  	pref=
      fi
      [[ -n "$pref" && "$pref" != */ ]] && pref=$pref/
!     if [[ -f ${pref}CVS/Entries ]]
!     then
! 	reply=( "${pref}${^${${(f@)$(<${pref}CVS/Entries)}#/}%%/*}"
! 		${pref}*/**/CVS(:h) )
!     else
! 	reply=( ${pref}*/**/CVS(:h) )
!     fi
  }
  #------------------------------------------------------------------------------
  # RedHat Linux rpm utility

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

On Jul 15, 12:03am, Bart Schaefer wrote:
} Subject: Re: Another patch to compctl-examples CVS compctl, and a bug?
}
} Here's a patch, to be applied on top of my last patch, that incorporates
} some of the changes suggested by the discussion.  It avoids using $(<...)
} construct on nonexistent files because of the stray newline that appears.

Seems Zoltan and I had similar thoughts on this ... but you don't need the
2>/dev/null redirection if you're testing ahead of time for the existence
of the CVS/Entries file.  Here's my same patch except against 3.0-pre3.

*** Misc/compctl-examples.0	Mon Jul 15 00:07:16 1996
--- Misc/compctl-examples	Mon Jul 15 09:57:31 1996
***************
*** 439,449 ****
  	pref=
      fi
      [[ -n "$pref" && "$pref" != */ ]] && pref=$pref/
!     if [[ -f "${pref}CVS/Entries" ]] then
!     reply=( "${pref}${^${${(f@)$(cat ${pref}CVS/Entries 2> /dev/null)}#/}%%/*}"
! 	    ${pref}*/**/CVS(:h) )
      else
!     reply=( ${pref}*/**/CVS(:h) )
      fi
  }
  #------------------------------------------------------------------------------
--- 439,450 ----
  	pref=
      fi
      [[ -n "$pref" && "$pref" != */ ]] && pref=$pref/
!     if [[ -f ${pref}CVS/Entries ]]
!     then
! 	reply=( "${pref}${^${${(f@)$(<${pref}CVS/Entries)}#/}%%/*}"
! 		${pref}*/**/CVS(:h) )
      else
! 	reply=( ${pref}*/**/CVS(:h) )
      fi
  }
  #------------------------------------------------------------------------------

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Completion behavior change in 3.0-pre3

[Bart Schaefer]

Here's zsh 3.0-pre2:

zagzig[85] echo z*i<TAB>
(feep)
zagzig[85] echo z*i

Here's zsh 3.0-pre3:

zagzig<3> echo z*i<TAB>
(feep)
zagzig<3> echo z\*i

I really prefer the pre2 behavior.  I suspect this has something to do
with Zoltan's simplification of the code in docomplete(), but I'm not
sure what.  Probably replacement of the loop that walks chline with a
single call to inststr(chline)?

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Completion behavior change in 3.0-pre3

[Christoph von Stuckrad]

On Mon, 15 Jul 1996, Bart Schaefer wrote:

> Subject: Completion behavior change in 3.0-pre3 
--pre2--example deleted--
> Here's zsh 3.0-pre3:
> 
> zagzig<3> echo z*i<TAB>
> (feep)
> zagzig<3> echo z\*i

Isn't this a feature instead of a bug ?

THIS 'z\*i' is exactly what would be used on the input line if the
pattern doesn't glob (is it?, well, HERE it is, but i've set the option
'nonomatch' to get this behaviour).

So if this behaviour depends on 'nonomatch' I would appreciate it!
If not, well, I think one can get used to it.


By the way, I fear almoust all scripts I use break due to
the new '((' and '[[' 'blanks', but I'll have to try yet
I'm just compiling...

Fanatic zsh-user Stucki

Christoph von Stuckrad       *  *  | talk to  | <stucki@math.fu-berlin.de> \
Freie Universitaet Berlin    |/__* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\  * | 'stucki' | Tel:+49 30 838-7545{9|8}    |
Arnimallee 2-6/14195 Berlin  * *   |  on IRC  | Fax:+49 30 838-5913        /

Re: Completion behavior change in 3.0-pre3

[Bart Schaefer]

On Jul 17, 11:52am, Christoph von Stuckrad wrote:
> Subject: Re: Completion behavior change in 3.0-pre3
> On Mon, 15 Jul 1996, Bart Schaefer wrote:
> 
> > Here's zsh 3.0-pre3:
> > 
> > zagzig<3> echo z*i<TAB>
> > (feep)
> > zagzig<3> echo z\*i
> 
> Isn't this a feature instead of a bug ?

Given that Zoltan didn't mention this as an intentional change, I don't
think it's meant to be a feature.

> THIS 'z\*i' is exactly what would be used on the input line if the
> pattern doesn't glob

I *might* agree if I had GLOB_COMPLETE set; but I don't, so it
should be waiting for me to make the pattern unambiguous before it
decides that it has to quote anything.  Even with GLOB_COMPLETE,
I can't really go along with you; performing completion/expansion
shouldn't change the *semantics* of the command line:

	touch z*i	# Fails with "no match"
	touch z\*i	# Creates a new file

In effect, zsh should never rewrite the line when it (feep)s, only
when it successfully expands or completes something.

> So if this behaviour depends on 'nonomatch' I would appreciate it!

I don't have nonomatch set either.  (Gad, that sounds illiterate.
A triple negative?  Anyway, it doesn't depend on nonomatch.)

> If not, well, I think one can get used to it.

Get used to backing up to remove quoting from every glob pattern on the
line after every completion?  Or get used to not using completion?

Re: Completion behavior change in 3.0-pre3

[Bart Schaefer]

On Jul 15, 11:00pm, Bart Schaefer wrote:
> Subject: Completion behavior change in 3.0-pre3
> Here's zsh 3.0-pre2:
> 
> zagzig[85] echo z*i<TAB>
> (feep)
> zagzig[85] echo z*i
> 
> Here's zsh 3.0-pre3:
> 
> zagzig<3> echo z*i<TAB>
> (feep)
> zagzig<3> echo z\*i

I've traced the point where the extra backslash gets inserted into
makecomplist(), right here:

    /* ... */
    lpre = zalloc(lpl + 1);
    memcpy(lpre, s, lpl);
    lpre[lpl] = '\0';
    p = quotename(lpre, NULL, NULL, NULL);
    if (strcmp(p, lpre) && !strpfx(p, qword)) {
	/* ... */
	inststrlen(p, 1, l2 = strlen(p));	/* This adds the backslash */
	/* ... */
    }
    /* ... */

In 3.0-pre2 and earlier, the backslash would get removed again as shown
by the following patch (which backs out two hunks of Zoltan's changes).
I'm not sure why Zoltan thought the line should only be restored when
going around the xorrec: loop.  Should cs et.al. get restored along with
the line when *not* going around the loop?  (They weren't in pre2, this
just puts back the pre2 behavior.)

*** Src/zle_tricky.c.0	Mon Jul 15 22:46:49 1996
--- Src/zle_tricky.c	Wed Jul 17 14:45:34 1996
***************
*** 2957,2962 ****
--- 2957,2964 ----
      validlist = 1;
      if(nmatches && !errflag)
  	return 0;
+     /* No matches: restore the command line. */
+     strcpy((char *)line, (char *)ol);
  
      if ((isf || cc->xor) && !parampre) {
  	/* We found no matches, but there is a xor'ed completion: *
***************
*** 2967,2973 ****
  	wb = owb;
  	we = owe;
  	cs = ocs;
- 	strcpy((char *)line, (char *)ol);
  	offs = oloffs;
  	s = dupstring(os);
  	free(amatches);
--- 2969,2974 ----

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Bart Schaefer]

On Jul 14,  7:32pm, Bart Schaefer wrote:
>
> On Jul 15,  3:02am, Zoltan Hidvegi wrote:
> } 
> }  	"${pref}${^${${(f@)$({<${pref}CVS/Entries} 2>/dev/null)}#/}%%/*}"
> 
> Here's the behavior I see in a directory that has no CVS subdirectory:
> 
> If I replace my `for ... echo' loop with your ${^...} solution above,
> then *every* time I hit TAB I get a newline on the terminal, and I
> never see any completions.  (Your solution works normally in a dir
> that *does* have a CVS subdir.)

I think I finally tracked this down, crashing my Linux 1.3.15 kernel
three times in the process.  (Use GDB to put a breakpoint on a system
call such as write(), and then watch what happens when the process
forks and the child uses the system call.)

When you write this form of READNULLCMD:

	$( { <nonexistentfile } 2>/dev/null )

Zsh forks to execute the { ... } part so that it can redirect stderr.
READNULLCMD in the child process then discovers that nonexistentfile
doesn't exist, and calls zerr() to output the "no such file" message.

This is all fine most of the time, but when the above is used in a
completion, zleactive==1 and so zerr() calls trashzle().  The child
thus messes up the parent's terminal.

However, I don't know where to put a `zleactive = 0;' to prevent this.
Does it go in getoutput()?  That would solve this particular case, but
there might be others.  Does it go in entersubsh()?  Or is entersubsh()
sometimes called when we haven't really forked?

Insights appreciated.

Re: Bug in case stmt with '('

[Bart Schaefer]

On Jul 21, 11:31pm, Bart Schaefer wrote:
} Subject: Re: Bug in case stmt with '('
}
} I think we should leave it POSIX-style.
} 
} However, there is a remaining bug in Zoltan's patch.
} 
} zagzig<8> case foo in
} > (foo) echo yes;;
} zsh: parse error near `echo'
} 
} Apparently there still needs to be at least one token between the close
} paren and the first word of the actual command.

I thought Zoltan's "if" cascade looked a little too easy.  Here's the fix.

*** Src/parse.c.0	Fri Jul 19 11:17:12 1996
--- Src/parse.c	Sun Jul 21 23:45:10 1996
***************
*** 522,544 ****
  		str2[sl] = Bar;
  		str2[sl+1] = '\0';
  		str = str2;
! 	    } else if (tok == STRING) {
! 		char *str2;
  		int sl = strlen(str);
  
! 		if (str[sl - 1] != Bar)
! 		    YYERRORV;
! 		str2 = ncalloc(sl + strlen(tokstr) + 1);
! 		strcpy(str2, str);
! 		strcpy(str2 + sl, tokstr);
! 		str = str2;
! 	    } else {
! 		/* POSIX allows (foo*) patterns */
! 		char *s = str;
  
! 		if (skipparens(Inpar, Outpar, &s) || *s)
! 		    YYERRORV;
! 		break;
  	    }
  	}
  	addlinknode(pats, str);
--- 522,547 ----
  		str2[sl] = Bar;
  		str2[sl+1] = '\0';
  		str = str2;
! 	    } else {
  		int sl = strlen(str);
  
! 		if (str[sl - 1] != Bar) {
! 		    /* POSIX allows (foo*) patterns */
! 		    char *s = str;
  
! 		    if (skipparens(Inpar, Outpar, &s) || *s)
! 			YYERRORV;
! 		    break;
! 		} else {
! 		    char *str2;
! 
! 		    if (tok != STRING)
! 			YYERRORV;
! 		    str2 = ncalloc(sl + strlen(tokstr) + 1);
! 		    strcpy(str2, str);
! 		    strcpy(str2 + sl, tokstr);
! 		    str = str2;
! 		}
  	    }
  	}
  	addlinknode(pats, str);
***************

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

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Another patch to compctl-examples CVS compctl, and a bug?

[Peter Stephenson]

schaefer@candle.brasslantern.com wrote:
> However, I don't know where to put a `zleactive = 0;' to prevent this.
> Does it go in getoutput()?  That would solve this particular case, but
> there might be others.  Does it go in entersubsh()?  Or is entersubsh()
> sometimes called when we haven't really forked?
> 
> Insights appreciated.

I'm not sure if I'd go as far as `insight', but putting zleactive to
zero in entersubsh() sounds very plausible to me.  Entersubsh() is
sometimes called when we haven't really forked, but the intention is
always that the shell is about to exec a command in the manner it
would if it actually had forked.  In fact, turning off the interactive
capabilities is one of its major raisons d'etre, so this looks just
the place.

It's not clear to me, by the way, whether the subset of options that
gets turned off in entersubsh() --- currently MONITOR and USEZLE (aha!
that proves it --- if USEZLE is turned off, zleactive should certainly
go to zero) is correct.  If MONITOR, why not INTERACTIVE itself?

% for opt in monitor interactive; do
for> print $([[ -o $opt ]] && print $opt is set)
for> done

  interactive is set

*** Src/exec.c.bart	Mon Jul 22 09:27:52 1996
--- Src/exec.c	Mon Jul 22 09:28:14 1996
***************
*** 1857,1862 ****
--- 1857,1863 ----
      if (sigtrapped[SIGQUIT] != 2)
  	signal_default(SIGQUIT);
      opts[MONITOR] = opts[USEZLE] = 0;
+     zleactive = 0;
      if (cl)
  	clearjobtab();
      times(&shtms);


-- 
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.