Re: Severe Bash Bug with Arrays
On Thu, Apr 26, 2012 at 08:47:39PM -0700, Linda Walsh wrote:
> Obviously, they were not complete beginners to bash -- to be
> reading
> arrays in from vars holding multi-line text? I would assume they'd have
> the
> intelligence to know when to use * or @ and I wouldn't have to talk down to
> them
> and cover basics.
Oh, you would be amazed and astonished. I've learned never to assume
a person possesses advanced knowledge, when it comes to programming
questions.
> > a=(lib tmp bin share)
> > (export IFS=,;eval "echo /usr/{${a[*]}}")
> /usr/lib /usr/tmp /usr/bin /usr/share
>
> Anything else you wanna tell me NEVER/ALWAYS to do?
NEVER use eval plus a brace expansion to generate a list. That's just
freakin' evil. And unsafe:
imadev:~$ a=(lib tmp bin share '`date`')
imadev:~$ (export IFS=,;eval "echo /usr/{${a[*]}}")
/usr/lib /usr/tmp /usr/bin /usr/share /usr/Fri Apr 27 08:25:49 EDT 2012
(Replace `date` with whatever evil command you think is likely to be
put into the array by a malicious user.)
Alternative 1:
a=(lib tmp bin share)
echo "${a[@]/#//usr/}"
Alternative 2:
a=(lib tmp bin share)
printf "/usr/%s " "${a[@]}"
Re: Severe Bash Bug with Arrays
Greg Wooledge wrote:
NEVER use eval plus a brace expansion to generate a list. That's just
freakin' evil. And unsafe:
===
But I _like_ evil sometimes! >:->
imadev:~$ a=(lib tmp bin share '`date`')
imadev:~$ (export IFS=,;eval "echo /usr/{${a[*]}}")
/usr/lib /usr/tmp /usr/bin /usr/share /usr/Fri Apr 27 08:25:49 EDT 2012
There can be lots of such problems... I tried it on larger dirs.. parens
quote...all sorts of probs... tried embedded print "%q" ..etc
But reality is things like that save me time in typing in stuff or writing
maint scripts on my machine -- they aren't meant for handling user input.
They take hand editing to gen the paths I want and don't take user input,
so it's a specialized usage in that case
Alternative 1:
a=(lib tmp bin share)
echo "${a[@]/#//usr/}"
Alternative 2:
a=(lib tmp bin share)
printf "/usr/%s " "${a[@]}"
---
good points
But I was pointing out that [*] has its place ... I use [@] alot
more often than [*], but will use [*], though a bit irregularly,
when I want to get the # of items in an array (where either would work)..
though I could make a case if it was worth anything to me that #..@ return
# items and #...[*] return total length of all items... but I don't really
careand it would break all my usages of #..[*]... ;-)
C'est la vi...
Re: reply style (OT) (was Re: Severe Bash Bug w/Arrays)
Mike Frysinger wrote: Anything else you wanna tell me NEVER/ALWAYS to do? try ALWAYS being polite. but i guess that'll NEVER happen. oh well, thankfully kmail can auto-mute based on sender. -mike «"Always" "good to prejudge" "everything someone says" based on how they interact with one person [sic].» I am no more likely to use the same style with my mom than I would with a convicted killer, would you? More often than not if you've read my past replies, my replies will be colored with the flavor of the note that was written to me. On a good day, it will be a toned down version of the flavor, on a less good day, it might be an intensified version of the tone Depends on how many times I revise it. That response was my 5th revision... If you wanted acerbic, my first reply would have been much more appropriate (and immature). I tend to find people who auto-judge all content from a person based on responses to annoying people, more than a bit immature given that human interactions are highly contextual. And I mean immature -- in the sense that they seem to think human responses are 'robotic or preprogrammed', and haven't yet learned that humans are not machines. It takes dozens of notes from the same person before I begin to recognize their pervasive style, and THEN might start remembering their name. But usually I won't remember who wrote something by the time I read their next note -- unless they have a pervasive style that I notice over time, or have a protracted discussion with them. Hopefully you will get this, on the off chance that you haven't auto-muted yourself due to any posting you've ever made in the past that might have offended someone. ;^). Linda
(yet more OT) was (Re: reply style (OT))
p.s. - the previous was yet, another example of tailoring a response to a specific situation (in case that wasn't obvious); I think it's a first for me to deliberately use someone else's addr to send such a response. my apologies to any who were offended.
no-empty-command-line-completion -- thought fixed in 4.2? when?
I thought this was fixed in 4.2, yet I'm still seeing it... when's this going to be fixed? It's driving me crazy, as bash drops input because it asks questions about displaying 1000's of completions...). when I paste a few lines of source in at the shell -- doesn't matter if it is bash script or perl or written text... I can't rely on bash not corrupting the text. Even between single quotes: a=' blah ' will generate autocomplete. Yet I have no-empty-commandline-completion turned off. So why isn't this fixed?
Re: Is it possible or RFE to expand ranges of *arrays*
Maarten Billemont wrote:
On 26 Apr 2012, at 06:30, John Kearney wrote:
Am 26.04.2012 06:26, schrieb Linda Walsh:
I know I can get
a="abcdef" echo "${a[2:4]}" = cde
how do I do:
typeset -a a=(apple berry cherry date); then get:
echo ${a[1:2]} = "berry" "cherry" ( non-grouped args)
I tried to do it in a function and hurt myself.
echo ${a[@]:1:2}
I see little reason to ask bash to wordsplit the elements after expanding them.
You ought to quote that expansion.
---
Good point.
Since if you do:
> a=( 'apple pie' 'berry pie' 'cherry cake' 'dates divine')
> b=( ${a[@]:1:2} )
> echo ${#b[*]}
4
#yikes!
> b=( "${a[@]:1:2}" )
2
#woo!
I'd guess the original poster probably figured, I'd figure out the correct
form pretty quickly in usage. but thanks for your insight.
( (to all)*sigh*)
