Re: Issue declaring an array via a variable name

2021-08-22 Thread Alex fxmbsw7 Ratchev
yea i dunno to say, i dont care, peace..

On Sun, Aug 22, 2021, 22:48 Lawrence Velázquez  wrote:

> On Sun, Aug 22, 2021, at 4:38 PM, Alex fxmbsw7 Ratchev wrote:
> > last time again
>
> You promise?
>
> > one pair quotes, not more
>
> Except you're wrong.
>
> $ val=foo
> $ declare "$val"='x'
> $ declare -p "$val"
> declare -- foo="x"
>
> $ val=bar
> $ declare -a "$val"='(baz quux)'
> $ declare -p "$val"
> declare -a bar=([0]="baz" [1]="quux")
>
>
> --
> vq
>


Re: Issue declaring an array via a variable name

2021-08-22 Thread Lawrence Velázquez
On Sun, Aug 22, 2021, at 4:38 PM, Alex fxmbsw7 Ratchev wrote:
> last time again

You promise?

> one pair quotes, not more

Except you're wrong.

$ val=foo
$ declare "$val"='x'
$ declare -p "$val"
declare -- foo="x"

$ val=bar
$ declare -a "$val"='(baz quux)'
$ declare -p "$val"
declare -a bar=([0]="baz" [1]="quux")


-- 
vq



Re: Issue declaring an array via a variable name

2021-08-22 Thread Alex fxmbsw7 Ratchev
as i said how to make it work, last time again, one pair quotes, not more

On Sun, Aug 22, 2021, 22:37 Chet Ramey  wrote:

> On 8/21/21 6:02 PM, Hunter Wittenborn wrote:
> >> As an end user I would expect the unquoted `('
> >
> >> operator to cause a syntax error, just as it does in `echo ('.
> >
> >
> >
> > Well I'm expecting '(' to be part of the shell's syntax (when unquoted;
> so likewise not cause a syntax error), but when looking at things like the
> left side of a variable assignment, I'm sure you'll agree that it should
> allow any string that fits a variable's normal specification (regardless of
> being an array or not).
>
> Maybe this is best seen as a misunderstanding about order of operations.
>
> Before the `declare' builtin is executed, the command has to be parsed.
> The parser identifies the token `declare' as the first word of a simple
> command, and further identifies `declare' as a declaration command, as
> explained in the documentation.
>
> One thing about the shell's metacharacters (of which `(' is one) is that
> they have to be quoted when they appear somewhere outside where the shell's
> grammar permits. One place bash allows `(' -- an extension to the POSIX
> grammar -- is on the rhs of an assignment statement.
>
> Given a declaration command, the shell parser allows assignment statements
> as arguments. An assignment statement, as documented, takes the form
>
> identifier=value
>
> where `identifier' is a `name' (as defined in the bash documentation) or an
> array subscript of the form `name[index]'.
>
> The key to understanding this is that all of this must happen before any of
> the shell's word expansions, including quote removal, take place.
>
> If the shell parser can't recognize a word, or at least the word that's
> been accumulated when it sees the `(' operator, as a valid assignment
> statement, the exception to having to quote the left paren doesn't come
> into play.
>
> We can disregard arguments that contain `=' that may be treated as
> assignments when `declare' sees them as long as they don't contain any
> shell metacharacters:
>
> >
> > `declare "${value}"="x"`
> >
> > `declare "y"="x"`
>
> However, if you want the parser to allow an unquoted metacharacter, you
> have to follow the rules that allow it to happen, and this does not:
>
> > `declare "${value}"=("x" "z")`
>
> Because "${value}" is not a valid shell `name' and cannot appear on the
> lhs of an assignment statement.
>
> Given that, it should be obvious why the above is a syntax error.
>
> --
> ``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: Issue declaring an array via a variable name

2021-08-22 Thread Chet Ramey

On 8/21/21 6:02 PM, Hunter Wittenborn wrote:

As an end user I would expect the unquoted `('



operator to cause a syntax error, just as it does in `echo ('.




Well I'm expecting '(' to be part of the shell's syntax (when unquoted; so 
likewise not cause a syntax error), but when looking at things like the left 
side of a variable assignment, I'm sure you'll agree that it should allow any 
string that fits a variable's normal specification (regardless of being an 
array or not).


Maybe this is best seen as a misunderstanding about order of operations.

Before the `declare' builtin is executed, the command has to be parsed.
The parser identifies the token `declare' as the first word of a simple
command, and further identifies `declare' as a declaration command, as
explained in the documentation.

One thing about the shell's metacharacters (of which `(' is one) is that
they have to be quoted when they appear somewhere outside where the shell's
grammar permits. One place bash allows `(' -- an extension to the POSIX
grammar -- is on the rhs of an assignment statement.

Given a declaration command, the shell parser allows assignment statements
as arguments. An assignment statement, as documented, takes the form

identifier=value

where `identifier' is a `name' (as defined in the bash documentation) or an
array subscript of the form `name[index]'.

The key to understanding this is that all of this must happen before any of
the shell's word expansions, including quote removal, take place.

If the shell parser can't recognize a word, or at least the word that's
been accumulated when it sees the `(' operator, as a valid assignment
statement, the exception to having to quote the left paren doesn't come
into play.

We can disregard arguments that contain `=' that may be treated as 
assignments when `declare' sees them as long as they don't contain any

shell metacharacters:



`declare "${value}"="x"`

`declare "y"="x"`


However, if you want the parser to allow an unquoted metacharacter, you
have to follow the rules that allow it to happen, and this does not:


`declare "${value}"=("x" "z")`


Because "${value}" is not a valid shell `name' and cannot appear on the
lhs of an assignment statement.

Given that, it should be obvious why the above is a syntax error.

--
``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: Issue declaring an array via a variable name

2021-08-22 Thread Oğuz
22 Ağustos 2021 Pazar tarihinde Hunter Wittenborn <
hun...@hunterwittenborn.com> yazdı:
>
> Well I'm expecting '(' to be part of the shell's syntax (when unquoted; so
> likewise not cause a syntax error), but when looking at things like the
> left side of a variable assignment, I'm sure you'll agree that it should
> allow any string that fits a variable's normal specification (regardless of
> being an array or not).
>

Okay, yeah, but neither `"var"', `"${variable}"', nor `${variable}' is a
'string that fits a variable's normal specification'.


-- 
Oğuz


Re: Issue declaring an array via a variable name

2021-08-21 Thread Lawrence Velázquez
On Sat, Aug 21, 2021, at 6:02 PM, Hunter Wittenborn wrote:
> In my head, something like this (where 'value' is equal to 'y'):
> 
> `declare "${value}"="x"`
> 
> becomes this (which it appears to do so):
> 
> `declare "y"="x"`

Almost.  The argument parses without issue ('=' has no special
meaning here), so it undergoes the usual parameter expansion and
quote removal, and you end up with

declare y=x

which is fine.

> Logically (for me anyway), this:
> 
> `declare "${value}"=("x" "z")`
> 
> should then become this:
> 
> `declare "y"=("x" "z")`

The shell performs parameter expansion and quote removal on a command
*after* parsing it.  As I see it, your mental model for `declare`
requires the shell to:

   1. Pause parsing upon seeing '('.
   2. Go back and, out of the usual order, perform parameter expansion
  and quote removal on the portion of the word preceding '=' to
  see whether it expands to a valid identifier.
  3a. If it does, resume parsing the word as an assignment, so '('
  begins an array.
  3b. If not, resume parsing as regular word, so '(' is a syntax error.

These would be rules that don't apply anywhere else.  You may find
this logical and worthwhile, but others sure don't.

"${value}"=("x" "z")  # invalid
echo "${value}"=("x" "z") # invalid
declare "${value}"=("x" "z")  # invalid but you want it to be valid

As has already been pointed out, this all goes away if you just
quote the parentheses -- even if you're silly about it:

declare -a "${value}"=\(x\ z\)

-- 
vq



Re: Issue declaring an array via a variable name

2021-08-21 Thread Alex fxmbsw7 Ratchev
i wrote, i write again
declare "var=value"
not
declare "var"="value"

On Sun, Aug 22, 2021, 00:02 Hunter Wittenborn 
wrote:

> > As an end user I would expect the unquoted `('
>
> > operator to cause a syntax error, just as it does in `echo ('.
>
>
>
> Well I'm expecting '(' to be part of the shell's syntax (when unquoted; so
> likewise not cause a syntax error), but when looking at things like the
> left side of a variable assignment, I'm sure you'll agree that it should
> allow any string that fits a variable's normal specification (regardless of
> being an array or not).
>
>
>
> Maybe this will explain how I'm thinking about it:
>
>
>
> In my head, something like this (where 'value' is equal to 'y'):
>
>
>
> `declare "${value}"="x"`
>
>
>
> becomes this (which it appears to do so):
>
>
>
> `declare "y"="x"`
>
>
>
> Logically (for me anyway), this:
>
>
>
> `declare "${value}"=("x" "z")`
>
>
>
> should then become this:
>
>
>
> `declare "y"=("x" "z")`
>


Re: Issue declaring an array via a variable name

2021-08-21 Thread Hunter Wittenborn
> As an end user I would expect the unquoted `('

> operator to cause a syntax error, just as it does in `echo ('.



Well I'm expecting '(' to be part of the shell's syntax (when unquoted; so 
likewise not cause a syntax error), but when looking at things like the left 
side of a variable assignment, I'm sure you'll agree that it should allow any 
string that fits a variable's normal specification (regardless of being an 
array or not).



Maybe this will explain how I'm thinking about it:



In my head, something like this (where 'value' is equal to 'y'):



`declare "${value}"="x"`



becomes this (which it appears to do so):



`declare "y"="x"`



Logically (for me anyway), this:



`declare "${value}"=("x" "z")`



should then become this:



`declare "y"=("x" "z")`


Re: Issue declaring an array via a variable name

2021-08-19 Thread Oğuz
20 Ağustos 2021 Cuma tarihinde Hunter Wittenborn <
hun...@hunterwittenborn.com> yazdı:
>
> So, in my opinion, this should logically work (from the view of an end
> user):
>
>
>
> declare "var"=("i" "j")
>

`"var"=("i" "j")' doesn't qualify as an assignment statement as the
variable name is quoted. As an end user I would expect the unquoted `('
operator to cause a syntax error, just as it does in `echo ('.


-- 
Oğuz


Re: Issue declaring an array via a variable name

2021-08-19 Thread Hunter Wittenborn
The
 general consensus seems to be that this isn't really a bug (from what 
I've understood), but it looks like I can use a variable reference to 
solve the issue nevertheless.



Regardless, 
I'm still wanting to almost classify this as a bug (or possibly a 
feature request; it feels like it's getting blurry where it would be at 
this point).







Because; Both of these work:



declare "var"="i"

declare var=("i" "j")



So, in my opinion, this should logically work (from the view of an end user):



declare "var"=("i" "j")





The same issue applies for variables, though seeming to not matter if they're 
in quotes or not for those.



Lastly
 - again, the variable reference issue is seeming to work fairly fine 
for my current use cases. I just don't really want to throw this off as a
 "syntax error" when this quite arguably seems like a bug instead.





 On Mon, 16 Aug 2021 09:27:55 -0500 Greg Wooledge  wrote 



On Mon, Aug 16, 2021 at 04:10:31PM +0200, Alex fxmbsw7 Ratchev wrote: 
> i dunno but, i had many testings many times 
> the stable wanted is to enclose the per arg definition in quotes, not like 
> "var"="var" 
> the right dash options is also useful 
 
I don't understand this paragraph at all. 
 
> test=( a b ) t=var 
> declare -ga "$t=( ${test@Q} )" 
 
I believe this is what you're trying to show us: 
 
unicorn:~$ declare -ga "${t}=( ${test@Q} )" 
unicorn:~$ declare -ga "${t}"=( ${test@Q} ) 
bash: syntax error near unexpected token `(' 
 
And likewise, 
 
unicorn:~$ declare -ga "$t=( ${test@Q} )" 
unicorn:~$ declare -ga "$t"=( ${test@Q} ) 
bash: syntax error near unexpected token `(' 
 
There is something subtle happening there, at the parsing level.  Chet's 
explanation (quoted below) may suffice for some. 
 
For my own purposes, "if it hurts, don't do that" is good enough. 
But that's just me. 
 
> the same style i found secure and data preserving such alike: 
> "list=( $( ls -Ac --quoting-style=shell-escape ) )" 
 
That has nothing to do with the issue that started this thread.  You've 
got a plain old compound array assignment, with a command substitution 
inside it.  The variable on the left hand side ("list") is a valid 
shell identifier.  There are no surprises here. 
 
> On Mon, Aug 16, 2021, 15:57 Chet Ramey  wrote: 
> > It's a syntax error. There is an unquoted operator (`(') where the grammar 
> > does not allow it. 
> > 
> > `declare' does allow compound array assignment statements as arguments, and 
> > the parser accommodates this as long as two conditions hold: the parser can 
> > detect that the first word of a simple command is `declare' and the 
> > argument is a valid assignment statement. In this case, the second fails, 
> > since `"${variable}"' is not a valid shell identifier. That renders the 
> > argument not a valid assignment statement. 
 





---

Hunter Wittenborn

https://www.hunterwittenborn.com

https://github.com/hwittenborn


Re: Issue declaring an array via a variable name

2021-08-16 Thread Chet Ramey
On 8/14/21 8:45 PM, Hunter Wittenborn wrote:
> Hi,
> 
> 
> 
> I was doing some testing for some additions to a rather big Bash script I'm 
> working on, and the following code kept failing whenever I attempted to run 
> it:
> 
> 
> 
> "
> 
> variable="hello"
> 
> 
> 
> declare -g "${variable}"=("world" "me")

Here's the answer I gave on help-bash:

It's a syntax error. There is an unquoted operator (`(') where the grammar
does not allow it.

`declare' does allow compound array assignment statements as arguments, and
the parser accommodates this as long as two conditions hold: the parser can
detect that the first word of a simple command is `declare' and the
argument is a valid assignment statement. In this case, the second fails,
since `"${variable}"' is not a valid shell identifier. That renders the
argument not a valid assignment statement.

-- 
``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: Issue declaring an array via a variable name

2021-08-15 Thread Léa Gris

Le 15/08/2021 à 02:45, Hunter Wittenborn écrivait :

- declare -g "${variable}"=("world" "me")
- declare -g ${variable}=("world" "me")
- declare -g "hello"=("world" "me")


Invalid because the string "${variable}" cannot be assigned = the scalar 
("world" "me")


If you want to dynamically compose the declare arguments, it either need 
to be only a string or only variable=value(s)


So these work because the argument is a string

declare -g "$variable=( \"world\" \"me\" )"
declare -g "$variable"'=( "world" "me" )'

Be cautious with dynamic declare statements, because it is as insecure 
as eval. It will execute statements contained in variables.


--
Léa Gris




Issue declaring an array via a variable name

2021-08-14 Thread Hunter Wittenborn
Hi,



I was doing some testing for some additions to a rather big Bash script I'm 
working on, and the following code kept failing whenever I attempted to run it:



"

variable="hello"



declare -g "${variable}"=("world" "me")

"



When run, it's complaining about a syntax error near "(", appearing to be on 
the 'declare' line right next to where I start typing the array.



In my testing, all of the following would fail:



- declare -g "${variable}"=("world" "me")

- declare -g ${variable}=("world" "me")

- declare -g "hello"=("world" "me")



The only one that did work was the following:



- declare -g hello=("world" "me")



This appeared to be a bug for me, but I wasn't sure if this was somehow a 
feature or not.



Lastly: A workaround for this was found here [1] which uses namerefs, and works 
just fine (and is probably easier for me to look at anyway), but this seemed 
like something that deemed a bug report regardless.



[1]: https://lists.gnu.org/archive/html/help-bash/2021-08/msg00069.html

---

Hunter Wittenborn

https://www.hunterwittenborn.com

https://github.com/hwittenborn