Re: currently doable? Indirect notation used w/a hash
On 14 Jun 2013 00:57, "Linda Walsh" wrote: > > > > Chet Ramey wrote: >>> >>> Now I want to access the value for IP for the current "IF" (IF holding >>> eth0 or eth1 or some other InterFace name). >> >> >> This is an excellent statement of the rationale for nameref variables, >> which will be implemented in bash-4.3. > > > That order fries wouldn't happen to come with > the ability to also export such things would it? ;-) Please, no more brittle export hacks. I'm already crying enough at function exports.
Re: currently doable? Indirect notation used w/a hash
Chris Down wrote: Chet Ramey wrote: >> Now I want to access the value for IP for the current "IF" (IF holding >> eth0 or eth1 or some other InterFace name). > This is an excellent statement of the rationale for nameref variables, > which will be implemented in bash-4.3. That order fries wouldn't happen to come with the ability to also export such things would it? ;-) Please, no more brittle export hacks. I'm already crying enough at function exports. Brittle would be bad. Pliant and chewy would be much better, I agree. Perhaps you might explain what you mean by brittle? Like the export hacks you get in the Antarctic in June? The word brittle with export doesn't seem to fit very well. What happened to your functions? Don't they work?
Re: currently doable? Indirect notation used w/a hash
On 14 Jun 2013 10:21, "Linda Walsh" wrote: >> Please, no more brittle export hacks. I'm already crying enough at function exports. > > > Brittle would be bad. Pliant and chewy would be much better, I agree. > > Perhaps you might explain what you mean by brittle? Like the export hacks > you get in the Antarctic in June? The word brittle with export doesn't > seem to fit very well. What happened to your functions? Don't they work? You are aware of *how* they work, yes? (with apologies for the terse replies, I'm on my phone)
Re: currently doable? Indirect notation used w/a hash
On Monday, June 10, 2013 09:39:56 AM Greg Wooledge wrote:
> > On 10 Jun 2013 14:15, "Chris F.A. Johnson" 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.
--
Dan Douglas
Re: currently doable? Indirect notation used w/a hash
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" 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
Re: currently doable? Indirect notation used w/a hash
On Fri, Jun 14, 2013 at 2:25 PM, Dan Douglas 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" 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
On Friday, June 14, 2013 02:30:19 PM Pierre Gaston wrote:
> On Fri, Jun 14, 2013 at 2:25 PM, Dan Douglas wrote:
> > 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.
> >
> Maybe nameref also allows to avoid name clashes (which I believe is
> not that easy to workaround now)?
It doesn't. https://gist.github.com/ormaaj/5682807
--
Dan Douglas
Re: corrupted input after size function (input that's not recorded by bash)
On Thu, Jun 13, 2013 at 04:42:36PM -0700, Linda Walsh wrote:
> Chris F.A. Johnson wrote:
> > The baskspaces (\b) are erasing your input, not the function's
> > output.
That's incorrect. A backspace character sent to a terminal device
moves the cursor (or does whatever else the terminal chooses to do
when it receives the character) but has no effect on the input buffer.
> Second problem with that theory, I resize the window and see
> the output... THEN, I type a command and the first word is ignored.
For what it's worth, I cannot reproduce this in a simple test. I opened
a new window, and then:
imadev:~$ showsize() { echo xyz; }; trap showsize SIGWINCH
imadev:~$
The function and trap have been defined. Then I resized the window,
and xyz (plus newline) appeared as expected. I typed "echo foo" and
pressed Enter, and got the expected result.
imadev:~$ xyz
echo foo
foo
imadev:~$
This makes me continue to suspect that the problem is being triggered by
something else in your setup (possibly multiple things working together).
You might try to reproduce the problem in a simpler setup, to see if you
can isolate what factors must be present for it to occur.
Re: currently doable? Indirect notation used w/a hash
On Fri, Jun 14, 2013 at 06:25:12AM -0500, Dan Douglas wrote:
> 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
No, that was not obvious.
Also, ouch. :(
Re: corrupted input after size function (input that's not recorded by bash)
Linda Walsh wrote:
>
> I have a small function in my bashrc:
>
> function showsize () {\
> local s=$(stty size); local o="(${s% *}x${s#* })"; s="${#o}";\
> echo -n $o; while ((s-- > 0));do echo -ne "\b"; done; \
> }
> export -f showsize
> trap showsize SIGWINCH
> ---
> That has the effect of showing me my current window size
> when I resize it.
>
> The odd thing is, if I use it while at a bash input prompt --
> any command I type has the first word ignored.
Ignored or executed as a separate command?
Using bash 4.2.45, "echo ls /" is treated as "echo ; ls /" although
as you've noticed the command appears in the history as-typed.
>
> so if I type:
>> echo cmd
>
> If 'cmd' is not a typo you can use command-not-found to lookup the
> package that contains it, like this:
> cnf cmd
> ---
> But then I re-edit the line (in vi-mode, ESC-k, it shows me I typed
> echo cmd -- and, indeed, if I hit return, it echo's the word 'cmd'
> w/no error.
>
> So how can my showsize function be mangling the input in a way that
> prevents proper execution, but isn't recorded by bash?
Trial and error suggests it's something to do with new-style command
substitution. Try backticks:
local s=`stty size`
>
> (this has been one of those things that's bothered me for years, but
> never been important enough to even ask about... I thought I'd look at it
> to fix it, but still don't see why it does what it does).
>
> Any clues?
showsize()
{
local o="(${LINES}x${COLUMNS})" ; local s="${o//?/\\b}" ; printf "$o$s"
}
Re: corrupted input after size function (input that's not recorded by bash)
Greg Wooledge wrote: This makes me continue to suspect that the problem is being triggered by something else in your setup (possibly multiple things working together). You might try to reproduce the problem in a simpler setup, to see if you can isolate what factors must be present for it to occur. Well, that's good input... Now I have to figure out how to break your setup too, er, I mean, fix my setup ... ;-) I'll definitely try it sans anything else and see what comes up. Could ven be the term settings or some interaction with the term emulator you use vs. mine.
Re: currently doable? Indirect notation used w/a hash
Chris Down wrote: On 14 Jun 2013 10:21, "Linda Walsh" wrote: Please, no more brittle export hacks. I'm already crying enough at function exports. Brittle would be bad. Pliant and chewy would be much better, I agree. Perhaps you might explain what you mean by brittle? Like the export hacks you get in the Antarctic in June? The word brittle with export doesn't seem to fit very well. What happened to your functions? Don't they work? You are aware of *how* they work, yes? (with apologies for the terse replies, I'm on my phone) They are put in the environment as strings, no? That seems fairly sound for most uses. It's far from bullet proof, but this is unencrypted SHELL we are talking about, so for it's use case, I don't see why it would be such a problem.
