Re: Bash $@ Parameter Variable Breaking Out of Strings

[Adam Danischewski]

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.ramey@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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/