Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15239 > unrolled thread
| Started by | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| First post | 2019-07-24 14:49 -0400 |
| Last post | 2019-07-24 14:49 -0400 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: expression evaluation problem Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-24 14:49 -0400
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-07-24 14:49 -0400 |
| Subject | Re: expression evaluation problem |
| Message-ID | <mailman.2168.1563994202.2688.bug-bash@gnu.org> |
On Wed, Jul 24, 2019 at 11:43:11AM -0700, L A Walsh wrote:
> Those aren't my variables.
> If you assign the integer attribute to a variable it isn't the same
> as when you don't.
In this case it *is*, because everything is being fed to an arithmetic
command anyway.
Simplifying the bug report as much as possible lets us avoid
confusing and unnecessary diversions.
> > The ${str:2*c:2} part is performed first, while c is still 0, and it
> > expands to "cf".
> >
> ---
> Why? It isn't even necessary when 'c' is greater than 'uxtra'
Because that's how bash works.
$((expression))
The expression is treated as if it were within double quotes, but a
double quote inside the parentheses is not treated specially. All to‐
kens in the expression undergo parameter and variable expansion, com‐
mand substitution, and quote removal. The result is treated as the
arithmetic expression to be evaluated. Arithmetic expansions may be
nested.
Back to top | Article view | gnu.bash.bug
csiph-web