[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code Execution in Mathematical Context

From: Chet Ramey
Subject: Re: Code Execution in Mathematical Context
Date: Wed, 5 Jun 2019 14:38:45 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 6/5/19 1:39 PM, Ilkka Virta wrote:
> On 5.6. 17:05, Chet Ramey wrote:
>> On 6/4/19 3:26 PM, Ilkka Virta wrote:
>>> If the bad user supplied variable contains array indexing in itself, e.g.
>>> bad='none[$(date >&2)]' then using it in an arithmetic expansion still
>>> executes the 'date', single quotes or not (the array doesn't need to
>>> exist):
>> Because the value is treated as an expression, not an integer constant.
> And I suppose that's by design, or just required by the arithmetic
> expression syntax, right? I think that was part of the original question.

OK. Yes, that's been part of the design since I implemented it in 1990.
The goal at the time was compatibility with ksh88. ksh93 still supports
the same thing.

>>>    $ (( 'bad' ))
>>>    Tue Jun  4 22:04:32 EEST 2019
>> Quoting a string doesn't make it a non-identifier in this context.
> So is there some other "simple" way of preventing that, then?

Maybe we could expand the effect of the assoc_expand_once option to cover
this case.

>>>    $ echo "$(( 'a[2]' ))"
>>>    bash: 'a[2]' : syntax error: operand expected (error token is "'a[2]' ")
>> The expression between the parens is treated as if it were within double
>> quotes, where single quotes are not special.
> I did put the double-quotes around the $((...)), but the same happens even
> without them. Is this just a difference between ((...)) and $((...)) for
> some reason?

When you use $((...)), the expression between the parens is treated as if
it were within double quotes, as per POSIX:

"The expression shall be treated as if it were in double-quotes, except
that a double-quote inside the expression is not treated specially. The
shell shall expand all tokens in the expression for parameter expansion,
command substitution, and quote removal."

I think this is an unfortunate difference between ((...)), which is
supposed to be equivalent to `let "..."' and $((...)). I think it should
probably be a syntax error in both cases.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]