* Re: bug or feature? [not found] <19970613182010.48585@retriever> @ 1997-06-16 9:15 ` Peter Stephenson 1997-06-18 18:13 ` Vinnie Shelton 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 1997-06-16 9:15 UTC (permalink / raw) To: Zsh hackers list, mito Louis-David Mitterrand wrote: > Something strange in filename generation: > > % ls JBC*a > JBClockView.java* JBCodesSICOVAM.java > JBCode.java JBConfig.java > > so far so good... then: > > % ls JBC*a~JBCo* > zsh: no matches found: JBC*a~JBCo* This is a genuine bug (as opposed to...? well, never mind). When parsing the pattern, the parser arrives at the ~ and stops the main pattern because it knows an exclusion is coming. However, it isn't smart enough to know that the 'a' just before should be the last thing matched. Later, when scanning JBClockView.java, everything is fine until it gets as far as matching 'lockView.j' against the *, and finds that the next character 'a' matches the last part of the pattern. It knows there are no more patterns to match in the list passed... but it also notes that the 'a' was not marked as the final part of the pattern, and that there is still a part of the string ('va') left, and concludes that this is OK since it must be backtracking or something. Therefore it wrongly claims that the string matched without the last 'va' and the rest of the scanner gets confused. (Alles klar?) The solution seems to be to keep track of whether a (lexically active) ~ matched at a particular point should be taken as ending the main string being scanned, which (due to the precedence of ~) is true unless we are in parentheses. The following code is supposed to do this. It fixes the basic bug, but probably could do with some checking... it would be nice to have a standard set of glob tests. Anyway, I've installed it and I can still log in. *** Src/glob.c.last Mon Jun 2 06:18:07 1997 --- Src/glob.c Mon Jun 16 10:45:58 1997 *************** *** 111,116 **** --- 111,120 ---- #define LASTP(c) (c->stat & C_LAST) #define PATHADDP(c) (c->stat & C_PATHADD) + /* Flags passed down to guts when compiling */ + #define GF_PATHADD 1 /* file glob, adding path components */ + #define GF_TOPLEV 2 /* outside (), so ~ ends main match */ + static char *pptr; /* current place in string being matched */ static Comp tail = 0; static int first; /* are leading dots special? */ *************** *** 451,457 **** /**/ static Comp ! parsecomp(void) { Comp c = (Comp) alloc(sizeof *c), c1, c2; char *cstr, *ls = NULL; --- 455,461 ---- /**/ static Comp ! parsecomp(int gflag) { Comp c = (Comp) alloc(sizeof *c), c1, c2; char *cstr, *ls = NULL; *************** *** 471,477 **** /* negate remaining pattern */ pptr++; c->str = dupstrpfx(cstr, pptr - cstr); ! if (!(c->next = parsecomp())) return NULL; return c; } --- 475,481 ---- /* negate remaining pattern */ pptr++; c->str = dupstrpfx(cstr, pptr - cstr); ! if (!(c->next = parsecomp(gflag))) return NULL; return c; } *************** *** 488,494 **** c1 = (Comp) alloc(sizeof *c1); *(c1->str = dupstring("?")) = Quest; c1->stat |= C_ONEHASH; ! if (!(c2 = parsecomp())) return NULL; c1->next = c2; c->next = c1; --- 492,498 ---- c1 = (Comp) alloc(sizeof *c1); *(c1->str = dupstring("?")) = Quest; c1->stat |= C_ONEHASH; ! if (!(c2 = parsecomp(gflag))) return NULL; c1->next = c2; c->next = c1; *************** *** 515,521 **** } } /* Parse the remaining pattern following the group... */ ! if (!(c1 = parsecomp())) return NULL; /* ...remembering what comes after it... */ tail = dpnd ? NULL : c1; --- 519,525 ---- } } /* Parse the remaining pattern following the group... */ ! if (!(c1 = parsecomp(gflag))) return NULL; /* ...remembering what comes after it... */ tail = dpnd ? NULL : c1; *************** *** 552,558 **** c1->next = c2; c2->stat |= C_ONEHASH; /* parse the rest of the pattern and return. */ ! c2->next = parsecomp(); if (!c2->next) return NULL; c->str = dupstrpfx(cstr, ls - cstr); --- 556,562 ---- c1->next = c2; c2->stat |= C_ONEHASH; /* parse the rest of the pattern and return. */ ! c2->next = parsecomp(gflag); if (!c2->next) return NULL; c->str = dupstrpfx(cstr, ls - cstr); *************** *** 584,590 **** pptr++; } /* mark if last pattern component in path component or pattern */ ! if (*pptr == '/' || !*pptr) c->stat |= C_LAST; c->str = dupstrpfx(cstr, pptr - cstr); return c; --- 588,595 ---- pptr++; } /* mark if last pattern component in path component or pattern */ ! if (*pptr == '/' || !*pptr || ! (isset(EXTENDEDGLOB) && *pptr == Tilde && (gflag & GF_TOPLEV))) c->stat |= C_LAST; c->str = dupstrpfx(cstr, pptr - cstr); return c; *************** *** 594,604 **** /**/ static Comp ! parsecompsw(int pathadd) { Comp c1, c2, c3, excl = NULL; ! c1 = parsecomp(); if (!c1) return NULL; if (isset(EXTENDEDGLOB) && *pptr == Tilde) { --- 599,609 ---- /**/ static Comp ! parsecompsw(int gflag) { Comp c1, c2, c3, excl = NULL; ! c1 = parsecomp(gflag); if (!c1) return NULL; if (isset(EXTENDEDGLOB) && *pptr == Tilde) { *************** *** 607,613 **** mode = 1; pptr++; ! excl = parsecomp(); mode = oldmode; if (!excl) return NULL; --- 612,618 ---- mode = 1; pptr++; ! excl = parsecomp(gflag); mode = oldmode; if (!excl) return NULL; *************** *** 618,624 **** if (*pptr == Bar) { /* get the next alternative after the | */ pptr++; ! c3 = parsecompsw(pathadd); if (!c3) return NULL; } else { --- 623,629 ---- if (*pptr == Bar) { /* get the next alternative after the | */ pptr++; ! c3 = parsecompsw(gflag); if (!c3) return NULL; } else { *************** *** 631,637 **** c2->left = c1; c2->right = c3; c2->exclude = excl; ! if (pathadd) c2->stat |= C_PATHADD; return c2; } --- 636,642 ---- c2->left = c1; c2->right = c3; c2->exclude = excl; ! if (gflag & GF_PATHADD) c2->stat |= C_PATHADD; return c2; } *************** *** 695,701 **** } } else { /* parse single path component */ ! if (!(c1 = parsecompsw(1))) return NULL; /* then do the remaining path compoents */ if (*pptr == '/' || !*pptr) { --- 700,706 ---- } } else { /* parse single path component */ ! if (!(c1 = parsecompsw(GF_PATHADD|GF_TOPLEV))) return NULL; /* then do the remaining path compoents */ if (*pptr == '/' || !*pptr) { *************** *** 2148,2154 **** remnulargs(str); mode = 1; /* no path components */ pptr = str; ! return parsecompsw(0); } /* blindly turn a string into a tokenised expression without lexing */ --- 2153,2159 ---- remnulargs(str); mode = 1; /* no path components */ pptr = str; ! return parsecompsw(GF_TOPLEV); } /* blindly turn a string into a tokenised expression without lexing */ -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bug or feature? 1997-06-16 9:15 ` bug or feature? Peter Stephenson @ 1997-06-18 18:13 ` Vinnie Shelton 1997-06-19 8:55 ` Peter Stephenson 0 siblings, 1 reply; 12+ messages in thread From: Vinnie Shelton @ 1997-06-18 18:13 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list Peter, Your patch (in archive/latest/3249) failed for me vs. 3.0.4. Can you generate a patch against 3.0.4? thanks, vin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bug or feature? 1997-06-18 18:13 ` Vinnie Shelton @ 1997-06-19 8:55 ` Peter Stephenson 0 siblings, 0 replies; 12+ messages in thread From: Peter Stephenson @ 1997-06-19 8:55 UTC (permalink / raw) To: Zsh hackers list Vinnie Shelton wrote: > Peter, > Your patch (in archive/latest/3249) failed for me vs. 3.0.4. > Can you generate a patch against 3.0.4? Here's a patch against 3.0.3. There are just some minor structural changes in the code. *** Src/glob.c.orig Tue Jun 3 07:11:26 1997 --- Src/glob.c Thu Jun 19 10:51:09 1997 *************** *** 1578,1583 **** --- 1578,1587 ---- zerr("no idea how you got this error message.", NULL, 0); } + /* Flags passed down to guts when compiling */ + #define GF_PATHADD 1 /* file glob, adding path components */ + #define GF_TOPLEV 2 /* outside (), so ~ ends main match */ + static char *pptr; /* current place in string being matched */ static Comp tail = 0; static int first; /* are leading dots special? */ *************** *** 1843,1849 **** remnulargs(str); mode = 1; /* no path components */ pptr = str; ! return parsecompsw(0); } /* Parse a series of path components pointed to by pptr */ --- 1847,1853 ---- remnulargs(str); mode = 1; /* no path components */ pptr = str; ! return parsecompsw(GF_TOPLEV); } /* Parse a series of path components pointed to by pptr */ *************** *** 1905,1911 **** } } else { /* parse single path component */ ! if (!(c1 = parsecompsw(1))) return NULL; /* then do the remaining path compoents */ if (*pptr == '/' || !*pptr) { --- 1909,1915 ---- } } else { /* parse single path component */ ! if (!(c1 = parsecompsw(GF_PATHADD|GF_TOPLEV))) return NULL; /* then do the remaining path compoents */ if (*pptr == '/' || !*pptr) { *************** *** 1926,1932 **** /**/ Comp ! parsecomp(void) { Comp c = (Comp) alloc(sizeof *c), c1, c2; char *cstr, *ls = NULL; --- 1930,1936 ---- /**/ Comp ! parsecomp(int gflag) { Comp c = (Comp) alloc(sizeof *c), c1, c2; char *cstr, *ls = NULL; *************** *** 1946,1952 **** /* negate remaining pattern */ pptr++; c->str = dupstrpfx(cstr, pptr - cstr); ! if (!(c->next = parsecomp())) return NULL; return c; } --- 1950,1956 ---- /* negate remaining pattern */ pptr++; c->str = dupstrpfx(cstr, pptr - cstr); ! if (!(c->next = parsecomp(gflag))) return NULL; return c; } *************** *** 1963,1969 **** c1 = (Comp) alloc(sizeof *c1); *(c1->str = dupstring("?")) = Quest; c1->stat |= C_ONEHASH; ! if (!(c2 = parsecomp())) return NULL; c1->next = c2; c->next = c1; --- 1967,1973 ---- c1 = (Comp) alloc(sizeof *c1); *(c1->str = dupstring("?")) = Quest; c1->stat |= C_ONEHASH; ! if (!(c2 = parsecomp(gflag))) return NULL; c1->next = c2; c->next = c1; *************** *** 1990,1996 **** } } /* Parse the remaining pattern following the group... */ ! if (!(c1 = parsecomp())) return NULL; /* ...remembering what comes after it... */ tail = dpnd ? NULL : c1; --- 1994,2000 ---- } } /* Parse the remaining pattern following the group... */ ! if (!(c1 = parsecomp(gflag))) return NULL; /* ...remembering what comes after it... */ tail = dpnd ? NULL : c1; *************** *** 2027,2033 **** c1->next = c2; c2->stat |= C_ONEHASH; /* parse the rest of the pattern and return. */ ! c2->next = parsecomp(); if (!c2->next) return NULL; c->str = dupstrpfx(cstr, ls - cstr); --- 2031,2037 ---- c1->next = c2; c2->stat |= C_ONEHASH; /* parse the rest of the pattern and return. */ ! c2->next = parsecomp(gflag); if (!c2->next) return NULL; c->str = dupstrpfx(cstr, ls - cstr); *************** *** 2059,2065 **** pptr++; } /* mark if last pattern component in path component or pattern */ ! if (*pptr == '/' || !*pptr) c->stat |= C_LAST; c->str = dupstrpfx(cstr, pptr - cstr); return c; --- 2063,2070 ---- pptr++; } /* mark if last pattern component in path component or pattern */ ! if (*pptr == '/' || !*pptr || ! (isset(EXTENDEDGLOB) && *pptr == Tilde && (gflag & GF_TOPLEV))) c->stat |= C_LAST; c->str = dupstrpfx(cstr, pptr - cstr); return c; *************** *** 2069,2079 **** /**/ Comp ! parsecompsw(int pathadd) { Comp c1, c2, c3, excl = NULL; ! c1 = parsecomp(); if (!c1) return NULL; if (isset(EXTENDEDGLOB) && *pptr == Tilde) { --- 2074,2084 ---- /**/ Comp ! parsecompsw(int gflag) { Comp c1, c2, c3, excl = NULL; ! c1 = parsecomp(gflag); if (!c1) return NULL; if (isset(EXTENDEDGLOB) && *pptr == Tilde) { *************** *** 2082,2088 **** mode = 1; pptr++; ! excl = parsecomp(); mode = oldmode; if (!excl) return NULL; --- 2087,2093 ---- mode = 1; pptr++; ! excl = parsecomp(gflag); mode = oldmode; if (!excl) return NULL; *************** *** 2093,2099 **** if (*pptr == Bar) { /* get the next alternative after the | */ pptr++; ! c3 = parsecompsw(pathadd); if (!c3) return NULL; } else { --- 2098,2104 ---- if (*pptr == Bar) { /* get the next alternative after the | */ pptr++; ! c3 = parsecompsw(gflag); if (!c3) return NULL; } else { *************** *** 2106,2112 **** c2->left = c1; c2->right = c3; c2->exclude = excl; ! if (pathadd) c2->stat |= C_PATHADD; return c2; } --- 2111,2117 ---- c2->left = c1; c2->right = c3; c2->exclude = excl; ! if (gflag & GF_PATHADD) c2->stat |= C_PATHADD; return c2; } -- Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <000001bff88e$b7ff9c90$21c9ca95@mow.siemens.ru>]
* Re: Bug or feature? [not found] <000001bff88e$b7ff9c90$21c9ca95@mow.siemens.ru> @ 2000-07-28 12:40 ` Peter Stephenson [not found] ` <Pine.LNX.4.10.10007281533350.23804-100000@verso.st.jyu.fi> 0 siblings, 1 reply; 12+ messages in thread From: Peter Stephenson @ 2000-07-28 12:40 UTC (permalink / raw) To: Juhapekka Tolvanen, Zsh hackers list > > ii zsh 3.1.6.pws21-1 A shell with lots of features. > > Agreed :-) > > That's pretty old. Could you install at least 3.1.9? In any case, I presume i > t > was a bug, since it works in current version. I don't know if it's that simple, but I don't know if it isn't either. We've got an old 3.1.6-dev-19 here and it works there, too. But there was no such version as 3.1.6.pws21 since I'd switched to using dev by then. So I don't know what this version is. (It would be helpful if people indicated the local part of their version numbers like Mandrake do by sticking `mdk' at the point where their part of the number starts.) I can only guess it's a really old 3.1.6 and the 21 means something different. I know there were bugs with exit traps way back when (though probably pre-3.1.6). I'd certainly like to know if it's there with the latest version. -- Peter Stephenson <pws@csr.com> Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <Pine.LNX.4.10.10007281533350.23804-100000@verso.st.jyu.fi>]
* Re: Bug or feature? [not found] ` <Pine.LNX.4.10.10007281533350.23804-100000@verso.st.jyu.fi> @ 2000-07-28 16:09 ` Bart Schaefer 2000-07-28 16:30 ` Juhapekka Tolvanen 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2000-07-28 16:09 UTC (permalink / raw) To: Zsh hackers list; +Cc: Juhapekka Tolvanen On Jul 28, 1:40pm, Peter Stephenson wrote: } } > > ii zsh 3.1.6.pws21-1 A shell with lots of features. } > } > That's pretty old. Could you install at least 3.1.9? In any case, I } > presume it was a bug, since it works in current version. } } I don't know if it's that simple, but I don't know if it isn't either. } We've got an old 3.1.6-dev-19 here and it works there, too. But there was } no such version as 3.1.6.pws21 since I'd switched to using dev by then. We could find out for sure if Juhapekka would run `echo $ZSH_VERSION'. The Debian package number is only of interest in figuring out if they made a change that broke something. On Jul 28, 3:51pm, Juhapekka Tolvanen wrote: } } Well, Potato is frozen state right now and it will go to stable state very } soon. No single package in stable Debian distribution is allowed to have so } called release critical bugs. And that means, that zsh provided with Potato } has no release critical bugs. It means no package in Potato has a release-critical bug that the Debian team knows about. Not quite the same thing. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug or feature? 2000-07-28 16:09 ` Bart Schaefer @ 2000-07-28 16:30 ` Juhapekka Tolvanen 2000-07-28 17:10 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Juhapekka Tolvanen @ 2000-07-28 16:30 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list On Fri, 28 Jul 2000, Bart Schaefer wrote: > On Jul 28, 1:40pm, Peter Stephenson wrote: > } > } > > ii zsh 3.1.6.pws21-1 A shell with lots of features. > } > > } > That's pretty old. Could you install at least 3.1.9? In any case, I > } > presume it was a bug, since it works in current version. > } > } I don't know if it's that simple, but I don't know if it isn't either. > } We've got an old 3.1.6-dev-19 here and it works there, too. But there was > } no such version as 3.1.6.pws21 since I'd switched to using dev by then. > We could find out for sure if Juhapekka would run `echo $ZSH_VERSION'. The > Debian package number is only of interest in figuring out if they made a > change that broke something. juhtolv@heresy : /home/juhtolv % echo $ZSH_VERSION 7717 | pts/5 3.1.6-dev-21 juhtolv@heresy : /home/juhtolv % zsh --version 7718 | pts/5 juhtolv@heresy : /home/juhtolv % 7713 | pts/5 Whatta fsck??? Grrrr..... http://www.math.fu-berlin.de/user/guckes/version/ > On Jul 28, 3:51pm, Juhapekka Tolvanen wrote: > } Well, Potato is frozen state right now and it will go to stable state very > } soon. No single package in stable Debian distribution is allowed to have so > } called release critical bugs. And that means, that zsh provided with Potato > } has no release critical bugs. > It means no package in Potato has a release-critical bug that the Debian > team knows about. Not quite the same thing. I don't think, they will consider that bug "release critical". AFAIK "critical" and "grave" bugs are considered "release critical bugs". If I will send a bug report and put "grave" to Severity:-field, I think I'll be flamed by that Debian developer, that maintains Debian package of zsh. http://www.debian.org/Bugs/Reporting http://www.debian.org/Bugs/Developer#severities critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. grave makes the package in question unuseable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. important any other bug which makes the package unsuitable for release. normal the default value, for normal bugs. wishlist for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. fixed for bugs that are fixed but should not yet be closed. Bugs fixed by non-maintainer-uploads have their severity set to fixed. -- Juhapekka "naula" Tolvanen * U of Jyväskylä * juhtolv@st.jyu.fi http://www.cc.jyu.fi/~juhtolv/ * * "STRAIGHT BUT NOT NARROW !!" --------------------------------------------------------------- "if i was twice the man i could be, i'd still be half of what you need" Nine Inch Nails ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug or feature? 2000-07-28 16:30 ` Juhapekka Tolvanen @ 2000-07-28 17:10 ` Bart Schaefer 2000-07-28 17:45 ` Juhapekka Tolvanen 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2000-07-28 17:10 UTC (permalink / raw) To: Juhapekka Tolvanen; +Cc: Zsh hackers list On Jul 28, 7:30pm, Juhapekka Tolvanen wrote: } } % zsh --version Hmm, I'm a little surprised that zsh silently ignored that. I believe it's treating it the same as `--' (end of options). Zsh is not a GNU package and doesn't understand any "long options". } http://www.math.fu-berlin.de/user/guckes/version/ Sven's a good guy, but I think he's misguided in this case. (It also hadn't stopped him from being a zsh user, last time I talked to him.) Furthermore, zsh attempts to give a reasonable impersonation of a number of older standard shells, none of which would do what Sven wants when given --version as an argument. I also note: zagzig[265] bash --version bash: --: bad option Given that `--' is a perfectly good option on its own, it's pretty clear that bash is treating `--version' as `-' followed by eight individual single-letter options. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug or feature? 2000-07-28 17:10 ` Bart Schaefer @ 2000-07-28 17:45 ` Juhapekka Tolvanen 2000-07-29 19:05 ` Bart Schaefer 0 siblings, 1 reply; 12+ messages in thread From: Juhapekka Tolvanen @ 2000-07-28 17:45 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list On Fri, 28 Jul 2000, Bart Schaefer wrote: > On Jul 28, 7:30pm, Juhapekka Tolvanen wrote: > } % zsh --version > Hmm, I'm a little surprised that zsh silently ignored that. I believe > it's treating it the same as `--' (end of options). Zsh is not a GNU > package and doesn't understand any "long options". Is it too much work to teach zsh to understand long-options? How about adding some single-letter option, that makes zsh to output its version-number and then exit succesfully? -v, -V, -r and -R are already reserved, though. > I also note: > > zagzig[265] bash --version > bash: --: bad option juhtolv@heresy : /home/juhtolv % bash --version 7720 | pts/5 GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu) Copyright 1998 Free Software Foundation, Inc. Which version of bash you have? BTW In Red Hat Linux bash version 2.0.* is in package bash2. -- Juhapekka "naula" Tolvanen * U of Jyväskylä * juhtolv@st.jyu.fi http://www.cc.jyu.fi/~juhtolv/ * * "STRAIGHT BUT NOT NARROW !!" --------------------------------------------------------------- "if i was twice the man i could be, i'd still be half of what you need" Nine Inch Nails ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug or feature? 2000-07-28 17:45 ` Juhapekka Tolvanen @ 2000-07-29 19:05 ` Bart Schaefer 2000-07-29 22:40 ` Trond Eivind Glomsrød 0 siblings, 1 reply; 12+ messages in thread From: Bart Schaefer @ 2000-07-29 19:05 UTC (permalink / raw) To: Juhapekka Tolvanen; +Cc: Zsh hackers list On Jul 28, 8:45pm, Juhapekka Tolvanen wrote: } } Is it too much work to teach zsh to understand long-options? The whole option system is pretty tightly tied to single-letter option representation (both for shell options and for switches of builtins). The best we could do is some kind of one-to-one translation. } Which version of bash you have? I don't know, it won't tell me. (Grin) Sorry, couldn't resist. BASH_VERSION says 1.14.7(1). } BTW In Red Hat Linux bash version 2.0.* is in package bash2. Only if you have a much newer version of Red Hat than I do. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug or feature? 2000-07-29 19:05 ` Bart Schaefer @ 2000-07-29 22:40 ` Trond Eivind Glomsrød 0 siblings, 0 replies; 12+ messages in thread From: Trond Eivind Glomsrød @ 2000-07-29 22:40 UTC (permalink / raw) To: Bart Schaefer; +Cc: Juhapekka Tolvanen, Zsh hackers list "Bart Schaefer" <schaefer@candle.brasslantern.com> writes: > } BTW In Red Hat Linux bash version 2.0.* is in package bash2. > > Only if you have a much newer version of Red Hat than I do. That's not a recent change - it's been that way for some time (all 6.x) This has since been changed, and in Rawhide you'll find /bin/bash is bash 2. -- Trond Eivind Glomsrød Red Hat, Inc. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug or feature?
@ 2000-07-31 15:00 Clint Adams
0 siblings, 0 replies; 12+ messages in thread
From: Clint Adams @ 2000-07-31 15:00 UTC (permalink / raw)
To: zsh-workers
Something ate the Subject line on this and ezmlm got upset.
----- Forwarded message from MAILER-DAEMON@sunsite.auc.dk -----
> no such version as 3.1.6.pws21 since I'd switched to using dev by then. So
It is actually dev21 with a few patches. The pws was retained because
"3.1.6.dev14" < "3.1.6pws13" according to Debian package management.
The hyphens need to disappear because the portion to the right of
the hyphen represents the Debian "delta". Thus "3.1.6-dev-21" gets
munged to "3.1.6.pws21".
As for the state of the freeze, even a 'critical' or 'grave' bug isn't
going to change the fact that Debian 2.2 will ship with the aforementioned
non-version.
2.2r1 (or whatever inane thing the next "point" release ends up being called)
will have the latest and greatest 3.1.9 and 3.0.8, I'd wager.
----- End forwarded message -----
^ permalink raw reply [flat|nested] 12+ messages in thread
* Bug or feature? @ 2005-10-31 22:08 DervishD 0 siblings, 0 replies; 12+ messages in thread From: DervishD @ 2005-10-31 22:08 UTC (permalink / raw) To: Zsh Workers Hi all :) Let's assume this script (called "testscript"): #!/bin/zsh # This is line 2 alias testalias='\ print This is an alias that spans;\ print multiple lines;\ ' testalias # Next line is 12 print $LINENO return 0 # This is the last line $ ./testscript 15 It prints 15 instead of (the correct) 12, due to the alias expansion, but this is annoying when the script has an error and zsh prints the offending line number, because when you edit the script the error is a few lines above. Is this a bug or a feature? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net http://www.pleyades.net & http://www.gotesdelluna.net It's my PC and I'll cry if I want to... ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-10-31 22:07 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <19970613182010.48585@retriever> 1997-06-16 9:15 ` bug or feature? Peter Stephenson 1997-06-18 18:13 ` Vinnie Shelton 1997-06-19 8:55 ` Peter Stephenson [not found] <000001bff88e$b7ff9c90$21c9ca95@mow.siemens.ru> 2000-07-28 12:40 ` Bug " Peter Stephenson [not found] ` <Pine.LNX.4.10.10007281533350.23804-100000@verso.st.jyu.fi> 2000-07-28 16:09 ` Bart Schaefer 2000-07-28 16:30 ` Juhapekka Tolvanen 2000-07-28 17:10 ` Bart Schaefer 2000-07-28 17:45 ` Juhapekka Tolvanen 2000-07-29 19:05 ` Bart Schaefer 2000-07-29 22:40 ` Trond Eivind Glomsrød 2000-07-31 15:00 Clint Adams 2005-10-31 22:08 DervishD
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).