Etan Reisner

That's true for system variables but I'm not sure that's as true for script-internal global variables (but maybe it is though that feels like playing in the system's/shell's playground a...

Bamboo uses many variables with the `bamboo_` prefix but not a single variable. (Though using a single associative array variable would certainly be nice.) But yes, same idea.

Seems reasonable and would work for me. Though I'd probably suggest making it require explicit pattern markings (or having both pattern and non-pattern versions so that literal variables could be...

@Moeriki `${bamboo.myvar}` isn't a shell variable. It isn't a legal variable name. (And even if it was that would still be many variables and not a single variable as that...

Putting command arguments in a string is an anti-pattern. It fails to work in many cases. You don't want to do it. Use an array. (See http://mywiki.wooledge.org/BashFAQ/050 for discussion of...

`"$@"` expansion as multiple words is posix. That's the correct way to handle this sort of thing. If you can't do that then you get to deal with the fact...

It is not "correct in every way". It doesn't work if any arguments need to have embedded spaces or need shell glob metacharacters and it _cannot_ be made to support...

That won't work. Those single quotes make it through to the application and the string is two words/arguments and the single quotes **don't** prevent shell expansion of the contents of...

Yeah, barring specific spec language indicating that the command substitution _must_ be performed first this seems unnecessarily risky to me. (I took a quick look at the spec but didn't...

It came up in code I actually wrote. How "real" that code is you can judge for yourself. =) https://github.com/deryni/expandTilde.sh/blob/master/tildeExpand.sh#L36 Looking at it again there's no reason not to just...