* Misc. unresolved stuff @ 1996-07-19 18:12 Bart Schaefer 1996-07-19 19:30 ` Zoltan Hidvegi 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 1996-07-19 18:12 UTC (permalink / raw) To: zsh-workers 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Misc. unresolved stuff 1996-07-19 18:12 Misc. unresolved stuff Bart Schaefer @ 1996-07-19 19:30 ` Zoltan Hidvegi 1996-07-19 19:59 ` Bart Schaefer 1996-07-19 20:38 ` Bart Schaefer 0 siblings, 2 replies; 5+ messages in thread From: Zoltan Hidvegi @ 1996-07-19 19:30 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers > 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; } } } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Misc. unresolved stuff 1996-07-19 19:30 ` Zoltan Hidvegi @ 1996-07-19 19:59 ` Bart Schaefer 1996-07-19 20:27 ` Zoltan Hidvegi 1996-07-19 20:38 ` Bart Schaefer 1 sibling, 1 reply; 5+ messages in thread From: Bart Schaefer @ 1996-07-19 19:59 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers 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 ... ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Misc. unresolved stuff 1996-07-19 19:59 ` Bart Schaefer @ 1996-07-19 20:27 ` Zoltan Hidvegi 0 siblings, 0 replies; 5+ messages in thread From: Zoltan Hidvegi @ 1996-07-19 20:27 UTC (permalink / raw) To: schaefer; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Misc. unresolved stuff 1996-07-19 19:30 ` Zoltan Hidvegi 1996-07-19 19:59 ` Bart Schaefer @ 1996-07-19 20:38 ` Bart Schaefer 1 sibling, 0 replies; 5+ messages in thread From: Bart Schaefer @ 1996-07-19 20:38 UTC (permalink / raw) To: Zoltan Hidvegi; +Cc: zsh-workers 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.) ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1996-07-19 20:41 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-07-19 18:12 Misc. unresolved stuff Bart Schaefer 1996-07-19 19:30 ` Zoltan Hidvegi 1996-07-19 19:59 ` Bart Schaefer 1996-07-19 20:27 ` Zoltan Hidvegi 1996-07-19 20:38 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).