#becomes "b". Single quotes prevent eval.
# +-1+ +---2+
eval $1="${!1/%\/*}"/'${!1#*/}'
else
# No, $1 doesn't contain slash
eval $1="${!1}"
fi
fi
} # __expand_tilde_by_ref()
---8<---
Freddy Vulto
http://fvue.nl
upvars from malicious variable names:
$ typeset 'ls -l'
bash: typeset: `ls -l': not a valid identifier
$ echo $?
1
Freddy Vulto
http://fvue.nl
et once (skipped t1)
#| | | +- unset thrice to global
#| | +- unset twice till global
#| +- unset once till t1
#+- unset not
See also: http://fvue.nl/wiki/Bash:_Unset
Freddy Vulto
http://fvue.nl
count regarding prefixing?
Does bash officially "reserve" any variable/function prefix to itself?
At least BASH_* and COMP_* seem to be used by bash.
Greetings,
Freddy Vulto
http://fvue.nl
.. [dir] = cd ../../../../../../../[dir]
For more information and download, see:
http://fvue.nl/wiki/Bash:_Cdots
Freddy Vulto
http://fvue.nl
est
declare -p a b # Ok: Globals are unchanged (a=A, b=nil)
It seems to work all right on bash-2.05b, bash-3.0, bash-3.2, bash-4.0,
bash-4.1.
The `eval' could be replace by `printf -v', but this requires bash >
3.1-alpha1 and the eval is relative safe because the varname is c
lobal
#| +- unset once till t1
#+- unset not
It seems to work on bash-3.0, 3.2, 4.0 and 4.1.
Is this a bug or a feature?
Freddy Vulto
http://fvue.nl/wiki/Bash:_passing_variables_by_reference
quot;$d" "$d" # No oops
}
client
echo "globals: $i $a $b $d" # No globals created
---8<---
It seems to work on bash-3.2.39, 4.0.33 and 4.1.2.
Is this behaviour safe to exploit?
Freddy Vulto
http://fvue.nl/wiki/Bash:_passing_variables_by_reference
ocal a b
t
echo $a $b
}
u # Outputs "A B"
echo $a $b # Outputs "1 ": globals aren't touched nor created
Freddy Vulto
http://fvue.nl/wiki/Bash:_passing_variables_by_reference
# Catch status
printf -v"$2" %s "$__2" # Return value
printf -v"$3" x && eval $3=\(\"\${_...@]}\"\) # Return array
return $__x
"$3" && # Return array value
eval $3=\( \"\${_...@]}\" \) || return 1
return $__x # Return exit status
}
blackbox i a b; printf $'%s\n' $a "$...@]}" # Outputs vars all right
blackbox i __2 __3 # Outputs error
d='ls /;true'; blackbox i "$d" "$d" # No oops
_blackbox a # Force public access
Freddy Vulto
http://fvue.nl/wiki/Bash:_passing_variables_by_reference
with local variable: $1"
printf -v $1 %s "$__1"
}
blackbox a; echo $a # Outputs "b" all right
blackbox __1 # Outputs error
d='ls /;true'; blackbox "$d" # No more oops
Freddy Vulto
http://fvue.nl/wiki/Bash:_passing_variables_by_reference
On 100430 08:19, Greg Wooledge wrote:
> On Fri, Apr 30, 2010 at 12:02:58AM +0200, Freddy Vulto wrote:
> > Passing variables by reference however, has a caveat in that
> > local variables override the passing by reference, e.g.:
> >
> > t() {
> >
flicts \
with local variable: $1"
eval $1=\$__1
}
Now we can call t() and receive an error if the variable causes a
conflict:
$ t __1; echo $__1
ERROR: variable name conflicts with local variable: __1
$ t a; echo $a
b
Thoughts? Ideas? Is there a bash
setting to make
bash-3 echo "^C" then typing ^C, just like bash-4?
Regards,
Freddy Vulto
http://fvue.nl
erence, works on both bash-3 & bash-4
c
$ compgen -f a\\\'b/ # Workaround for bash-4
a\'b/c
$ compgen -f a\\\'b/ # Workaround for bash-3
a\'b/c
Regards,
Freddy Vulto
http://fvue.nl
n't have a directory
`ab' besides `a\'b'? That's whap happened to me too...
It seems compgen is leaving out the quote out erroneously:
$ mkdir a\'b
$ touch a\'b/c
$ mkdir ab
$ touch ab/e
$ compgen -f a\'b/
ab/e # Should be a\'b/c
Freddy Vulto
http://fvue.nl
`compgen -f' produces no output if the directory contains a single quote.
I get the same result on both bash-3.2.39 and bash-4.0.35.
Steps to reproduce the problem:
$ mkdir a\'b
$ touch a\'b/{c,d}
$ compgen -f a\'b/
$
Expected output:
a\'b/c
a
I get:
$ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
Bash-4 seems to give the desired result (leave the array intact), but
it's a bug on bash-3?
Regards,
Freddy Vulto
http://fvue.nl
disable it (d), although enabling it goes all right (c):
$ a foo= ^C # Ok. Reference with -o filenames disabled
$ b foo\= ^C # OK. Reference with -o filenames enabled
$ c foo\= ^C # OK
$ d foo\= ^C # Expected foo= (-o filenames disabled)
Regards,
Freddy Vulto
http://fvue.nl
t seems to be in bash-3 as
well. The command:
$ b'
doesn't complete with commands but with local filenames, although this
is a valid command:
$ b'ash'
All in all, the patch seems like an improvement to me.
Freddy Vulto
http://fvue.nl
b c # This returns `a', where I'd expected `b'?
3. Complete `b' within process substitution:
$ a <(b c # This returns `b' all right.
Regards,
Freddy Vulto
http://fvue.nl
${#comp_wor...@]}; i++)); do
echo $i: "${COMP_WORDS[$i]}"
done
}
complete -F _cword a
2. Complete `a':
$ a 'b c
Regards,
Freddy Vulto
http://fvue.nl
ractive-comments:monitor:vi
$ set +o verbose
$ echo $SHELLOPTS # 'history' is still there
braceexpand:histexpand:history:interactive-comments:monitor:vi
Regards,
Freddy Vulto
http://fvue.nl
etc/hosts
127.0.0.1 localhost
127.0.1.1 freddy
$ compgen -A hostname
localhost
freddy
$ unset -v HOSTFILE
$ compgen -A hostname
�
�
$
I tested on another machine with bash-3.1 (patch level 17), having the
same problem.
Regards, Freddy Vulto
http://fvue.nl
Even within the EXIT trap, the -u error exit status disappears when -e
is used (?):
$ (set -u; trap 'echo $?' EXIT; echo $bad)
bash: bad: unbound variable
1
$ (set -eu; trap 'echo $?' EXIT; echo $bad)
bash: bad: unbound variable
0
Freddy Vulto
http://fvue.nl
My mistake, the 'trap' of (5) needs to be defined within single quotes
to prevent the $? from expanding too soon:
$ trap 'echo Exit $?' ERR
Freddy Vulto
t 1
$ trap - ERR # Reset trap
Freddy Vulto
http://fvue.nl
; false; echo K)
# output: IJ; exits within right `()' only
echo $(set -e; echo L; false; echo M) && echo $(set -e; echo N; false;
echo O)
# output: LN; exits within `$()' if `-e' set explicitly
(set -e; echo P; false; echo Q) && (set -e; echo R; false; echo S)
# output: PQR; exits within right `()' only
---8<---
Regards, Freddy Vulto
29 matches
Mail list logo
