Re: Associative array keys are not reusable in (( command

[Chet Ramey]

On 1/10/21 2:55 PM, Oğuz wrote:

If I don't know the key beforehand, like if I read it from a file or the 
like, this becomes a security issue. That is my concern, 
`assoc_expand_once' doesn't help in that situation.


If you're taking input that you haven't verified and putting it into an
expansion context, I recommend you reconsider.

You can also use the key-value pair assignment syntax, which doesn't
require scanning for a close brace.

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

Re: Associative array keys are not reusable in (( command

[Greg Wooledge]

On Mon, Jan 11, 2021 at 09:07:08AM -0500, Chet Ramey wrote:
> On 1/10/21 2:55 PM, Oğuz wrote:
> 
> > If I don't know the key beforehand, like if I read it from a file or the
> > like, this becomes a security issue. That is my concern,
> > `assoc_expand_once' doesn't help in that situation.
> 
> If you're taking input that you haven't verified and putting it into an
> expansion context, I recommend you reconsider.
> 
> You can also use the key-value pair assignment syntax, which doesn't
> require scanning for a close brace.

So what I'm hearing is:

It is not safe to use an associative array element inside a math
context.  This is either by design, or an unavoidable side effect of the
implementation, and it will not be fixed, and there is no sense arguing
about it.

unicorn:~$ echo "$BASH_VERSION"
5.1.0(1)-release
unicorn:~$ declare -A aa
unicorn:~$ x='y[$(date >&2)0]'
unicorn:~$ aa[$x]=1
unicorn:~$ echo "${aa[$x]}"
1
unicorn:~$ echo "$(( aa[$x] ))"
Mon Jan 11 09:25:48 EST 2021
0

The workaround is to retrieve the AA element first, then perform the
arithmetic you need to perform using only string variables or indexed
array elements, then store the result back into the AA element if desired.

unicorn:~$ (( aa[$x]++ ))
Mon Jan 11 09:29:24 EST 2021
Mon Jan 11 09:29:24 EST 2021
unicorn:~$ tmp=${aa[$x]}; ((tmp++)); aa[$x]=$tmp
unicorn:~$ declare -p aa
declare -A aa=(["y[\$(date >&2)0]"]="2" ["y[0]"]="1" )

Re: Associative array keys are not reusable in (( command

[Chet Ramey]

> So what I'm hearing is:

We hear what we choose, I suppose.

What semantics would you choose to change?

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

Re: Associative array keys are not reusable in (( command

[Léa Gris]

Declare an integer associative array instead:

echo "$BASH_VERSION"

5.0.17(1)-release

declare -Ai aa
x='y[$(date >&2)0]'
aa[$x]=1
declare -p aa

declare -Ai aa=(["y[\$(date >&2)0]"]="1" )

aa[$x]+=1
declare -p aa

declare -Ai aa=(["y[\$(date >&2)0]"]="2" )



--
Léa Gris

Re: Associative array keys are not reusable in (( command

[Léa Gris]

Le 11/01/2021 à 15:42, Léa Gris écrivait :

Declare an integer associative array instead:

echo "$BASH_VERSION"

5.0.17(1)-release

declare -Ai aa
x='y[$(date >&2)0]'
aa[$x]=1
declare -p aa

declare -Ai aa=(["y[\$(date >&2)0]"]="1" )

aa[$x]+=1
declare -p aa

declare -Ai aa=(["y[\$(date >&2)0]"]="2" )


And forgot one more safe use of arithmetic expression:

safe_arith_index=${x@Q}
declare -p safe_arith_index

declare -- safe_arith_index="'y[\$(date >&2)0]'"

(( aa[$safe_arith_index]++ ))
declare -p aa

declare -Ai aa=(["y[\$(date >&2)0]"]="3" )


--
Léa Gris

Re: Associative array keys are not reusable in (( command

[Greg Wooledge]

On Mon, Jan 11, 2021 at 03:50:40PM +0100, Léa Gris wrote:
> safe_arith_index=${x@Q}
> declare -p safe_arith_index
> > declare -- safe_arith_index="'y[\$(date >&2)0]'"
> (( aa[$safe_arith_index]++ ))
> declare -p aa
> > declare -Ai aa=(["y[\$(date >&2)0]"]="3" )

OK, that one has potential, since it can be inlined as well.

unicorn:~$ declare -A aa
unicorn:~$ x='y[$(date >&2)0]'
unicorn:~$ aa[$x]=1
unicorn:~$ (( aa[${x@Q}]++ ))
unicorn:~$ declare -p aa
declare -A aa=(["y[\$(date >&2)0]"]="2" )

Obviously you'd need printf -v tmp %q "$x" if you're running bash older
than 4.4... or just use the tmp=${aa[$x]} workaround.

Re: Associative array keys are not reusable in (( command

[Oğuz]

11 Ocak 2021 Pazartesi tarihinde Léa Gris  yazdı:
>
> safe_arith_index=${x@Q}
>

This won't work if `x' contains a newline or a tab or something that makes
bash resort to $'...' strings. See my first post.


-- 
Oğuz

Re: Associative array keys are not reusable in (( command

[Oğuz]

11 Ocak 2021 Pazartesi tarihinde Chet Ramey  yazdı:
>
> What semantics would you choose to change?
>

If you are reluctant to change semantics, how about a new parameter
transformation to quote values using `sh_single_quote'?


-- 
Oğuz

Re: Associative array keys are not reusable in (( command

[Chet Ramey]

On 1/11/21 11:33 AM, Oğuz wrote:



11 Ocak 2021 Pazartesi tarihinde Chet Ramey > yazdı:


What semantics would you choose to change?


If you are reluctant to change semantics, how about a new parameter 
transformation to quote values using `sh_single_quote'?


Why, when @Q already exists?

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

Re: Associative array keys are not reusable in (( command

[Greg Wooledge]

> > If you are reluctant to change semantics, how about a new parameter
> > transformation to quote values using `sh_single_quote'?
> 
> Why, when @Q already exists?

It's often the case that the strings generated by bash are being
fed to some other shell, where $'...' doesn't work.  Granted, you can
always do "'${myvar//$q/$q\\$q$q}'" (where q=\').

If the sh single quoting also helps you use associative array elements
inside a math context, then that would be a second reason.  But at this
point I can't even *guess* whether it's safe to use sh-single-quoted
associative array keys inside a math context.  I tried one with a
command substitution and a newline inside it, and it seemed to work, but
that doesn't mean it's *safe*.

Re: Associative array keys are not reusable in (( command

[Oğuz]

11 Ocak 2021 Pazartesi tarihinde Chet Ramey  yazdı:

> On 1/11/21 11:33 AM, Oğuz wrote:
>
>>
>>
>> 11 Ocak 2021 Pazartesi tarihinde Chet Ramey > chet.ra...@case.edu>> yazdı:
>>
>> What semantics would you choose to change?
>>
>>
>> If you are reluctant to change semantics, how about a new parameter
>> transformation to quote values using `sh_single_quote'?
>>
>
> Why, when @Q already exists?
>

Because it doesn't always work.

bash-5.1$ x=$'\n\'' y='x],b[$(uname >&2)0'
bash-5.1$ declare -A assoc=($x 23 $y 42)
bash-5.1$
bash-5.1$ (( assoc[${x@Q}]++ ))
bash: ((: assoc[$'\n\'']++ : bad array subscript (error token is
"assoc[$'\n\'']++ ")
bash-5.1$ (( assoc[${y@Q}]++ ))
bash-5.1$
bash-5.1$ shopt -s assoc_expand_once
bash-5.1$
bash-5.1$ (( assoc[${x@Q}]++ ))
bash-5.1$ (( assoc[${y@Q}]++ ))
bash: ((: assoc['x],b[$(uname >&2)0']++ : bad array subscript (error token
is "b[$(uname >&2)0']++ ")
bash-5.1$
bash-5.1$ (( assoc[$x]++ ))
bash-5.1$ (( assoc[$y]++ ))
Linux

I tried sh_single_quote like this

diff --git a/subst.c b/subst.c
index 6132316a..639b18b2 100644
--- a/subst.c
+++ b/subst.c
@@ -7786,6 +7786,9 @@ string_transform (xc, v, s)
   case 'Q':
ret = sh_quote_reusable (s, 0);
break;
+  case 'S':
+  ret = sh_single_quote (s);
+  break;
   case 'U':
ret = sh_modcase (s, 0, CASE_UPPER);
break;
@@ -7918,6 +7921,7 @@ valid_parameter_transform (xform)
 case 'E':  /* expand like $'...' */
 case 'P':  /* expand like prompt string */
 case 'Q':  /* quote reusably */
+case 'S':  /* quote reusably */
 case 'U':  /* transform to uppercase */
 case 'u':  /* tranform by capitalizing */
 case 'L':  /* transform to lowercase */

but if assoc_expand_once is enabled it doesn't work with a key that
contains a closing brace either. Damn.



-- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>


-- 
Oğuz

Re: bug-bash Digest, Vol 218, Issue 13

[Thomas Mellman]

On 1/10/21 6:00 PM, bug-bash-requ...@gnu.org wrote:

Message: 3
Date: Sun, 10 Jan 2021 16:49:50 +0100
From: Ángel 
To: bug-bash@gnu.org
Subject: Re: non-executable files in $PATH cause errors
Message-ID:
<94646752576f053515ac2ba4656fe0c895f348ce.ca...@16bits.net>
Content-Type: text/plain; charset="ISO-8859-15"

On 2021-01-10 at 08:52 +0100, n952162 wrote:

Hello,

I consider it a bug that bash (and its hash functionality) includes
non-executable files in its execution look-up and then (inevitably)
simply reports an error, because its such files aren't  executable.

Perhaps it's there to support PATH look up for arguments to the bash
command.  That would also be a bug.  Why should it be okay to execute
a
non-executable script?  Supporting users who are too lazy to chmod a
file ought to be less important than supporting users who want
fine-grain control over what's executable and what's not.

Hello

I can't reproduce what you report.

$ mkdir foo bar
$ printf '#!/bin/sh\necho Program "$0"\n' > foo/program
$ printf '#!/bin/sh\necho Program "$0"\n' > bar/program
$ PATH="$PATH:$PWD/foo:$PWD/bar"
$ chmod +x bar/program
$ program

It is executing bar/program, not foo/program which is earlier in the
path, but not executable.

Maybe you just made the earlier program not executable, and the old
path is still being remembered? You should run  hash -r  after
making executable changes that will make an already-executed command
find a different program in the path (in the example above, making
foo/program executable, or removing again its +x bit).

Best regards



I unfortunately can't reproduce it, either.  I can't remember if I
reconfigured something or was doing something special.  When I encounter
it again, I'll investigate it better.


But here's a bug for you, in readline:

- edit a line

- go to some character

- replace that character with another, using the "r" command.

- cruise further down the line to another character

- hit the "." repeat command

The replace operation will not be executed, but rather the "x" operation.

This has actually improved over the years.  A while back, repeating an
earlier operation like that would get characters tangled up.   Now, it
seems at least to be deterministic.

5.1 locale.c typos?

[Henry Bent]

locale.c: In function 'set_default_locale':
locale.c:94:3: error: 'local_shiftstates' undeclared (first use in this
function)
   local_shiftstates = 0;
   ^
locale.c:94:3: note: each undeclared identifier is reported only once for
each function it appears in
locale.c: In function 'set_default_locale_vars':
locale.c:120:7: error: 'local_shiftstates' undeclared (first use in this
function)
   local_shiftstates = 0;
   ^
locale.c: In function 'set_locale_var':
locale.c:229:7: error: 'local_shiftstates' undeclared (first use in this
function)
   local_shiftstates = 0;
   ^
locale.c: In function 'reset_locale_vars':
locale.c:394:3: error: 'local_shiftstates' undeclared (first use in this
function)
   local_shiftstates = 0;
   ^

These were supposed to be locale_shiftstates, no?

-Henry