bash: /usr/local/share/bashrun/bashrc: line 209: syntax error in conditional expression: unexpected token `('
bash: /usr/local/share/bashrun/bashrc: line 209: syntax error near `^(['
bash: /usr/local/share/bashrun/bashrc: line 209: ` if [+): ]]; then '
I can't reproduce this error. Please state your bash and bashrun version when reporting bugs.
FYI, there is indeed a =~ operator in bash. Straight from the bash manual:
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)).
Sorry. It's bash 3.1.17(2) and bashrun 0.15. I only see it when I let it use xterm and scroll up. When I set it to use mlterm, I don't see it. However, when I source /usr/local/share/bashrun/bashrc manually, it shows those errors no matter what terminal I'm using.
Anyway, I've found the problem. The operand needs to be quoted (single or double) if it's less than bash 3.2, because of the parentheses.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I feel reluctant to rewriting the regular expressions (which would involve shopt -s compat31 for bash versions > 3.1) and thus further obfuscating them in order to support a version of bash which is almost four years old… I was unaware of this issue until now, since bashrun development started on bash 3.2.033. Thus I also can't guarantee that bashrun will work properly on 3.1 or earlier even if these errors are fixed. (It will definitely not work on bash versions prior to 3.0). I admit that I didn't make these requirements explicit anywhere in the past, which I will do for future releases.
Also, you are the first to report this issue. May I ask what system/distribution (and which version thereof) you are running? Is there a specific reason you need to stick with 3.1.17? If so, are there other users in the same situation? In any case, you're likely to encounter similar issues with a lot of other bash scripts written recently.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fair enough. It was easy enough for me to quote them myself. I'm using Slackware current, and I'll see if I can ask the maintainers to update bash. Anyone using Slackware will be in my situation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Uh, ok… if it's slackware then I'll of course make bashrun compatible with their version of bash. Seems I underestimated how conservative distributions can be :) Thanks again!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thinking about this again, I've changed my mind… I really don't want to support versions of bash prior to 3.2. Slackware is the only distro I'm aware of that still uses bash 3.1 in it's latest release (13.0), and since slackware's "current" and "testing" branches already feature packages of bash 4.x I'd suggest to use those instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When starting:
bash: /usr/local/share/bashrun/bashrc: line 209: syntax error in conditional expression: unexpected token `('
bash: /usr/local/share/bashrun/bashrc: line 209: syntax error near `^(['
bash: /usr/local/share/bashrun/bashrc: line 209: ` if [+): ]]; then '
There is no =~ operator in bash!
http://www.tldp.org/LDP/abs/html/comparison-ops.html
I can't reproduce this error. Please state your bash and bashrun version when reporting bugs.
FYI, there is indeed a =~ operator in bash. Straight from the bash manual:
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)).
See also: http://www.tldp.org/LDP/abs/html/regexp.html, where it says: "As of version 3, Bash has acquired its own RE-match operator: =~."
Sorry. It's bash 3.1.17(2) and bashrun 0.15. I only see it when I let it use xterm and scroll up. When I set it to use mlterm, I don't see it. However, when I source /usr/local/share/bashrun/bashrc manually, it shows those errors no matter what terminal I'm using.
Anyway, I've found the problem. The operand needs to be quoted (single or double) if it's less than bash 3.2, because of the parentheses.
Thanks for pointing out this issue.
I feel reluctant to rewriting the regular expressions (which would involve shopt -s compat31 for bash versions > 3.1) and thus further obfuscating them in order to support a version of bash which is almost four years old… I was unaware of this issue until now, since bashrun development started on bash 3.2.033. Thus I also can't guarantee that bashrun will work properly on 3.1 or earlier even if these errors are fixed. (It will definitely not work on bash versions prior to 3.0). I admit that I didn't make these requirements explicit anywhere in the past, which I will do for future releases.
Also, you are the first to report this issue. May I ask what system/distribution (and which version thereof) you are running? Is there a specific reason you need to stick with 3.1.17? If so, are there other users in the same situation? In any case, you're likely to encounter similar issues with a lot of other bash scripts written recently.
Fair enough. It was easy enough for me to quote them myself. I'm using Slackware current, and I'll see if I can ask the maintainers to update bash. Anyone using Slackware will be in my situation.
Uh, ok… if it's slackware then I'll of course make bashrun compatible with their version of bash. Seems I underestimated how conservative distributions can be :) Thanks again!
Thinking about this again, I've changed my mind… I really don't want to support versions of bash prior to 3.2. Slackware is the only distro I'm aware of that still uses bash 3.1 in it's latest release (13.0), and since slackware's "current" and "testing" branches already feature packages of bash 4.x I'd suggest to use those instead.