RE: PATCH: Re: Open bugs and questions?

RE: PATCH: Re: Open bugs and questions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

>                                           And: how do you
> > specify a character class matching everything but ']'?
> > 
> 
> [^]]
> 
> or (fool-prrof)
> 
> [^\]]

Err, sorry. I meant: in the context of that big pattern in the patch:

  % let "$foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)]"
  zsh: bad math expression: operand expected at `)(|:*)]'
  % (( $foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)] ))
  zsh: command not found: )(|:*)]


Bye
 Sven


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

Re: PATCH: Re: Open bugs and questions?

[Peter Stephenson]

>   % let "$foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)]"
>   zsh: bad math expression: operand expected at `)(|:*)]'
>   % (( $foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)] ))
>   zsh: command not found: )(|:*)]

% pat='(|\([^\)]#\))-bar(|[-+=])(|\[[^\]]\])(|:*)' 
% (( $foo[(I)$~pat] ))

I haven't tried this out because out of context I haven't the smallest idea
what it's supposed to be doing.

-- 
Peter Stephenson <pws@csr.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: PATCH: Re: Open bugs and questions?

[Andrej Borsenkow]

> 
> Err, sorry. I meant: in the context of that big pattern in the patch:
> 
>   % let "$foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)]"
>   zsh: bad math expression: operand expected at `)(|:*)]'
>   % (( $foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)] ))
>   zsh: command not found: )(|:*)]
> 

Is not this related to a bug id 104052 on Sourceforge?

-andrej

RE: PATCH: Re: Open bugs and questions?

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > Err, sorry. I meant: in the context of that big pattern in the patch:
> > 
> >   % let "$foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)]"
> >   zsh: bad math expression: operand expected at `)(|:*)]'
> >   % (( $foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)] ))
> >   zsh: command not found: )(|:*)]
> > 
> 
> Is not this related to a bug id 104052 on Sourceforge?

Yes.

Bye
 Sven


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

PATCH: Re: Open bugs and questions?

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Aug 2,  2:08pm, Sven Wischnowsky wrote:
> } Subject: Re: Open bugs and questions?
> }
> } The `use 'exit' to exit' message is displayed slightly differently:
> } below the prompt without displaying a new prompt. Is that ok?
> 
> Perhaps it should respect "alwayslastprompt", or something?  Nah, that's
> overkill.  But how does your change work when ZLE is disabled?

Exactly as before. The change is entirely in zle. Only in zle_main.c, even.

> } Hm, because of that and the shell-function widget thing, I'll wait
> } before committing it.
> 
> I think the shell-function-widget-thing is fine.

Ok, I'll commit it then.

Most of the patch is re-indentation.


Bye
 Sven

Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.10
diff -u -r1.10 options.yo
--- Doc/Zsh/options.yo	2000/07/19 21:37:18	1.10
+++ Doc/Zsh/options.yo	2000/08/03 07:48:55
@@ -573,6 +573,11 @@
 of tt(exit) or tt(logout) instead.
 However, ten consecutive EOFs will cause the shell to exit anyway,
 to avoid the shell hanging if its tty goes away.
+
+Also, if this option is set and the Zsh Line Editor is used, widgets
+implemented by shell functions can be bound to EOF (normally
+Control-D) without printing the normal warning message.  This works
+only for normal widgets, not for completion widgets.
 )
 pindex(INC_APPEND_HISTORY)
 cindex(history, incremental appending to a file)
Index: Src/Zle/zle_main.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_main.c,v
retrieving revision 1.8
diff -u -r1.8 zle_main.c
--- Src/Zle/zle_main.c	2000/07/27 17:48:48	1.8
+++ Src/Zle/zle_main.c	2000/08/03 07:48:59
@@ -76,7 +76,10 @@
 /**/
 int insmode;
 
-static int eofchar, eofsent;
+/**/
+mod_export int eofchar;
+
+static int eofsent;
 static long keytimeout;
 
 #ifdef HAVE_SELECT
@@ -556,7 +559,7 @@
 	reselectkeymap();
 	selectlocalmap(NULL);
 	bindk = getkeycmd();
-	if (!ll && isfirstln && c == eofchar) {
+	if (!ll && isfirstln && unset(IGNOREEOF) && c == eofchar) {
 	    eofsent = 1;
 	    break;
 	}
@@ -630,26 +633,33 @@
     } else if((w = func->widget)->flags & (WIDGET_INT|WIDGET_NCOMP)) {
 	int wflags = w->flags;
 
-	if(!(wflags & ZLE_KEEPSUFFIX))
-	    removesuffix();
-	if(!(wflags & ZLE_MENUCMP)) {
-	    fixsuffix();
-	    invalidatelist();
+	if (keybuf[0] == eofchar && !keybuf[1] &&
+	    !ll && isfirstln && isset(IGNOREEOF)) {
+	    showmsg((!islogin) ? "zsh: use 'exit' to exit." :
+		    "zsh: use 'logout' to logout.");
+	    ret = 1;
+	} else {
+	    if(!(wflags & ZLE_KEEPSUFFIX))
+		removesuffix();
+	    if(!(wflags & ZLE_MENUCMP)) {
+		fixsuffix();
+		invalidatelist();
+	    }
+	    if (wflags & ZLE_LINEMOVE)
+		vilinerange = 1;
+	    if(!(wflags & ZLE_LASTCOL))
+		lastcol = -1;
+	    if (wflags & WIDGET_NCOMP) {
+		int atcurhist = histline == curhist;
+		compwidget = w;
+		ret = completecall(args);
+		if (atcurhist)
+		    histline = curhist;
+	    } else
+		ret = w->u.fn(args);
+	    if (!(wflags & ZLE_NOTCOMMAND))
+		lastcmd = wflags;
 	}
-	if (wflags & ZLE_LINEMOVE)
-	    vilinerange = 1;
-	if(!(wflags & ZLE_LASTCOL))
-	    lastcol = -1;
-	if (wflags & WIDGET_NCOMP) {
-	  int atcurhist = histline == curhist;
-	    compwidget = w;
-	    ret = completecall(args);
-	    if (atcurhist)
-		histline = curhist;
-	} else
-	    ret = w->u.fn(args);
-	if (!(wflags & ZLE_NOTCOMMAND))
-	    lastcmd = wflags;
 	r = 1;
     } else {
 	Eprog prog = getshfunc(w->u.fnnam);

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

Re: PATCH: Re: Open bugs and questions?

[Sven Wischnowsky]

Peter Stephenson wrote:

> >   % let "$foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)]"
> >   zsh: bad math expression: operand expected at `)(|:*)]'
> >   % (( $foo[(I)(|\([^\)]#\))-bar(|[-+=])(|\[[^]]\])(|:*)] ))
> >   zsh: command not found: )(|:*)]
> 
> % pat='(|\([^\)]#\))-bar(|[-+=])(|\[[^\]]\])(|:*)' 
> % (( $foo[(I)$~pat] ))
> 
> I haven't tried this out because out of context I haven't the smallest idea
> what it's supposed to be doing.

Yes, I know. I wanted to avoid introducing an extra parameter just for 
the pattern.

It's used to test if one of the options found in the --help output has 
a description in the user specified specs. I.e. the pattern should
match option specs.

Bye
 Sven


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

RE: PATCH: Re: Open bugs and questions?

[Andrej Borsenkow]

> 
                                          And: how do you
> specify a character class matching everything but ']'?
> 

[^]]

or (fool-prrof)

[^\]]

-andrej

PATCH: Re: Open bugs and questions?

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> I haven't updated the one I made just before 3.1.9, but I don't think
> everything on that last list got done, either.

Hmhm.

> } 12344, 12350, 12382
> }   Make `_arguments --' use the short options, too?
> 
> I have a patch for this first part, but:
> 
> }   And make it prefer a user-supplied description if there is one (and
> }   a automatically found one).
> 
> I don't have a patch for that second part.

Below is the patch for it. It makes user-supplied specs be preferred
unconditionally, though, even if there is a spec matching the option
after the `--' (that's the problem: `matching', probably user didn't
mean that or it's one of the two builtin patterns for files and
paths).

Two comments: I had to use `let' because stuffing that parameter
expansion into a `((...))'' wasn't parsed correctly. And: how do you
specify a character class matching everything but ']'?


> } 12225
> }   The return value of _arguments with `->state' actions doesn't tell
> }   if options were completed.
> 
> I meant to reply to that message.  I've never been happy with using the
> exit status to indicate that an ->state action was taken.  The only
> simple test on exit status is true/false; for anything else, you have
> to compare against $? -- which means you might as well be testing some
> other parameter instead, e.g. [[ -n "$state" ]] which is what most of
> the functions that use ->state already do anyway.
> 
> So I suggest simply dumping the 300 exit status; zero means that matches
> were added, anything else means that no matches were added, and if you
> want to use states you test the $state array directly.

No. The special return value is used by the wrappers around _arguments 
such as _x_arguments. And there we *need* to be able to distinguish
the cases (to keep the special parameters from being reset).

And anyway, the problem is not with the return value, since, as you
observed, we use $state for tests anyway. The problem is that with
->state actions _arguments may have to generate matches (the options)
and it can't know if the caller adds more matches. What I wanted is an 
easier way for calling functions to distinguish this from the case
where _arguments generates real matches (by executing one of the other 
forms for actions). Currently this can be done by relying on the
return value to test if `real' matches (not only options) were
generated and then use $state to find out if a state has to be handled 
and *there* use $compstate[nmatches] to find out if options were
completed. If needed, and it is seldom needed because in most cases
the state doesn't have to be handled in a loop.

> } 12054, 12071
> }   There is no way to handle ^D at the beginning of the line with a
> }   widget, because the zle main loop deals with it directly.
> 
> It *is* possible to handle ^D at beginning of line:  stty eof undef
> permits it.  This is equivalent to having to turn off flow control in
> order to use ^S and ^Q in keybindings.
> 
> So maybe the right answer is that `setopt ignoreeof' should affect ZLE
> the same way that `setopt noflowcontrol' does.  An actual zero-byte
> read would still be handled as it currently is; only ^D in column zero
> would be different (actually invoke the ^D binding rather than print
> "zsh: use 'logout' to logout.").

Sounds good.

> THEN we could change delete-char-or-list to print that warning when there
> are no characters in the editor buffer, et voila: the default behavior is
> exactly as now.

And the other widgets that are bound to ^D by default (in vi mode).

> ...
> 
> } 11399, 11400, 11413, 11428
> }   Context names for styles not used by the completion system
> }   itself. More specifically, for function that call the completion
> }   system, but have other styles used directly. And where to document
> }   them.
> 
> I've been toying with the idea of adding a "user contributions" chapter
> to the manual and throwing into it: incremental-complete-word, zed, the
> prompt themes, predict-on, zrecompile, nslookup, etc.  With appropriate
> sections, of course.

Sounds good, too.

> } 11465
> }   Interrupting builtins. E.g. with `cmd1 | builtin ; cmd2' a ^C should 
> }   keep cmd2 from being run.
> 
> There's also 11468.  I wish I had a suggestion.

I thought I had replied to it at the time, but it seems I didn't. To
repeat, the problem mentioned in 11468 was (quoting Bart):

> zagzig% cat | while read line; do echo $line; done; :
> ^Z^C
> zsh: suspended  cat | 
> zsh: running    while read line; do; echo $line; done
> zagzig% jobs
> [1]  + suspended  cat | 
>        running    while read line; do; echo $line; done
> zagzig% fg
> [1]  + continued  cat | while read line; do; echo $line; done
> foo
> zagzig% 
> 
> 
> According to Etc/BUGS, the `; :' forces zsh to fork before starting the
> while loop.  So in that case I would have expected ^Z to work, but it
> doesn't.  Following the ^Z with a ^C appears to background the job, but
> that hasn't really happened either; the while loop is not running, it's
> already gotten a failure return from read.  Is it sitting there waiting
> for "cat" to die?   (Which cat does, from a closed stdout, I think, as
> soon as you give it any input.)

First of all the `; :' is mentioned only for `zsh -c', but I admit
that I didn't try it with 3.0.8. With current CVS I get that thing
suspended on the ^Z, but foregrounding it gives the same result as
what Bart describes above. This is because in update_job(),
jobs.c:32[89] breaks and errflag are set because val is -1. This makes 
the test in zread(), builtin.c:3774 fail and read returns with a
non-zero status, ending the loop.

Changing the test in update_job() is, of course, trivial, but the read 
becomes unsuspensible. Ick.

Bye
 Sven

Index: Completion/Base/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_arguments,v
retrieving revision 1.30
diff -u -r1.30 _arguments
--- Completion/Base/_arguments	2000/08/01 11:21:00	1.30
+++ Completion/Base/_arguments	2000/08/02 08:43:30
@@ -70,7 +70,18 @@
     lopts=("--${(@)^${(@)${(@)${(@M)${(@ps:\n:j:\n:)${(@)${(@M)${(@f)$(_call options ${~words[1]} --help 2>&1)//\[--/
 --}:#[ 	]#-*}//,/
 }}:#[ 	]#--*}#*--}%%[]	 ]*}:#}")
-    lopts=( "${(@)lopts:#--}" )
+
+    # Remove options also described by user-defined specs.
+
+    tmp=()
+    for opt in "${(@)lopts:#--}"; do
+
+      # Using (( ... )) gives a parse error.
+
+      let "$tmpargv[(I)(|\([^\)]#\))${opt}(|[-+=])(|\[*\])(|:*)]" ||
+          tmp=( "$tmp[@]" "$opt" )
+    done
+    lopts=( "$tmp[@]" )
 
     # Now remove all ignored options ...
 

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