Thanks for the quick reply, I hit send by accident, the first part is clear
in the documentation.
On the second part, I still see a potential problem because Bash is
allowing for access to the internal local function variables.
E.g.
function update() {
local -i VAR=45
local -i TOPSECRET_NUMBER=50 ## No one can know about.
VAR+=${1}
echo $VAR
}
$ update 0
45
$ update TOPSECRET_NUMBER
95
## Successfully deduce that TOPSECRET_NUMBER is 50
## Instead could be CC_NUM, CCARD, SessionID, CrToken, etc.
On Tue, Mar 22, 2016 at 11:18 AM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 3/22/16 10:47 AM, Adam Danischewski wrote:
> > I noticed an issue using the parameter built-in variable $@ breaking
> > out of contained strings when utilized in functions.
> >
> > For example, consider the following bash script: m.bsh
> > #!/bin/bash
> > echo "$#"
> > while getopts d: OPTION "$@"; do
> > case "$OPTION" in
> > d)
> > echo "the optarg is ${OPTARG##*=}, optind is ${OPTIND}"
> > [[ -z "${OPTARG}" ]] && echo "Let's set the null byte as the delim."
> > ;;
> > esac
> > done
> > exit 0
> >
> > $alias t1='_() { var=$@; /tmp/m.bsh -d "clarify ${var}"; }; _'
> > $t1 hi there
> > 2
> > the optarg is clarify hi there, optind is 3
> > ### Correctly considers the text as a single string argument
> > containing a space.
>
> The $@ is expanded in a context where word splitting is not performed.
> There has actually been a lot of discussion about this case on the
> Posix shell standardization mailing list.
>
> >
> > $alias t2='_() { /tmp/m.bsh -d "clarify $@"; }; _'
> > $ t2 hi there
> > 3
> > the optarg is clarify hi, optind is 3
> > ### Incorrectly breaks the argument array variable out as separate
> > single string arguments.
>
> I'm not sure why you think this is a problem. When $@ occurs in double
> quotes, it expands to multiple words, one for each positional parameter,
> combined with the portions of the string before and after it. "$@" always
> expands to multiple words if there are multiple positional parameters and
> word splitting is performed.
>
> > I noticed another interesting occurrence as well, I'm not sure if they
> are
> > related, to variable names:
> >
> > function update() {
> > local -i VAR=45
> > VAR+=-1
> > VAR+=$1
> > echo $VAR
> > }
> >
> > $ VAR2=2
> > $ update VAR2
> > 47
> >
> > $ VAR=3
> > $ update VAR
> > 88 ### !?
>
> There's no mystery here. When a variable name is used in arithemtic
> evaluation context, its value is expanded as an expression. Since VAR is
> an integer variable, the rhs of any assignment to it is considered an
> arithmetic expression and evaluated as such.
>
> So what you end up with is
>
> local -i VAR=45 # VAR = 45
> VAR+=-1 # VAR = 44, local var takes precedence
> VAR+=VAR # VAR += 44 --> VAR = 88, local var used
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
