Re: declare a="$b" if $a previously set as array

On 12/16/14 4:49 PM, Stephane Chazelas wrote: > I believe my proposal in Message-ID: > <20141214204845.ga5...@chaz.gmail.com> > http://thread.gmane.org/gmane.comp.shells.bash.bugs/22737/focus=22789 > > would be the most consistent syntax. But that breaks > compatibility especially as it means the

Re: declare a="$b" if $a previously set as array

On 12/16/14 2:53 AM, Dan Douglas wrote: > On Sunday, December 14, 2014 02:39:29 PM Chet Ramey wrote: >> And we get to the fundamental issue. Is it appropriate to require >> arguments to declaration commands to be valid assignment statements when >> the parser sees them, instead of when the builtin

Re: declare a="$b" if $a previously set as array

On 12/16/14 7:30 AM, Stephane Chazelas wrote: >> * This solves the problem without breaking backwards compatibility and >> allows >>declare -p output to continue to function. > [...] > > Well, if "declare -p" continues to function which is not what I > understand your proposal to do, then:

Re: declare a="$b" if $a previously set as array

On 12/17/14 3:58 AM, konsolebox wrote: > On Mon, Dec 15, 2014 at 4:34 AM, Chet Ramey wrote: >> It does implement `emulated behavior of normal assignments'. The question >> is whether or not it should do that after having had its arguments undergo >> one round of word expansion. > > After studyin

Re: declare a="$b" if $a previously set as array

On Mon, Dec 15, 2014 at 4:34 AM, Chet Ramey wrote: > It does implement `emulated behavior of normal assignments'. The question > is whether or not it should do that after having had its arguments undergo > one round of word expansion. After studying the code I realized that that's actually the o

Re: declare a="$b" if $a previously set as array

On Mon, Dec 15, 2014 at 1:48 PM, konsolebox wrote: > Last thing is `declare -x "$a_complete_assignment"` should not be allowed; > even quoted assignments like `declare -x "$one=$two"` simply because > they are already a reinterpreted form i.e. they are already evaluated > with a pair of single or

Re: declare a="$b" if $a previously set as array

2014-12-16 21:49:58 +, Stephane Chazelas: [...] > 1.1 litteral array assignment. [...] > 1.2 litteral scalar assignment [...] > 2. words that don't form valid assignments. > > Those are parsed as normal command line arguments. > > declare \a=(...) > > would get a syntax error because of the

Re: declare a="$b" if $a previously set as array

2014-12-15 22:00:54 -0500, Chet Ramey: > On 12/14/14 4:44 PM, Stephane Chazelas wrote: > > > There's still a (security) issue with > > > > declare -x/-l/-r > > that may still be used in non-function contexts (not "export" or > > "readonly"), and as result for things like: > > > > saved=$(export

Re: declare a="$b" if $a previously set as array

On 12/15/14, 9:41 PM, Linda Walsh wrote: > Though I just ran into a bit of weirdness (in 4.2.45) > (output is commented out and indented): > > env -i /bin/bash --norc --noprofile > declare -a ar=(ONE TWO THREE) > declare -p ar > # declare -a ar='([0]="ONE" [1]="TWO" [2]="THREE")' > >

Re: declare a="$b" if $a previously set as array

On 12/16/14, 2:53 AM, Dan Douglas wrote: > On Sunday, December 14, 2014 02:39:29 PM Chet Ramey wrote: >> And we get to the fundamental issue. Is it appropriate to require >> arguments to declaration commands to be valid assignment statements when >> the parser sees them, instead of when the builti

Re: declare a="$b" if $a previously set as array

2014-12-16 12:30:52 +, Stephane Chazelas: > 2014-12-16 01:53:52 -0600, Dan Douglas: > [...] > > That would be one way but I think this can be solved without going quite > > so far. How do you feel about these rules? > > > > 1. If a word that is an argument to declare is parsed as a valid >

Re: declare a="$b" if $a previously set as array

2014-12-16 01:53:52 -0600, Dan Douglas: [...] > That would be one way but I think this can be solved without going quite > so far. How do you feel about these rules? > > 1. If a word that is an argument to declare is parsed as a valid > assignment, then perform the assignment immedi

Re: declare a="$b" if $a previously set as array

On Sunday, December 14, 2014 02:39:29 PM Chet Ramey wrote: > And we get to the fundamental issue. Is it appropriate to require > arguments to declaration commands to be valid assignment statements when > the parser sees them, instead of when the builtin sees them, at least > when using the compoun

Re: declare a="$b" if $a previously set as array

On Sunday, December 14, 2014 09:44:16 PM Stephane Chazelas wrote: > but: > > x='($(uname>&2))' bash -c 'f() { a[0]=x; declare a=$x; }; f' > > is not, because when in a function, declare ignores variables by > the same name that have not been declared in that same scope > (even if they have been *

Re: declare a="$b" if $a previously set as array

On 12/14/14 4:44 PM, Stephane Chazelas wrote: > There's still a (security) issue with > > declare -x/-l/-r > that may still be used in non-function contexts (not "export" or > "readonly"), and as result for things like: > > saved=$(export -p var) > ... > eval "$saved" > > And with declare -g in

Re: declare a="$b" if $a previously set as array

Chet Ramey wrote: On 12/8/14 4:56 AM, Stephane Chazelas wrote: I'm saying that if a script writer writes: declare a="$b" I don't think it's unreasonable for a script writer to expect that this does not unset a; it's not documented to do that, and assignment without the `declare' doesn'

Re: declare a="$b" if $a previously set as array

On 12/15/14 6:41 AM, Dan Douglas wrote: > To me the biggest problem is what happens when you explicitly request a scalar > assignment. (I even specified a[1] to ensure it's not an "a vs. a[0]" issue.) > > bash -c 'typeset -a a; b="(foo bar)"; typeset a[1]=$b; typeset -p a; > printf "<%s> "

Re: declare a="$b" if $a previously set as array

On Wednesday, December 10, 2014 10:43:45 AM Stephane Chazelas wrote: > David Korn mentions that local scoping a la ksh was originally rejected by > POSIX because ksh88 originally implemented "dynamic scoping" (like most > shells now do, but most other languages don't). ksh changed to lexical > scop

Re: declare a="$b" if $a previously set as array

2014-12-15 05:41:51 -0600, Dan Douglas: > So I'm still getting caught up on this thread, but hasn't this issue been done > to death in previous threads? Back when I was examining bash's strange declare > -a, you were the very first person I found to notice its quasi-keyword > behavior > 10 years a

Re: declare a="$b" if $a previously set as array

Sorry I did a bad job copy/pasting then editing that last example. ksh -c 'typeset -a x=(foo); print "${@x}"; typeset -T A=(typeset y); A x=(y=foo); print "${@x}"; x+=(y=bar); print "${@x}"; typeset -p x' typeset -a A A A -a x=((y=foo) (y=bar)) -- Dan Dou

Re: declare a="$b" if $a previously set as array

So I'm still getting caught up on this thread, but hasn't this issue been done to death in previous threads? Back when I was examining bash's strange declare -a, you were the very first person I found to notice its quasi-keyword behavior 10 years ago (https://lists.gnu.org/archive/html/bug-bash/200

Re: declare a="$b" if $a previously set as array

On Mon, Dec 15, 2014 at 5:05 AM, Chet Ramey wrote: > On 12/9/14 5:51 PM, konsolebox wrote: >> On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh wrote: >> >>> Instead of dumbing down bash, why not lobby for bash to record >>> which variables contain tainted input -- and throw an error they are e

Re: declare a="$b" if $a previously set as array

On Mon, Dec 15, 2014 at 5:12 AM, Chet Ramey wrote: > On 12/10/14 8:27 AM, konsolebox wrote: > >>> Note that that's the Bourne shell, not a POSIX sh. >> >> I was actually wanting to say that heirloom-sh is still a modernized >> shell (in code) despite being a strict clone of the original sh. > > It

Re: declare a="$b" if $a previously set as array

On 12/14/2014 08:45 PM, Chet Ramey wrote: On 12/7/14 11:16 PM, Eduardo A. Bustamante López wrote: On Sun, Dec 07, 2014 at 07:34:53PM -0800, Linda Walsh wrote: Only if you properly quote "external input". Well, that's the whole point, as a script writer, I don't expect to get arbitrary code exe

Re: declare a="$b" if $a previously set as array

2014-12-14 20:48:45 +, Stephane Chazelas: [...] > $ bash -c 'declare a[1]="(1 2 3)"; declare -p a' > declare -a a='([0]="1" [1]="2" [2]="3")' > > $ bash -c 'declare a+=([1]="1 2 3"); declare -p a' > bash: line 0: declare: `a+': not a valid identifier > declare -a a='([1]="1 2 3")' > > How do

Re: declare a="$b" if $a previously set as array

On 12/14/14 4:19 PM, Stephane Chazelas wrote: > Yes I don't know what Mint (Ubuntu?) did, but it's a bit broken > see also: > > $ bash -c 'f() { declare a[1]=foo; declare -p a; }; a[0]=x; f; declare -p a' > bash: line 0: declare: a: not found > declare -a a='([0]="x")' > > (sorry about the conf

Re: declare a="$b" if $a previously set as array

2014-12-14 14:39:29 -0500, Chet Ramey: [...] > > ~$ bash --version > > GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) > > Copyright (C) 2013 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > > > > > This is free softwar

Re: declare a="$b" if $a previously set as array

On 12/10/14 8:27 AM, konsolebox wrote: >> Note that that's the Bourne shell, not a POSIX sh. > > I was actually wanting to say that heirloom-sh is still a modernized > shell (in code) despite being a strict clone of the original sh. It's not a `strict' clone'. It is a modified version of the SV

Re: declare a="$b" if $a previously set as array

On 12/10/14 5:43 AM, Stephane Chazelas wrote: > It's ironic that local scoping is now implemented in virtually > all POSIX shells but not specified by POSIX. It almost was, once. It's one of my great regrets that I got rid of my paper copy of Posix 1003.2 draft 9, which specified `local'. -- `

Re: declare a="$b" if $a previously set as array

On 12/9/14 5:51 PM, konsolebox wrote: > On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh wrote: > >> Instead of dumbing down bash, why not lobby for bash to record >> which variables contain tainted input -- and throw an error they are eval'ed >> (based on an option setting, of course)? > > F

Re: declare a="$b" if $a previously set as array

2014-12-14 14:57:15 -0500, Chet Ramey: [...] > Well, I don't think it's particularly a syntax issue. It's the question > I wrote in my previous message: how much further should we move compound > assignment away from the execution semantics associated with builtins. [...] IMO, the ksh behaviour i

Re: declare a="$b" if $a previously set as array

On 12/9/14 7:55 AM, konsolebox wrote: > Other shells certainly does not support local > scopes. Pretty much every other shell except the straight descendants of the System V Bourne shell supports local scopes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars

Re: declare a="$b" if $a previously set as array

On 12/9/14 5:59 AM, Stephane Chazelas wrote: > BTW, it's worth noting (and maybe documenting) that word > splitting and filename generation are performed in: > > declare -g $var=$something > (or declare ''var=$something or declare f\oo=$bar...) > > So it must be indeed: > > declare -g "$var=$so

Re: declare a="$b" if $a previously set as array

On 12/8/14 9:51 PM, konsolebox wrote: > On Sun, Dec 7, 2014 at 7:24 AM, Stephane Chazelas > wrote: >> $ b='($(uname>&2))' bash -c 'a=(); declare -r a=$b' >> Linux > > I actually also don't like that form of implementation. Even if declare > is a builtin and not a reserved word, it still has some

Re: declare a="$b" if $a previously set as array

On 12/8/14 6:29 PM, Linda Walsh wrote: >> Also, it's *not* the way it's supposed to operate. Arrays are not POSIX, how >> can this be the way it's "supposed" to operate? Where do you get that from? > > Of the shells you mention, which implemented arrays first? ksh did. It certainly had

Re: declare a="$b" if $a previously set as array

On 12/8/14 4:31 PM, Eduardo A. Bustamante López wrote: > If you want delayed evaluation, use 'eval', that's what it's for. Your use > case > is a lame excuse for a "feature" that's clearly more evil than useful. I stopped reading right here. In the end, this is a minor argument about a relative

Re: declare a="$b" if $a previously set as array

On 12/8/14 3:48 PM, Linda Walsh wrote: >> intending to declare the *scalar* varible "$a" as a copy of the >> scalar variable "$b" > > How does the script writer **KNOW** $a and $b are scalar? I agree that the script writer needs to pay attention to the types and values of variables he i

Re: declare a="$b" if $a previously set as array

On 12/8/14 4:56 AM, Stephane Chazelas wrote: > I'm saying that if a script writer writes: > > declare a="$b" > > intending to declare the *scalar* varible "$a" as a copy of the > scalar variable "$b" (and remember that in ksh/bash, scalar > variables and arrays are not very differentiated, $

Re: declare a="$b" if $a previously set as array

On 12/7/14 11:16 PM, Eduardo A. Bustamante López wrote: > On Sun, Dec 07, 2014 at 07:34:53PM -0800, Linda Walsh wrote: >> Only if you properly quote "external input". > Well, that's the whole point, as a script writer, I don't expect to get > arbitrary code execution here: > > | dualbus@hp:~/t$ un

Re: declare a="$b" if $a previously set as array

On 12/7/14 5:36 AM, Stephane Chazelas wrote: > In this case, it's not about sanitizing external input, at least > as far as the $external_input variable is concerned. In a way, it is. It's understanding the context in which external input is going to be used. However, I think that you're right,

Re: declare a="$b" if $a previously set as array

On Wed, Dec 10, 2014 at 6:43 PM, Stephane Chazelas wrote: > 2014-12-10 06:33:00 +0800, konsolebox: > [...] >> > Not sure what you mean by that last sentence, but all of dash, >> > yash, mksh, pdksh, AT&T ksh, posh, zsh (so virtually all modern >> > Bourne-like shells) do support local scopes each

Re: declare a="$b" if $a previously set as array

2014-12-10 10:43:45 +, Stephane Chazelas: [...] > In particular, it mandates a "local" builtin. So sh scripts that > use "local" are guaranteed to work in Debian. However note that > behaviour for "local foo=bar" is unspecified there, so sh > scripts for Debian should use "local foo; foo=bar" (

Re: declare a="$b" if $a previously set as array

2014-12-10 06:33:00 +0800, konsolebox: [...] > > Not sure what you mean by that last sentence, but all of dash, > > yash, mksh, pdksh, AT&T ksh, posh, zsh (so virtually all modern > > Bourne-like shells) do support local scopes each with variations > > of behaviour and syntax. > > I know ksh, pdks

Re: declare a="$b" if $a previously set as array

On Tue, Dec 9, 2014 at 7:29 AM, Linda Walsh wrote: > Instead of dumbing down bash, why not lobby for bash to record > which variables contain tainted input -- and throw an error they are eval'ed > (based on an option setting, of course)? For compatibility's sake I think it's a good idea

Re: declare a="$b" if $a previously set as array

On Tue, Dec 9, 2014 at 9:40 PM, Stephane Chazelas wrote: > 2014-12-09 20:55:02 +0800, konsolebox: > [...] >> As for the other things, I was actually only concerned about the >> dangerous behavior that's synonymous to "eval $b" so I didn't really >> thought about discussing them. And I'm only refe

Re: declare a="$b" if $a previously set as array

2014-12-09 20:55:02 +0800, konsolebox: [...] > As for the other things, I was actually only concerned about the > dangerous behavior that's synonymous to "eval $b" so I didn't really > thought about discussing them. And I'm only referring to Bash when I > made the suggestions. Other shells certai

Re: declare a="$b" if $a previously set as array

On Tue, Dec 09, 2014 at 08:55:02PM +0800, konsolebox wrote: > > declare -g "$var=$something" > > It actually should be completely avoided. eval is the right tool for > that job (besides a variable declared with -n in 4.3+). Unfortunately, "declare -n" is the same as eval. We've had this discuss

Re: declare a="$b" if $a previously set as array

On Tue, Dec 9, 2014 at 6:59 PM, Stephane Chazelas wrote: > BTW, it's worth noting (and maybe documenting) that word > splitting and filename generation are performed in: > > declare -g $var=$something > (or declare ''var=$something or declare f\oo=$bar...) > > So it must be indeed: > > declare -g

Re: declare a="$b" if $a previously set as array

2014-12-09 10:59:14 +, Stephane Chazelas: [...] > $ a=0 ksh -c 'function f { typeset a=1; g; h; echo "f: $a"; }; function g { > a=2; }; function h { typeset a=3; };f' > f: 1 > > "f" doesn't have to worry about alien functions changing its > local variables under its feet. [...] (for clarific

Re: declare a="$b" if $a previously set as array

Thanks konsolebox and Eduardo, glad to see I'm not the only one seeing an issue in that. A few additions inline: 2014-12-09 10:51:51 +0800, konsolebox: [...] > (But I think those who used to recommend using declare as a general tool > for assigning values remotely over evil eval would love it sin

Re: declare a="$b" if $a previously set as array

On Sun, Dec 7, 2014 at 7:24 AM, Stephane Chazelas wrote: > $ b='($(uname>&2))' bash -c 'a=(); declare -r a=$b' > Linux I actually also don't like that form of implementation. Even if declare is a builtin and not a reserved word, it still has some special treatments that's different from a simple

Re: declare a="$b" if $a previously set as array

Eduardo A. Bustamante López wrote: On Mon, Dec 08, 2014 at 12:48:05PM -0800, Linda Walsh wrote: --- This usage ***depends*** on delayed evaluation -- which you claim is "code injection". This is the way shell is supposed to operate. The programmer ***HAS*** to choose when to cause the expre

Re: declare a="$b" if $a previously set as array

On Mon, Dec 08, 2014 at 12:48:05PM -0800, Linda Walsh wrote: > --- This usage ***depends*** on delayed evaluation -- which you > claim is "code injection". This is the way shell is supposed to > operate. The programmer ***HAS*** to choose when to cause the expression > to be evaluated depending

Re: declare a="$b" if $a previously set as array

2014-12-08 12:48:05 -0800, Linda Walsh: [...] > declare -x fmt='($(echo uid:$UID) $(echo euid:$EUID) $(date) $(uname -n))' > declare -a out > declare -l out=$fmt > echo "out=${out[@]}" > sudo bash --norc -c 'declare -a out;declare -l out=$fmt; echo > "out=${out[@]}"' > > > > Run that and you

Re: declare a="$b" if $a previously set as array

Stephane Chazelas wrote: 2014-12-07 19:34:53 -0800, Linda Walsh: [...] Stephane Chazelas wrote: declare -l a="$external_input" he's entitled to expect $a to contain the lower case version of $external_input whatever $external_input contain. --- Only if you properly quote "external input".

Re: declare a="$b" if $a previously set as array

2014-12-07 19:34:53 -0800, Linda Walsh: [...] > Stephane Chazelas wrote: > > declare -l a="$external_input" > > > >he's entitled to expect $a to contain the lower case version of > >$external_input whatever $external_input contain. > --- > Only if you properly quote "external input". > > If you

Re: declare a="$b" if $a previously set as array

On Sun, Dec 07, 2014 at 07:34:53PM -0800, Linda Walsh wrote: > Only if you properly quote "external input". Well, that's the whole point, as a script writer, I don't expect to get arbitrary code execution here: | dualbus@hp:~/t$ unset var; value='[$(ls -l)]=1 [2]=2'; declare -a var="($value)"; de

Re: declare a="$b" if $a previously set as array

Stephane Chazelas wrote: declare -l a="$external_input" he's entitled to expect $a to contain the lower case version of $external_input whatever $external_input contain. --- Only if you properly quote "external input". If you properly quote the external input I don't see the problem: Doe

Re: declare a="$b" if $a previously set as array

2014-12-06 20:19:21 -0500, Chet Ramey: > On 12/6/14 6:24 PM, Stephane Chazelas wrote: > > Hiya, > > > > this is potentially dangerous: > > > > If $a was previously used as an array (or hash), then: > > > > declare a=$external_input > > So what you're saying is that blindly using external input

Re: declare a="$b" if $a previously set as array

On 12/6/14 6:24 PM, Stephane Chazelas wrote: > Hiya, > > this is potentially dangerous: > > If $a was previously used as an array (or hash), then: > > declare a=$external_input So what you're saying is that blindly using external input can sometimes have negative consequences? > (or: > declare

declare a="$b" if $a previously set as array

Hiya, this is potentially dangerous: If $a was previously used as an array (or hash), then: declare a=$external_input (or: declare -r a=$external_input for instance (or -l...)... but not: readonly a=$external_input (or export) ) becomes a code injection vulnerability: $ b='($(uname>&2))' bash