On 7/15/25 3:21 AM, Robert Elz wrote:
Date:Mon, 14 Jul 2025 15:22:35 -0400
From:Chet Ramey
Message-ID: <90a41c5d-c407-4a36-b7b1-21a9201b4...@case.edu>
| Say you have something like
|
| if command; then
|declare -i X
|X=some-random-expressio
Date:Mon, 14 Jul 2025 15:22:35 -0400
From:Chet Ramey
Message-ID: <90a41c5d-c407-4a36-b7b1-21a9201b4...@case.edu>
| Say you have something like
|
| if command; then
| declare -i X
| X=some-random-expression
| fi
|
| How does the parser determine
On 7/14/25 1:07 PM, Zachary Santer wrote:
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,
Besides extglob?
--
``The lyf so short, the craft so long to l
On 7/12/25 6:52 PM, Zachary Santer wrote:
On Fri, Jul 11, 2025 at 3:13 PM Chet Ramey wrote:
This means that arithmetic syntax errors are detected when the expression
is evaluated, not when the (( command is parsed. This is due to its origins
as syntactic sugar for `let "expression".
The [[ co
On Sun, Jul 13, 2025 at 1:43 PM Martin D Kealey 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
>>
On 7/9/25 4:57 PM, Robert Elz wrote:
jacaranda$ echo "$BASH_VERSION"
5.3.0(1)-release
jacaranda$ unset hash
jacaranda$ declare -A hash; key=\'\]
jacaranda$ let "hash[\$key]++"; declare -p hash
declare -A hash=(["']"]="1" )
So it is still different, just different different.
`let' is a builtin
On Sat, Jul 12, 2025, at 8:51 PM, Robert Elz wrote:
> Date:Sat, 12 Jul 2025 18:52:55 -0400
> From:Zachary Santer
> Message-ID:
>
>
> | Same applies to parameter expansion syntax errors.
>
> The NetBSD shell used to do that (and POSIX even allows it), but
> it turns out
Missed a comma…
On Mon, 14 Jul 2025, 03:43 Martin D Kealey, wrote
> an expression would be parsed and then when executed [COMMA] the
> expression itself - rather than the value resulting from evaluating it -
> could be assigned to a variable.
>
>
> Since when is removal of recursive evaluation being mooted?
>
Not by me, but if we're going down the path of parsing numeric expressions
at the same time as the surrounding shell commands, it would be useful to
have some sort of lambda assignment, so an expression would be parsed and
then when
Date:Sat, 12 Jul 2025 18:52:55 -0400
From:Zachary Santer
Message-ID:
| Now I'm drifting into Martin Kealey's camp. I don't want a new syntax
| for associative array subscripts, but I would give up some backwards
| compatibility in return for having arithmetic
On Sat, Jul 12, 2025, at 6:52 PM, Zachary Santer wrote:
> let is a builtin, and its argument is always just going to be a
> string, so people could continue to form arithmetic expressions at
> runtime using that, if they are determined to do so.
((...)) is not the only arithmetic context. The "le
On Fri, Jul 11, 2025 at 3:13 PM Chet Ramey wrote:
>
> This means that arithmetic syntax errors are detected when the expression
> is evaluated, not when the (( command is parsed. This is due to its origins
> as syntactic sugar for `let "expression".
>
> The [[ conditional command, on the other han
On 7/9/25 11:36 AM, Chet Ramey wrote:
It's clear that the problem here is this internal quoting not being removed
at the appropriate time. I'm just not sure what to do about it yet.
I figured out why this wasn't happening for `[' and `]' (and, under some
circumstances, `~'), and fixed it. The
On 7/1/25 2:50 PM, Zachary Santer wrote:
On the other hand, there's no expectation that this should work:
$ op='||'
$ [[ ${var_is_unset} == 'true' ${op} ${var} == 'foo' ]]
and it doesn't, whereas
$ var_is_unset=1
$ unset var
$ op='||'
$ (( var_is_unset ${op} var > 0 ))
does currently work, 'set
On 6/30/25 5:06 AM, Isabella Bosia wrote:
this causes a parser error since commit 35bc7025
a=(0 1 2)
b=(0 1 2)
x=0
((i=$x,a[b[i]]))
using $ anywhere in (( )) makes subscripts not expandable
I pushed a fix for this to the devel branch today.
--
``The lyf so short, the craft so long to lerne.
On Thu, 10 Jul 2025 at 01:36, Chet Ramey wrote:
> If the expression hadn't contained $x, nothing would have been expanded,
> because expanding a word without any expansion characters is a waste of
> time. This arguably causes a problem in this case; it would have been
> more consistent to run the
On Wed, Jul 9, 2025 at 11:38 AM Chet Ramey wrote:
>
> If the expression hadn't contained $x, nothing would have been expanded,
> because expanding a word without any expansion characters is a waste of
> time. This arguably causes a problem in this case; it would have been
> more consistent to run
Date:Wed, 9 Jul 2025 14:00:46 -0400
From:Greg Wooledge
Message-ID: <20250709180045.ga28...@wooledge.org>
| If that's true, then I don't understand why these two commands give
| different results:
|
| (( hash[\$key]++ ))
| let "hash[\$key]++"
|
|
On 7/9/25 2:00 PM, Greg Wooledge wrote:
On Wed, Jul 09, 2025 at 11:36:59 -0400, Chet Ramey wrote:
The arithmetic expression within (( and )) is equivalent to
let "expression"
so the contents are expanded once as if in double quotes. This has
always been the case -- earlier versions of bash jus
On Wed, Jul 09, 2025 at 11:36:59 -0400, Chet Ramey wrote:
> The arithmetic expression within (( and )) is equivalent to
>
> let "expression"
>
> so the contents are expanded once as if in double quotes. This has
> always been the case -- earlier versions of bash just translated
> ((expr)) into le
On 6/30/25 5:06 AM, Isabella Bosia wrote:
this causes a parser error since commit 35bc7025
a=(0 1 2)
b=(0 1 2)
x=0
((i=$x,a[b[i]]))
using $ anywhere in (( )) makes subscripts not expandable
Not quite true; it expands them only once. Here's what I mean.
The arithmetic expression within (( and
On 6/30/25 5:06 AM, Isabella Bosia wrote:
this causes a parser error since commit 35bc7025
a=(0 1 2)
b=(0 1 2)
x=0
((i=$x,a[b[i]]))
using $ anywhere in (( )) makes subscripts not expandable
I'll take a look at this after bash-5.3 is released.
--
``The lyf so short, the craft so long to lern
On Tue, Jul 1, 2025 at 5:36 AM Martin D Kealey wrote:
>
> On Tue, 1 Jul 2025, 08:59 Zachary Santer, wrote:
>>
>> It appears bash has made the parser more complex by selectively
>> removing the pre-expansion step for certain parts of expressions.
>> That's bad because the rules for when that happe
On Tue, 1 Jul 2025, 08:59 Zachary Santer, wrote:
> It appears bash has made the parser more complex by selectively
> removing the pre-expansion step for certain parts of expressions.
> That's bad because the rules for when that happens are undocumented
> [...]
>
By far the simplest approach for
On Mon, Jun 30, 2025 at 1:45 PM Robert Elz wrote:
>
> What's more, I don't see what the issue is, inside (( )) or $(( ))
> is what should be treated as a double quoted string (arith context
> for evaluation, but still a double quoted string - and the first thing
> the shell should be doing with an
for context, this came up when trying to do $((foo[bar[i%${#bar[@]}]]))
which has no immediate equivalent without $
On Mon, Jun 30, 2025, 19:45 Robert Elz wrote:
> Date:Mon, 30 Jun 2025 10:44:24 -0400
> From:Greg Wooledge
> Message-ID: <20250630144424.gj32...@wooled
Date:Mon, 30 Jun 2025 10:44:24 -0400
From:Greg Wooledge
Message-ID: <20250630144424.gj32...@wooledge.org>
| Unfortunately, that's not true. You need $ if you want to use any
| special parameters in an arithmetic context, such as $# or $1.
There are a zillion oth
On Mon, Jun 30, 2025 at 10:45 AM Greg Wooledge wrote:
>
> On Mon, Jun 30, 2025 at 08:33:49 -0600, Stan Marsh wrote:
> > It seems to me that there is never any need for $ in arithmetic contexts,
> > so the
> > obvious fix would be to just remove any $ found between (( and )). But
> > from what I
(I wrote):
>> It seems to me that there is never any need for $ in arithmetic contexts, so
>> the
>> obvious fix would be to just remove any $ found between (( and )). But from
>> what I
>> understand that is easier said than done.
(Causing Greg to write):
>Unfortunately, that's not true. Yo
On Mon, Jun 30, 2025 at 08:33:49 -0600, Stan Marsh wrote:
> It seems to me that there is never any need for $ in arithmetic contexts, so
> the
> obvious fix would be to just remove any $ found between (( and )). But from
> what I
> understand that is easier said than done.
Unfortunately, that's
On 6/30/25 5:06 AM, Isabella Bosia wrote:
>>this causes a parser error since commit 35bc7025
>>a=(0 1 2)
>>b=(0 1 2)
>>x=0
>>((i=$x,a[b[i]]))
>>using $ anywhere in (( )) makes subscripts not expandable
(And then Chet wrote):
>This was one of the results of this 2021 discussion:
>https://lis
On 6/30/25 5:06 AM, Isabella Bosia wrote:
this causes a parser error since commit 35bc7025
a=(0 1 2)
b=(0 1 2)
x=0
((i=$x,a[b[i]]))
using $ anywhere in (( )) makes subscripts not expandable
This was one of the results of this 2021 discussion:
https://lists.gnu.org/archive/html/bug-bash/2021-
32 matches
Mail list logo
