Misc. unresolved stuff

Misc. unresolved stuff

[Bart Schaefer]

In article 1397, Zoltan said he'd fix $[$[1+2]+3], and apparently he has.
Is there some reason why $((...)) doesn't nest?  I asked in article 1414
whether there other differences between $[...] and $((...)).  There's
exactly one mention of $((...)) in zshexpn.man, which says only that it's
the same as $[...].

In article 1426, I asked why array subscript flags such as $foo[(f)...]
don't work with $foo[@] and $foo[*].  Does anyone else want them to?

In article 1428, I pointed out that zsh's "getopts" builtin doesn't seem
to properly handle some error cases, by comparison to bash.  I don't have
ksh to compare to that.  Does anyone think "getopts" is a problem?

In zsh-users article 257, I asked why there's no (:L) modifier, to go
with the (L) flag; similarly (U) and (:U).  I also hoped for a better
error message for unrecognized modifiers.  Any comment?

Re: Misc. unresolved stuff

[Zoltan Hidvegi]

> In article 1397, Zoltan said he'd fix $[$[1+2]+3], and apparently he has.
> Is there some reason why $((...)) doesn't nest?  I asked in article 1414
> whether there other differences between $[...] and $((...)).  There's
> exactly one mention of $((...)) in zshexpn.man, which says only that it's
> the same as $[...].

That's a bug again.  The fix is below.

> In article 1426, I asked why array subscript flags such as $foo[(f)...]
> don't work with $foo[@] and $foo[*].  Does anyone else want them to?

That's a bit more difficult because in this case $foo should be split.
$foo[(f)@] is interpreted in params.c while splitting is done in subst.c so
this cahnge is not trivial (but it is probably not difficult).

> In article 1428, I pointed out that zsh's "getopts" builtin doesn't seem
> to properly handle some error cases, by comparison to bash.  I don't have
> ksh to compare to that.  Does anyone think "getopts" is a problem?

I think that zsh getopts is ksh and POSIX compatible.  I do not use getopts
but you can compare it with the ksh version.  pdksh is free and the AT&T
ksh93 can also be downloaded and used free from
http://www.research.att.com/orgs/ssr/book/reuse/.

> In zsh-users article 257, I asked why there's no (:L) modifier, to go
> with the (L) flag; similarly (U) and (:U).  I also hoped for a better
> error message for unrecognized modifiers.  Any comment?

I think we can live with this inconsistency.  The biggest problem here that
there are too few letters in the alphabet.  Probably that's why (L) is not
(l).  But there is a bug in the parameter modifier code when a modifier is
used on an empty array and the diagnostics can certainly be improved.
Tell me if you like the behaviour after applying this patch.

Zoltan


rcsdiff -qc -kk -r2.41 -r2.43 Src/subst.c
*** Src/subst.c
--- Src/subst.c	1996/07/19 19:25:14	2.43
***************
*** 128,148 ****
  	    char endchar;
  	    int l1, l2;
  
! 	    if (*str == Inpar)
! 		endchar = Outpar, str[-1] = '\0';
! 	    else
! 		endchar = *str, *str = '\0';
! 
! 	    while (*++str != endchar)
! #ifdef DEBUG
! 		if (!*str) {
! 		    /* This shoud never happen */
! 		    zerr("Oops. parse error in command substitution", NULL, 0);
! 		    return NULL;
! 		}
! #else
! 		;
! #endif
  	    *str++ = '\0';
  	    if (endchar == Outpar && str2[1] == '(' && str[-2] == ')') {
  		/* Math substitution of the form $((...)) */
--- 128,146 ----
  	    char endchar;
  	    int l1, l2;
  
! 	    if (*str == Inpar) {
! 		endchar = Outpar;
! 		str[-1] = '\0';
! 		if (skipparens(Inpar, Outpar, &str))
! 		    DPUTS(1, "Oops. parse error in command substitution");
! 		str--;
! 	    } else {
! 		endchar = *str;
! 		*str = '\0';
! 
! 		while (*++str != endchar)
! 		    DPUTS(!*str, "Oops. parse error in command substitution");
! 	    }
  	    *str++ = '\0';
  	    if (endchar == Outpar && str2[1] == '(' && str[-2] == ')') {
  		/* Math substitution of the form $((...)) */
***************
*** 1201,1207 ****
  		if (!isarr)
  		    modify(&val, &s);
  		else {
! 		    char *ss = s;
  		    char **ap = aval;
  		    char **pp = aval = (char **)ncalloc(sizeof(char *) * (arrlen(aval) + 1));
  
--- 1199,1205 ----
  		if (!isarr)
  		    modify(&val, &s);
  		else {
! 		    char *ss;
  		    char **ap = aval;
  		    char **pp = aval = (char **)ncalloc(sizeof(char *) * (arrlen(aval) + 1));
  
***************
*** 1209,1215 ****
--- 1207,1226 ----
  			ss = s;
  			modify(pp++, &ss);
  		    }
+ 		    if (pp == aval) {
+ 			char t[] = "";
+ 			ss = s;
+ 			s = t;
+ 			modify(&s, &ss);
+ 		    }
  		    s = ss;
+ 		}
+ 		if (inbrace && *s != Outbrace) {
+ 		    if (*s == ':' && !imeta(s[1]))
+ 			zerr("unrecognized modifier `%c'", NULL, s[1]);
+ 		    else
+ 			zerr("unrecognized modifier", NULL, 0);
+ 		    return NULL;
  		}
  	    }
  	}

Re: Misc. unresolved stuff

[Bart Schaefer]

On Jul 19,  9:30pm, Zoltan Hidvegi wrote:
> Subject: Re: Misc. unresolved stuff
> 
> ! 		endchar = *str;
> ! 		*str = '\0';
> ! 
> ! 		while (*++str != endchar)
> ! 		    DPUTS(!*str, "Oops. parse error in command substitution");

Shouldn't that be:

		while (*++str && *str != endchar)

??  Otherwise you could go wandering off the end of str ...

Re: Misc. unresolved stuff

[Zoltan Hidvegi]

Bart wrote:
> > ! 		while (*++str != endchar)
> > ! 		    DPUTS(!*str, "Oops. parse error in command substitution");
> 
> Shouldn't that be:
> 
> 		while (*++str && *str != endchar)
> 
> ??  Otherwise you could go wandering off the end of str ...

At least it will be obvious that something is wrong.  It should be
impossible for a null to come before the endchar.

Zoltan

Re: Misc. unresolved stuff

[Bart Schaefer]

On Jul 19,  9:30pm, Zoltan Hidvegi wrote:
> Subject: Re: Misc. unresolved stuff
> 
> > In zsh-users article 257, I asked why there's no (:L) modifier, to go
> > with the (L) flag; similarly (U) and (:U).  I also hoped for a better
> > error message for unrecognized modifiers.  Any comment?
> 
> Tell me if you like the behaviour after applying this patch.

Yes, that is better.

I note that unrecognized glob modifiers are silently ignored; is that
intentional?  (I realize that this patch wasn't addressing globbing.)