Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
I prefer plan C: leave it alone. It's working fine.
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Pierre Gaston wrote: Just quote the spaces and not the special chars: Pierre, your suggestion doesn't help clean up strings used inside of double brackets. I wanted to avoid the need for multiple backslashes in an expression as it makes the expression less readable and more error prone. Note that the same problem and solution exist when you use filename generation: for f in /some path/ withspaces/*; do # doesn't work the path contains spaces I'm aware of that, but since [[ and ]] are new, and =~ is new, there is no legal interpretation for multiple arguments on either side of the =~ operator. Since =~ permits comparing variables _without_ putting quotes around them, (as would normally be the case if you used the single square brackets and plain '='), why not extend that idea to not needing quotes between the =~ and either side of the double square brackets so literal strings benefit from not needing quotes as well. Of course, if quotes *are* included on the rhs, then the pattern matching (glob or regex) would be disabled as happens now. Is there a downside to this syntax or this idea?
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On Mon, Sep 20, 2010 at 10:28 PM, Linda Walsh b...@tlinx.org wrote: Pierre Gaston wrote: Just quote the spaces and not the special chars: Pierre, your suggestion doesn't help clean up strings used inside of double brackets. I wanted to avoid the need for multiple backslashes in an expression as it makes the expression less readable and more error prone. Multiple backslash? I gave only one example with one backslash and gave several without one, and even a solution where the regexp is inside quotes like you initially requested. Note that the same problem and solution exist when you use filename generation: for f in /some path/ withspaces/*; do # doesn't work the path contains spaces I'm aware of that, but since [[ and ]] are new, and =~ is new, there is no legal interpretation for multiple arguments on either side of the =~ operator. Since =~ permits comparing variables _without_ putting quotes around them, (as would normally be the case if you used the single square brackets and plain '='), why not extend that idea to not needing quotes between the =~ and either side of the double square brackets so literal strings benefit from not needing quotes as well. Of course, if quotes *are* included on the rhs, then the pattern matchings (glob or regex) would be disabled as happens now. Is there a downside to this syntax or this idea? Besides introducing yet another parsing exception, while the actual problem and solution probably exist for as long as the bourne shell exist (and maybe before), what about: [[ foo =~ bar baz ]] Should bar baz be considered as one regexp? if not, how would you write a regexp matching `foo baz' ? or `foo baz.*' ? if yes how would you do and and with a regexp? What if you want to match ` bar baz ' with trailing or leading spaces? Should you be able to also use space without quotes in this case and have [[ foo =~ bar ]] and [[ foo =~ bar ]] have different meanings? Space are used to separates arguments everywhere in the shell and yes quotes are sometimes ugly and often causes trouble until you take the time to learn to use them, but it's the price to pay to avoid putting quotes around every argument every time you use the command line interactively. I don't see how your suggestion would help in the end since you would still need to quotes some chars like or || and the handling of space would not be consistent with the rest of the shell.
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On Sun, Sep 19, 2010 at 2:54 AM, Linda Walsh b...@tlinx.org wrote: O rats, I think I understand why you have the double q'marks do what they do in double brackets. 1) Even though I've seen the construct many times, I've almost never use glob-expression matching in a case statement. It would appear that is the only place a glob can match an expression in 'old shell' (w/o the double brackets), yes? So [[ ]] changes the syntax such that matching is only performed against arguments in the command line, *instead* of against the fs(filesystem). Thus to parallel the implementation of expansion against the command line and the fact that quotes disable such expansion, (while dq's still allow the variable substitution), [[ ]] was introduced (among, perhaps other reasons I am not listing). In a way, dbrkts are the same as sbrkts, but double quoting is assumed around the arguments so 'variables' with embedded spacing are handled properly. Since it's already a quoted expression (sorta), adding quotes disables the matching. However, 1 disparity == a regex in single brackets is in no danger of matching against the file system OR at all (unless by accident), as regex's are only seen as such next to =~ in dbrkts. Hmmm.. Then what possible interpretations could this have: a='one two three' if [[ $a =~ one t.. three ]]; ... I would say that since it *has* no legal syntax, currently, that it be defined such that anything between the operators and the double sq brackets be taken as a grouped expression == i.e. as though double quotes were around them. That would solve the problem the problem consistently. I.e. with square double brackets, then expressions on the right and left side are always grouped as though they were in a variable. It's unfortunate, that operations in double brackets, are not (or, were not) defined as communicative as they are in single brackets. Was there a reason for that decision? I.e. if [ me?t == me?t ] ; ... will match if meat is in the current directory, but double brackets doesn't seem to work with globs on both sides of == (anymore than regexs do on either side of =~). I was going to suggest some other quote operator to put around a regex, that would allow it to contain spaces, but symmetrically, it should also work around a glob rhs with ==. But given that, currently if [[ xx yz == xx * ]], has no current legal definition, any more than if [[ xx yz =~ xx .* ]] has regex's, it seems reasonable to take anything to either side of the operator up to a double bracket, as 1 expression with embedded spaces. That would solve my issues with dquotes not being usable to group, and cause no backward portability problems. -l Just quote the spaces and not the special chars: [[ xx yx = 'xx '* ]] or [[ xx yz = xx\ * ]] or any other variation that escape or put the space inside quotes but not the * In the same way: [[ xx yz =~ xx' '.* ]] if you prefer to quote everything, use a helper variable: regex='xx .*' [[ xx yz =~ $regex ]] No quotes, around the expansion, .* keeps its meaning, the space is not a problem as word splitting of the expansion doesn't occur inside [[ ]] (This trick has the side effect of being backward compatible with bash3.1) Note that the same problem and solution exist when you use filename generation: for f in /some path/ withspaces/*; do # doesn't work the path contains spaces for f in /some path/with spaces/*; do # doesn't work * is not special anymore for f in /some path/with spaces/* ;do # ok, spaces are quoted but not the * The only difference is that since wordsplitting is occuring you cannot use the variable trick to quote everything: glob='/some path/with spaces/*' for f in $glob; do # fails the path is split into word for f in $glob;do # fails the * is quoted
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
I'm sorry to not answer a message directly, but I didn't get the mails of this list during the last day - no idea why. Quoting text from the pipermail archive. After initialÄy introducing =~, Chet made it consistent with =/== in a second version, means: =/== doesn't do pattern matching for parts inside quotes, =~ doesn't du regexp matching for parts inside quotes. Except this isnt' true. Quoting example C: t='one two three' a='one two three' 1) if [[ $t == $a ]]; then echo 'Matches'; fi 2) if [[ $t == $a ]]; then echo 'Matches'; fi examples. The above does match. the pattern in $a matches the pattern in $t whether it is in quotes or not. But with =~ it is different: t='one two three' a='one t.. three' 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi 4) if [[ $t =~ $a ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi Test with a='one t?? three', i.e. use a pattern matching special character. Or for the regex case, use NO regex special character. Then both should behave the same: Patter matching: $ t=one two three $ a=one t?? three $ [[ $t = $a ]]; echo $? 0 $ [[ $t = $a ]]; echo $? 1 Regular expression matching: $ t=one two three $ a=one t.. three $ [[ $t =~ $a ]]; echo $? 0 $ [[ $t =~ $a ]]; echo $? 1 Regards, Jan
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Chet Ramey wrote: On 9/17/10 6:50 PM, Linda Walsh wrote: Jan Schampera wrote: == is the same as =, my suggestion is to NOT touch that. === I'm not going to say too much on this. The behavior as it exists now is very consistent: for both == and =~, any part of the rhs that's quoted is matched as a string. Period. It was a mistake not to do it that way in the first place. --- No it wasn't. Because a regex is NOT inherently a regex, globbing chars ARE. You put quotes around glob characters to stop their 'globbing', because it is the characters that 'glob'. The same is not true of regex expressions. Regex expressions are simple strings. Period. They have no special meaning apart from use with =~ or some similar operator. You can't type ls t.. and expect it to do a regex match. But, with the operator that says 'take right hand expression as 'RE', do we get consistent behavior?: t='one two three' a='one t.. three' 3) if [[ $t =~ $a ]]; then echo 'Matches'; fi 4) if [[ $t =~ $a ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi Now, double quotes Don't behave consistently -- AGAIN Again, the examples are not equivalent. --- Why not? They They are both simple strings. If you put the simple string on a line as an arg to to echo or ls, it won't expand into something else. Glob chars will. Why, because it is the glob chars that are the 'operator'. Glob chars aren't constants. they are operators. You quote them to remove their operator properties. But with regex's you don't have to quote them to make them lose their function -- they have no function by themselves. It is only in the presence of a special operator that says treat the rhs as a regex, that they have any meaning. There is no language where quoting a regex makes it NOT a regex. It may change what you are matching, but quotes never deactivate matching when it would otherwise have occurred. You're not helping your argument any by using examples that can at best be considered disingenuous and at worst deliberately misleading. How are they misleading? I use == to compare constant strings. When you compare 'test' with t??t, the globbing operator has precedence and attempts to match the string t??t against test. If it can match the glob pattern against the intput 'test', then it substitutes in the literal string 'test' and that result is passed the the '==' operator, which returns true. IT isn't the == operator that turns t??t into something that can match 'test'. t??t will match 'test' in an 'echo' statement or in an 'ls' statement if there is a file by that name in your current directory. In the case of =~ == it's an override operator that says to treat the rhs as a regex. Quoting it doesn't change anything because the regex is already in its terminal form before the match is attempted. There are no active characters in the regex to deactivate. To make the characters in the regex lose their meaning, you remove the regex operator, '=~', and replace it with '=='. It's the =~ that creates the rhs as a regex -- NOT the characters themselves. That's the difference and that why putting quotes around 'inactive' characters should make no difference in how ANOTHER operator (the =~) treats them. Am I making sense yet?
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On Sat, Sep 18, 2010 at 9:45 PM, Linda Walsh b...@tlinx.org wrote: I use == to compare constant strings. When you compare 'test' with t??t, the globbing operator has precedence and attempts to match the string t??t against test. If it can match the glob pattern against the intput 'test', then it substitutes in the literal string 'test' and that result is passed the the '==' operator, which returns true. IT isn't the == operator that turns t??t into something that can match 'test'. t??t will match 'test' in an 'echo' statement or in an 'ls' statement if there is a file by that name in your current directory. You are confusing pattern matching an pathname generation. pathname generation doesn't occur inside [[ ]], like it doesn't in a case. mkdir bar; cd bar # ie go into a directory with no file [ foo = f* ] echo match # doesn't print anything [ doesn't do pattern matching [[ foo = f* ]] echo match # matches because [[ does pattern matching on the contrary: touch bar buz [ foo = b* ] # errors because bash tries to run [ foo = bar buz ] [[ foo = b * ]] # no error pathname generation doesn't occur inside [[ ]] you can also use set -x to see this
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
IT isn't the == operator that turns t??t into something that can match 'test' It absolutely is. If you don't think so, you fundamentally misunderstand its purpose and operation. --- Then where is the operator when you take the same chararcters t??t and place them as an argument to 'echo' or 'ls' echo t??t ls t??t The turn into something else there as well and there's no '==' to be found. There is a difference between glob chars and regex chars. Regex chars only expand in the presence of a regex operator. The glob chars expand on the command line without any operator being present to match files in the current directory of the file system. Regex characters don't do that or is that just gibberish too?
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
On 9/18/10 6:12 PM, Linda Walsh wrote: IT isn't the == operator that turns t??t into something that can match 'test' It absolutely is. If you don't think so, you fundamentally misunderstand its purpose and operation. --- Then where is the operator when you take the same chararcters t??t and place them as an argument to 'echo' or 'ls' echo t??t ls t??t The turn into something else there as well and there's no '==' to be found. I really don't think you understand how this works, but I don't know how to explain it a different way. Pattern matching and regexp matching are essentially the same, and both are active in contexts where they're defined to be active. Pattern matching is a component of pathname expansion, and is active when and where pathname expansion occurs. I think you're concentrating too hard on whether or not there's an `operator' present. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
O rats, I think I understand why you have the double q'marks do what they do in double brackets. 1) Even though I've seen the construct many times, I've almost never use glob-expression matching in a case statement. It would appear that is the only place a glob can match an expression in 'old shell' (w/o the double brackets), yes? So [[ ]] changes the syntax such that matching is only performed against arguments in the command line, *instead* of against the fs(filesystem). Thus to parallel the implementation of expansion against the command line and the fact that quotes disable such expansion, (while dq's still allow the variable substitution), [[ ]] was introduced (among, perhaps other reasons I am not listing). In a way, dbrkts are the same as sbrkts, but double quoting is assumed around the arguments so 'variables' with embedded spacing are handled properly. Since it's already a quoted expression (sorta), adding quotes disables the matching. However, 1 disparity == a regex in single brackets is in no danger of matching against the file system OR at all (unless by accident), as regex's are only seen as such next to =~ in dbrkts. Hmmm.. Then what possible interpretations could this have: a='one two three' if [[ $a =~ one t.. three ]]; ... I would say that since it *has* no legal syntax, currently, that it be defined such that anything between the operators and the double sq brackets be taken as a grouped expression == i.e. as though double quotes were around them. That would solve the problem the problem consistently. I.e. with square double brackets, then expressions on the right and left side are always grouped as though they were in a variable. It's unfortunate, that operations in double brackets, are not (or, were not) defined as communicative as they are in single brackets. Was there a reason for that decision? I.e. if [ me?t == me?t ] ; ... will match if meat is in the current directory, but double brackets doesn't seem to work with globs on both sides of == (anymore than regexs do on either side of =~). I was going to suggest some other quote operator to put around a regex, that would allow it to contain spaces, but symmetrically, it should also work around a glob rhs with ==. But given that, currently if [[ xx yz == xx * ]], has no current legal definition, any more than if [[ xx yz =~ xx .* ]] has regex's, it seems reasonable to take anything to either side of the operator up to a double bracket, as 1 expression with embedded spaces. That would solve my issues with dquotes not being usable to group, and cause no backward portability problems. -l
Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Linda Walsh b...@tlinx.org writes: Or another disparity: C. t='one two three' c='one two three' 1) if [[ $t == $a ]]; then echo 'Matches'; fi 2) if [[ $t == $a ]]; then echo 'Matches'; fi So, the expressions match whether or not $a is in double quotes or not (single quotes would not match, as the $a would be taken literally). Set a='one * three' and try again. Quoting should not disable RE matching. Yes it should. Just like quoting disables glob matching. There must be a way to remove the special meaning of a character. It is NOT the same as double quotes not allowing *file glob expansion*. Globbing is not only about expansion, it is also about matching. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
