On Sun, Jul 13, 2025 at 1:43 PM Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
>>
>> > And then there's POSIX. Does the Austin Group let the peanut gallery
>> > into their discussions?
>>
>> They do (https://www.opengroup.org/austin/), but given how portable
>> this currently is...
>>
>>         % cat /tmp/foo.sh
>>         op='||'
>>         echo $((1 $op 0))
>
> [bash, dash, ksh, mksh, oksh, yash, zsh all saying "1"]
>
> To be clear, I would not change the behaviour when in POSIX mode, and
> probably not even in normal bash mode, unless explicitly opted into (using
> shopt -s something or similar, or maybe if bash itself is invoked as 'bash6')

Chet has mentioned wanting to bring bash's default behavior more into
line with POSIX in the future, which I support.

>> ...achieving consensus to disallow it would be difficult, unless multiple 
>> shell developers could be convinced to break backward compatibility.
>
>> Making it unspecified would be another possibility, but AFAIK no 
>> implementations justify this change either.
>
> "Herding cats" comes to mind...

Seeing how the printf %b discussion went was interesting. The Austin
Group can't really dictate things to the implementers. They need
buy-in, or there's just an irrelevant standard that no-one is
following.

>> (The ((...)) and "let" commands are not part of the standard.)
>
> Hmm, so we could change those, leave $((...)) as-is, and provide the new 
> behaviour in, say $[...]? Nah, that inconsistency would be terrible.
>
> Better to pick something new, like ${[...]} as an expansion and {[...]} as a 
> command.

The logical conclusion to this being more assortments of {, [, and (
when people decide on new math context habeviors after that.

> Or shopt -s strict_math

If it makes sense to do this at all, this is probably the way to go.
array_expand_once/assoc_expand_once is the only shopt option that
jumps out at me as a modification to parser behavior, and
*conditionally* adding arithmetic context parsing to the shell parser
might be an unreasonable amount of work. As much as having to parse
arithmetic contexts each time they're evaluated sounds really
inefficient, honestly I'm fine with that.

Reply via email to