> Am 22.03.2016 um 15:47 schrieb Adam Danischewski
> <adam.danischew...@gmail.com>:
>
> 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.
>
> $ alias t2='_() { /tmp/m.bsh -d "clarify $@"; }; _'
alias t2='_() { $HOME/m.bsh -d "clarify $*"; }; _'
might help.
For "$@" the man page says: If the double-quoted expansion occurs within a
word, the expansion of the first parameter is joined with the beginning part
of the original word [...]
-- Reuti
> $ 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 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 ### !?
>
>
