Re: RFE: allow double quotes to group multi-words be treated?as?1?arg, w/DQ's stripped off -- including RH =~
clemens fischer wrote: [...] If you received several emails/posts, I apologize. This was a problem with news.eternal-september.org. My article was sent only once from my box. clemens
Re: RFE: allow double quotes to group multi-words be treated as?1?arg, w/DQ's stripped off -- including RH =~
Greg Wooledge wrote:
In this particular case, I would use a glob rather than an ERE,
because h? is much simpler than ^h.$.
Besides, bash's extended globs provide everything ERE's provide. I use
the idiom:
shopt -s extglob
# for example, to check for numbers
case -${something} in -+([[:digit:]])) echo number;; esac
all the time.
clemens
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
On 8/4/2010 10:07 PM, Chet Ramey wrote: On 8/4/10 8:31 AM, Greg Wooledge wrote: In fact, putting the ERE-pattern you want to match against into a variable and then using =~ $variable *is* the recommended practice, if you need to use =~ at all. It is the only way to get consistent results among all the different releases of bash that have =~, since the behavior changed multiple times during the 3.x series. All this is true (as is the text I removed), except that the behavior changed only once: to make quoted text remove any special meaning of the quoted characters to the regular expression matcher. Backwards compatibility, of course, means never having to say you're sorry, but it also means that you never get to fix anything. The behavior change fixed a problem, as I saw it, with the initial implementation. Without this change, there is no clean way to match a literal character that has a special meaning as a regexp operator. Chet Couldn't you have limited to single quotes -- reserving to them the function of literalizing what is between them. Otherwise, could you think other characters you'd prefer to use to group words separated by white-space, together to be matched in a pattern? Or, why should double quotes be functionally the same as single quotes in that situation?
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
Linda Walsh b...@tlinx.org writes: Or, why should double quotes be functionally the same as single quotes in that situation? Handling it different from glob meta characters would make it even more special. 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.
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
On 8/5/10 2:56 AM, Linda Walsh wrote: Couldn't you have limited to single quotes -- reserving to them the function of literalizing what is between them. No. That's not the difference between single and double quotes. Why would I complicate things further? Otherwise, could you think other characters you'd prefer to use to group words separated by white-space, together to be matched in a pattern? And introduce another special character or two? Thank you, no. Or, why should double quotes be functionally the same as single quotes in that situation? Why should they not? Chet -- ``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/
RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
On 8/1/2010 8:11 PM, Chris F.A. Johnson wrote: On Sun, 1 Aug 2010, Linda Walsh wrote: I have: w=/home/law/bin/package: line 5: type: xx: not found The =~ operator is suppose to use the RH Expr as a ext.-regex. So why doesn't this match and print not found? if [[ $w =~ .*not found.* ]]; then echo not found; fi It prints nothing. Seems like such a basic concept. Sorry, this newbie needs help on such trivial matters. :-( When quoted, the right-hand argument is matched as a string, not an expression. So that's how it is... Aren't single quotes reserved for making things literal, while double quotes are used for grouping, yet interpreting what is between them (expansions and such). Is there a reason RH =~ was made inconsistent regarding this practice? I might note: the man page makes no reference to such heinous behavior, leading one me to think I'd use single quotes if I didn't want the contents to be 'active' Though to tell the truth. Technically, it says: An additional binary operator, =~, is available, with the same precedence as == and !=. When it is used, the string to the right of the operator is considered an extended regular expres- sion and matched accordingly (as in regex(3)). I don't see anything about quotes making the =~ operator behave like the == operator. I'm not sure I see the usefulness in that. If there is, then is it necessary to reserving both single and double quotes to make =~ behave like ==? Therefore: RFE: Please make double quotes a grouping operator to group multiple words (as in separated by spaces) together -- even if it is on the RH of =~. Let single quotes be the 'do not interpret this' signifier. Otherwise there's no nice way to group together patterns that have spaces in them. Inserting '\' before every space isn't my idea of nice: Ick! p.s. -- why do you want to have =~ behave like ==? I.e. why these special cases to deactivate regex? Isn't the whole point of =~ to use the RH as an regex? Why have syntax to disable it? I.E -- please consider another possibility: Using double quotes would first do a variable substitution pass, while using single quotes would not -- but use the literal string as a regex. Why throw away useful functionality of quotes with a new operator?
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
On Wednesday 04 Aug 2010 09:06:16 Linda Walsh wrote: On 8/1/2010 8:11 PM, Chris F.A. Johnson wrote: On Sun, 1 Aug 2010, Linda Walsh wrote: I have: w=/home/law/bin/package: line 5: type: xx: not found The =~ operator is suppose to use the RH Expr as a ext.-regex. So why doesn't this match and print not found? if [[ $w =~ .*not found.* ]]; then echo not found; fi It prints nothing. Seems like such a basic concept. Sorry, this newbie needs help on such trivial matters. :-( When quoted, the right-hand argument is matched as a string, not an expression. So that's how it is... Aren't single quotes reserved for making things literal, while double quotes are used for grouping, yet interpreting what is between them (expansions and such). Is there a reason RH =~ was made inconsistent regarding this practice? I might note: the man page makes no reference to such heinous behavior, leading one me to think I'd use single quotes if I didn't want the contents to be 'active' Though to tell the truth. Technically, it says: An additional binary operator, =~, is available, with the same precedence as == and !=. When it is used, the string to the right of the operator is considered an extended regular expres- sion and matched accordingly (as in regex(3)). I don't see anything about quotes making the =~ operator behave like the == operator. I'm not sure I see the usefulness in that. If there is, then is it necessary to reserving both single and double quotes to make =~ behave like ==? From the Changelog: This document details the changes between this version, bash-3.2-alpha, and the previous version, bash-3.1-release. ... 3. New Features in Bash ... f. Quoting the string argument to the [[ command's =~ operator now forces string matching, as with the other pattern-matching operators. From the file COMPAT: 33. Bash-3.2 adopts the convention used by other string and pattern matching operators for the `[[' compound command, and matches any quoted portion of the right-hand-side argument to the =~ operator as a string rather than a regular expression. 34. Bash-4.0 allows the behavior in the previous item to be modified using the notion of a shell `compatibility level'. Finally, to set a given compatibility level, one uses shopt -s compat31 This is in the man page: compat31 If set, bash changes its behavior to that of version 3.1 with respect to quoted arguments to the conditional command's =~ operator. So your example would have worked with shopt -s compat31. -- D.
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
Oi vey. Is that the only thing that will be affected by shopt -s compat31? Or perhaps that shopt needs to be a bit more specific. So your example would have worked with shopt -s compat31. From the file COMPAT: 33. Bash-3.2 adopts the convention used by other string and pattern matching operators for the `[[' compound command, and matches any quoted portion of the right-hand-side argument to the =~ operator as a string rather than a regular expression. ... Other string operators? What other ones operate this way? This is what I'm referring to: a=hi if [[ hi == $a ]]; then echo this matches; fi if [[ 'hi' == '$a' ]] then echo this doesn't; fi I would prefer this work: a=h. if [[ hi =~ $a ]]; That would make sense though I'm not sure what other string operators we are trying to be consistent with. Foolish consistency is the hobgoblin of small minds.
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
Linda Walsh b...@tlinx.org writes: I would prefer this work: a=h. if [[ hi =~ $a ]]; This works (both with and without compat31): [[ hi =~ $a ]] echo matches (It doesn't matter how you quote the lhs, anyway.) 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.
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
Le 04/08/2010 09:27, Davide Brini a écrit : From the Changelog: This document details the changes between this version, bash-3.2-alpha, and the previous version, bash-3.1-release. ... 3. New Features in Bash ... f. Quoting the string argument to the [[ command's =~ operator now forces string matching, as with the other pattern-matching operators. Yet on 3.2.39 (Fedora 10) the old quoted regex behaviour was still there: echo $BASH_VERSION shopt compat31 w=/home/law/bin/package: line 5: type: xx: not found [[ $w =~ .*not found.* ]] echo match 3.2.39(1)-release compat31off match
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
On Wed, Aug 04, 2010 at 02:02:39AM -0700, Linda Walsh wrote: Other string operators? What other ones operate this way? This is what I'm referring to: a=hi if [[ hi == $a ]]; then echo this matches; fi if [[ 'hi' == '$a' ]] then echo this doesn't; fi You are misunderstanding the role of quotes. Double quotes and single quotes have some things in common: * They cause the content inside of them to be treated as a single word, instead of potentially multiple words. * They cause shell/pattern metacharacters such as space, asterisk, parentheses, braces, brackets, etc. to be treated as literal. And one thing different: * Double quotes permit `...` and $ substitutions to occur. Single do not. In your examples, '$a' is matched as the literal string dollar-sign a. $a is matched as a *string* (not a pattern) whose value is the content of the variable a. The example you did NOT show is: if [[ hi == $a ]]; then ... In that one, the $a is matched as a *pattern* (not a string) whose value is the content of the variable a. That is the significance of the double quotes, or their lack. In action: imadev:~$ a='*a' imadev:~$ if [[ baa = $a ]]; then echo yes; else echo no; fi no imadev:~$ if [[ baa = $a ]]; then echo yes; else echo no; fi yes I would prefer this work: a=h. if [[ hi =~ $a ]]; Quoting the right hand side makes bash treat the contents of a as a string rather than a pattern. If you want the contents treated as a pattern (or in this case, an ERE) then remove the quotes. a='^h.$' if [[ hi =~ $a ]]; ... In fact, putting the ERE-pattern you want to match against into a variable and then using =~ $variable *is* the recommended practice, if you need to use =~ at all. It is the only way to get consistent results among all the different releases of bash that have =~, since the behavior changed multiple times during the 3.x series. In this particular case, I would use a glob rather than an ERE, because h? is much simpler than ^h.$.
Re: RFE: allow double quotes to group multi-words be treated as 1 arg, w/DQ's stripped off -- including RH =~
On 8/4/10 8:31 AM, Greg Wooledge wrote: In fact, putting the ERE-pattern you want to match against into a variable and then using =~ $variable *is* the recommended practice, if you need to use =~ at all. It is the only way to get consistent results among all the different releases of bash that have =~, since the behavior changed multiple times during the 3.x series. All this is true (as is the text I removed), except that the behavior changed only once: to make quoted text remove any special meaning of the quoted characters to the regular expression matcher. Backwards compatibility, of course, means never having to say you're sorry, but it also means that you never get to fix anything. The behavior change fixed a problem, as I saw it, with the initial implementation. Without this change, there is no clean way to match a literal character that has a special meaning as a regexp operator. Chet -- ``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/
