Re: >= and <= for string comparison

[Peng Yu]

On 1/17/23, Koichi Murase <myoga.murase@gmail.com> wrote:
> 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.

Good catch! I didn't think about that. That might one reason that <=
=> was not implemented in the first place?

-- 
Regards,
Peng