From mboxrd@z Thu Jan 1 00:00:00 1970 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes Date: Tue, 2 Feb 1999 15:19:06 +0100 (MET) Message-Id: <199902021419.PAA09047@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Tue, 2 Feb 1999 13:36:46 +0300 Subject: Re: Incomplete/misleading description of GLOB_SUBST and $~ paramter expansion flag X-Mailing-List: 5179 Andrej Borsenkow wrote: > This resulted from this line of Sven's: > > if [[ "$cmd1" == $~pat || "$cmd2" == $~pat ]] then > > (again something, I didn't know before and that is hard to infer from > manuals :-( > > The current description of above items imply, that they affect only file > name expansion (globbing). The reality is, they prevent globbing > metacharacters from being quoted in _any_ context where glob pattern is > used. This includes, but is not limited to, filename expansion. The patch below cleans up the docs for this and for completion matching. Still no examples in the `$~foo' case, though. Bye Sven diff -u od/Zsh/compctl.yo Doc/Zsh/compctl.yo --- od/Zsh/compctl.yo Mon Feb 1 10:53:36 1999 +++ Doc/Zsh/compctl.yo Tue Feb 2 15:08:32 1999 @@ -580,7 +580,8 @@ a letter followed by a colon and the patterns describing which character sequences on the line match which character sequences in the words. -The letters understood are: tt(l), tt(r), tt(m), tt(L), tt(R), and tt(M). +The letters understood are: + startitem() item(tt(m) and tt(M))( These describe patterns that match anywhere in the words. The colon should @@ -605,20 +606,20 @@ enditem() Each pattern is either an empty string or consists of a sequence of -character (possibly quoted), question marks, character classes, and -correspondence classes. Normal characters match only themselves, question -marks match any character, and character classes are formed as for -globbing and match the same characters as there. -Correspondence classes are formed like character classes with two -differences: they are delimited by a pair of braces and negated +characters (possibly quoted with backslashes), question marks, +character classes, and correspondence classes. Normal characters match +only themselves, question marks match any character, and character +classes are formed as for globbing and match the same characters as +there. Correspondence classes are formed like character classes with +two differences: they are surrounded by a pair of braces and negated classes are not allowed (i.e. the characters tt(!) and tt(^) have no special meaning directly after the opening brace). Correspondence classes are used to conveniently describe that several characters on the line match several other characters in the word. For -example, if you want to define the any lowercase letter on the line +example, if you want to define that any lowercase letter on the line matches the corresponding uppercase letter in the word all you need to -write down is: `tt(m:{a-z}={A-Z})'. More than one correspondence class +write is: `tt(m:{a-z}={A-Z})'. More than one correspondence class may be given on either side of the equal sign, in this case the first class on the left says which character matches for the first class on the right, the second class on either side work together, and so on. @@ -643,16 +644,15 @@ lowercase forms use the substring from the word, so this should be used if the exact words produced by the completion code need to be used. The uppercase forms use the substring from the command line and -should be used if the typed string need to be retained. +should be used if the typed string needs to be retained. Examples: -startitem() The option tt(-o) produces option names in all-lowercase form, without underscores, and without the optional tt(no) at the beginning even -though the buitlins tt(setopt) and tt(unsetopt) understand opotion +though the builtins tt(setopt) and tt(unsetopt) understand option names with uppercase letters, underscores, and the optional tt(no). -So we want to be able to say, that in this case an prefix tt(no) and +So we want to be able to say that in this case an prefix tt(no) and any underscore may be ignored when trying to match the produced words, and that uppercase letters on the line match the corresponding lowercase letters in the words. This can be done with: @@ -670,7 +670,7 @@ uppercase letter on the line matches the corresponding lowercase letter in the word. The use of the uppercase forms of the specification characters (tt(L) and tt(M)) guarantees that the special -wrinting on the command line (and especially the option tt(no)) will +writing on the command line (and especially the option tt(no)) will not be erased. As a second example we will make completion case insensitive. For this @@ -689,7 +689,7 @@ have to use: indent( -tt(compctl -M 'm:{a-z}={A-Z} m:{A-Z}={a-z}') +tt(compctl -M 'm:{a-zA-Z}={A-Za-z}') ) A nice example for the use of tt(*) patterns is partial word @@ -697,7 +697,7 @@ complete to strings like tt(comp.source.unix), i.e. you consider the word to consist of multiple parts (separated by the dot in the example) and each part should be completed separately. Defining such -forms of matching is simple, for example if we want to separately +forms of matching is simple. For example, if we want to separately complete word parts separated by dots, commas, underscores, and hyphens, we can do this by saying: @@ -710,7 +710,7 @@ word which has the effect we wanted. The second specification is needed to make this work when the cursor is in the middle of the word and the option tt(COMPLETE_IN_WORD) is set. In this case the -completion code would normally try to match word that end with the +completion code would normally try to match words that end with the string that is already on the command line, but in our example we would like the code to match words even if they contain extra characters after the string on the line. Hence we say that the empty @@ -719,7 +719,7 @@ The form of tt(compctl) that defines the global matching specifications is a bit more powerful than described until now. It -accepts not only one specification strin, but any number of them. When +accepts not only one specification string, but any number of them. When completion is attempted, the code first uses the definitions from the first string. If no words could be matched with these specifications, it tries the whole thing again with the specifications from the second @@ -737,10 +737,10 @@ ) If using the first specification string does not produce matches, the -second one is tried. The two descriptions it this string say that the +second one is tried. The two descriptions in this string say that the empty string at the beginning and end of the string on the line matches any characters at the beginning or end of the word. -enditem() + texinode(Example)()(Matching Control)(Programmable Completion) sect(Example) nofill(tt(compctl -u -x 's[tt(PLUS())] c[-1,-f],s[-f+PLUS()]' -g '~/Mail/*(:t)' \ diff -u od/Zsh/expn.yo Doc/Zsh/expn.yo --- od/Zsh/expn.yo Mon Feb 1 10:53:36 1999 +++ Doc/Zsh/expn.yo Tue Feb 2 15:16:18 1999 @@ -477,9 +477,10 @@ pindex(GLOB_SUBST) Turn on the tt(GLOB_SUBST) option for the evaluation of var(spec); if the `tt(~)' is doubled, turn it off. When this option is -set, any pattern characters resulting -from parameter expansion are eligible for filename expansion and filename -generation. +set, the string resulting from the expansion will be interpreted as a +pattern thus becoming eligible for filename expansion and filename +generation and usable as a pattern in pattern-matching contexts like +the `tt(=)' and `tt(!=)' operators in conditions. ) enditem() -- Sven Wischnowsky wischnow@informatik.hu-berlin.de