2023年1月17日(火) 22:54 Ruiyang Peng <rain@ryp.intirain.cc>:
On 2023/1/17 12:59, Peng Yu wrote:
But it takes more effort to find out that it is not available when it
is counter-intuitive not to provide string operations but arithmetic
operations. In this sense, it is better to add >= <= for string
comparisons to make the interface uniform. After all, it should be
straightforward to add support of >= and <= on the current framework.
[...] but adding it to bash is much faster. So I thought it would be
worth posting this as a suggestion to bug-bash.
I think what is non-trivial here is that we need to change the lexical
rule in [[ ... ]] to support the operators >= and <=. Inside [[ ...
]], the shell special characters such as <, >, |, and & lose their
original meaning as processed in a normal command context, but these
characters are still lexically recognized as if the redirection
operators and command separators. I'd guess [[ ... ]] reuses the lexer
of the normal commands, so we probably need to re-implement another
lexer just to support a different rule with the operators <= and >=.
Also one needs to care about backward compatibility. For example, <=
is processed as an operator `<' plus a word `='.under the current
rule: e.g. [[ "$a" >=foo ]] has been a valid conditional expression
that compares the content of the variable with the string `=foo'. One
possible solution to support the operator `<=' is to break the
backward compatibility so [[ "$a" >=foo ]] doesn't work anymore or is
interpreted in a different way as [[ "$a" >= foo ]] in future Bash
versions. Another solution is to switch between the single token `>='
and two separate tokens of `>' and `=' depending on the next string or
word after `=', i.e., `>=' becomes a single token only when it is
followed by at least one whitespace character and a word.
--
Koichi