[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: currently doable? Indirect notation used w/a hash
From: |
Pierre Gaston |
Subject: |
Re: currently doable? Indirect notation used w/a hash |
Date: |
Fri, 14 Jun 2013 14:30:19 +0300 |
On Fri, Jun 14, 2013 at 2:25 PM, Dan Douglas <ormaaj@gmail.com> wrote:
> On Friday, June 14, 2013 06:02:15 AM Dan Douglas wrote:
>> On Monday, June 10, 2013 09:39:56 AM Greg Wooledge wrote:
>> > > On 10 Jun 2013 14:15, "Chris F.A. Johnson" <chris@cfajohnson.com> wrote:
>> > > > It is not the least bit difficult with eval:
>> > > >
>> > > > eval "array=( \"\${$1[@]}\" )"
>> >
>> > On Mon, Jun 10, 2013 at 09:17:23PM +0800, Chris Down wrote:
>> > > Enjoy your arbitrary command execution.
>> >
>> > To be fair, Chris Johnson was probably assuming a programming environment
>> > where the function is only callable from within the same script, and
>> > thus has only trustworthy arguments provided by the caller. Sometimes,
>> > this is the case. Sometimes, it isn't.
>> >
>> > In a more general sense, using eval SAFELY requires undergoing several
>> > tedious steps.
>>
>> You're aware of this. For the record, there should never be a situation where
>> a variable name isn't guaranteed. All builtins that accept variable names,
>> arithmetic variable dereferences, and indirect variable expansions are
>> exploitable, not just eval. It never makes sense to have the name of some
>> internal label not controlled entirely internally.
>>
>> If it's a library function used by some other script, then responsibility for
>> making that guarantee is inherited by the library consumer. There's no
>> difference.
>>
>> To validate a "parameter name" fully requires a full shell parser, because
>> the
>> subscript of an indexed array is effectively a part of its name as far as
>> Bash
>> is concerned.
>>
>
> Also forgot to mention (though it should be obvious).
>
> $ ~/doc/programs/bash43 -c 'function f { typeset -n x=$1; : "$x"; }; a=(yo
> jo); f "a[\$(echo yes this even applies to namerefs>&2)0]"'
> yes this even applies to namerefs
>
> In a nutshell bash namerefs don't actually enable any new functionality. It's
> just a convenient syntax, makes dealing with keys indirectly easier, and
> improves portability in some limited cases.
>
> --
> Dan Douglas
>
Maybe nameref also allows to avoid name clashes (which I believe is
not that easy to workaround now)?
- Re: currently doable? Indirect notation used w/a hash, (continued)
Re: currently doable? Indirect notation used w/a hash, Greg Wooledge, 2013/06/10
- Re: currently doable? Indirect notation used w/a hash, Chris F.A. Johnson, 2013/06/10
- Re: currently doable? Indirect notation used w/a hash, Chris Down, 2013/06/10
- Re: currently doable? Indirect notation used w/a hash, Greg Wooledge, 2013/06/10
- Re: currently doable? Indirect notation used w/a hash, Chris F.A. Johnson, 2013/06/10
- Re: currently doable? Indirect notation used w/a hash, Dan Douglas, 2013/06/14
- Re: currently doable? Indirect notation used w/a hash, Dan Douglas, 2013/06/14
- Re: currently doable? Indirect notation used w/a hash,
Pierre Gaston <=
- Re: currently doable? Indirect notation used w/a hash, Dan Douglas, 2013/06/14
- Re: currently doable? Indirect notation used w/a hash, Greg Wooledge, 2013/06/14
Re: currently doable? Indirect notation used w/a hash, Chris F.A. Johnson, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Greg Wooledge, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Chris F.A. Johnson, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Linda Walsh, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Chris F.A. Johnson, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Linda Walsh, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Linda Walsh, 2013/06/10
Re: currently doable? Indirect notation used w/a hash, Mike Frysinger, 2013/06/10