Re: Passing variables by reference conflicts with local
On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote: > I prefer to avoid using eval by using declare, but declare inside a > function makes the variable local. Wouldn't it be nice to have a > global flag (declare -g) like zsh's typeset -g. Yeah. It definitely would. (This comes up every once in a while in IRC, too.)
Re: Passing variables by reference conflicts with local
On 5/3/10 8:21 AM, Greg Wooledge wrote: > On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote: >> I prefer to avoid using eval by using declare, but declare inside a >> function makes the variable local. Wouldn't it be nice to have a >> global flag (declare -g) like zsh's typeset -g. > > Yeah. It definitely would. (This comes up every once in a while in > IRC, too.) I am planning a feature like this for a future release. It may end up in bash-4.2. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
possible bug with 4.1
Howdy, I have noticed that some commands appear in history and some do not. I have isolated that to commands that have blanks before their name. I sometimes see this with pasted commands but this may be the same problem. Am I doing something wrong by any chance? Regards, George... "It's not what you know that hurts you, It's what you know that ain't so." Wil Rogers
Re: possible bug with 4.1
George R Goffe wrote: > I have noticed that some commands appear in history and some do > not. I have isolated that to commands that have blanks before their > name. I sometimes see this with pasted commands but this may be the > same problem. > > Am I doing something wrong by any chance? This is a feature so that a user may control what commands go into the history and which do not. In the bash man page it says: HISTCONTROL A colon-separated list of values controlling how commands are saved on the history list. If the list of values includes ignorespace, lines which begin with a space character are not saved in the history list. Remove "ignorespace" from HISTCONTROL and it will save commands that begin with a space too. Bob
Problem around brackets, && and ||
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc'
-DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-DSSH_SOURCE_BASHRC -O2 -pipe -march=native
-mtune=native
uname output: Linux terminus 2.6.33-gentoo-syrius #1 SMP PREEMPT Fri Feb
26 15:57:48 CET 2010 x86_64 AMD Phenom(tm) 9500 Quad-Core Processor
AuthenticAMD GNU/Linux
Machine Type:
x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 37
Release Status: release
Description:
If the last command in a {...} has && and fails and the {...}
has an || outside then the outside command will be executed.
This happens not only for {...} but (...) too. I have to add ||
: to the last commands as workaround.
My English is very bad so I wrote some sample code to
demonstrate the problem, and the workaround. I can repeat this under
Bash version 3
too.
Repeat-By:
bad.sh:
#!/bin/bash
/bin/true && \
{
echo "I have to see this"
/bin/false && echo "I don't have to see this"
} || echo "I never have to see this!"
Outputs:
I have to see this
I never have to see this!
bad2.sh:
#!/bin/bash
/bin/true && \
(
echo "I have to see this"
/bin/false && echo "I don't have to see this"
) || echo "I never have to see this!"
Outputs:
I have to see this
I never have to see this!
good.sh:
#!/bin/bash
/bin/true && \
{
echo "I have to see this"
/bin/false && echo "I don't have to see this" || :
} || echo "I never have to see this!"
Outputs:
I have to see this
Re: Problem around brackets, && and ||
On Mon, May 03, 2010 at 07:49:12PM +0200, Kunszt Árpád wrote:
> Description:
> If the last command in a {...} has && and fails and the {...}
> has an || outside then the outside command will be executed.
Use if/then/else/fi instead of && ||. Using && || is dangerous, as I've
explained here:
http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3
Re: Passing variables by reference conflicts with local
On 100503 08:57, Chet Ramey wrote:
> > On Sat, May 01, 2010 at 04:26:16AM -0500, Dennis Williamson wrote:
> >> I prefer to avoid using eval by using declare, but declare inside a
> >> function makes the variable local. Wouldn't it be nice to have a
> >> global flag (declare -g) like zsh's typeset -g.
> I am planning a feature like this for a future release. It may end up
> in bash-4.2.
What I'm happily exploiting in this thread (and trying to get consent
for) is the fact that declaring a global within a function does NOT
automatically make the variable global, but instead allows one to pass
variables between functions. In this light I also find the term
"global" misleading.
This thread is still leaving me with the feeling I'm doing something
wrong. Is this a documented and maintained bash feature? Can we safely
apply this feature to the bash-completion package? Will a `declare -g'
preserve the existing behaviour in say bash-4.2?
In other words: is it safe to exploit the behaviour below - 'a=A b=B'
not becoming global?
a=1; unset b
t() {
a=A b=B
}
u() {
local 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
Re: Problem around brackets, && and ||
2010-05-03 21:25 keltezéssel, Greg Wooledge írta:
> On Mon, May 03, 2010 at 07:49:12PM +0200, Kunszt Árpád wrote:
>
>> Description:
>> If the last command in a {...} has && and fails and the {...}
>> has an || outside then the outside command will be executed.
>>
> Use if/then/else/fi instead of && ||. Using && || is dangerous, as I've
> explained here:
>
> http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3
>
>
>
I read it, thanks. I understand it now.
I read man bash lots of times, but this behavior had escaped my
attention. There isn't any word about cmd1 && cmd2 || cmd3 only the cmd1
&& cmd2 and cmd1 || cmd2 mentioned. I think lots of people, including
myself, thought that && and || is an equivalent to the if ... then ...
else statement.
So my bugreport is now against the documentation. :-)
Arpad
Re: Passing variables by reference conflicts with local
I think I found a much cleaner workaround. It looks like a called
function can really unset local variables in the caller(?!), so that
passing by reference works:
_blackbox_unset_vars "$2" "$3"
If you would try to unset local variables directly in "blackbox()",
using:
unset -v "$2" "$3"
, passing by reference fails. Here's the code:
---8<---
unset -v i a b d # Make sure vars are unset
# Unset variables
# Param: $* variables to unset
_blackbox_unset_vars() {
unset -v "$@"
}
# Param: $1 input argument
# Param: $2 variable name to return value to
# Param: $3 variable name to return array value to
# Public library function
blackbox() {
local a b c d e f g h i j k=( foo "bar cee" )
# ...
# Lots of library code here
# ...
# Doing a 'unset -v "$2" "$3"' directly doesn't work?
_blackbox_unset_vars "$2" "$3"
printf -v"$2" %s b # Return value "b"
printf -v"$3" x && eval $3=\(\"\$...@]}\"\) # Return array $k
}
client() {
local i a b d
blackbox i a b; printf $'%s\n' $a "$...@]}" # Outputs vars ok
d='ls /;true'; blackbox i "$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
Re: Passing variables by reference conflicts with local
Freddy Vulto wrote:
# Param: $1 �variable name to return value to
# Public library function
blackbox() {
local __1
_blackbox __1
[[ $1 == __1 ]]&& echo "ERROR: variable name conflicts"\
"with local variable: $1"
printf -v $1 %s "$__1"
}
# Param: $1 �variable name to return value to
# Public library function
blackbox() {
[[ "$1" =~ [_[:alpha:]][_[:alnum:]]* ]] || die # TODO: error instead
if [ $1 == "__1" ]; then
local __2
_blackbox __2
printf -v $1 %s "$__2"
else
local __1
_blackbox __1
printf -v $1 %s "$__1"
fi
}
Wouldn't that avoid having variable names that can't be used?
It should be possible to place this code in a generic wrapper such that
you can do:
blackbox1() { call_varref _blackbox1 "$@"; }
blackbox2() { call_varref _blackbox2 "$@"; }
This requires, of course, that only one variable is 'passed by-ref' and
is at a consistent position (though you could easily add a parameter
specifying what position). How to do this is left as an exercise for the
reader :-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Oops. -- Shannon Foraker (David Weber, Ashes of Victory)
Re: completion gobbles partial match string
On 5/1/10 8:46 PM, jida...@jidanni.org wrote: > set show-all-if-ambiguous on This is the problem. I'll take a look. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: completion gobbles partial match string
On 5/3/10 9:23 PM, Chet Ramey wrote: > On 5/1/10 8:46 PM, jida...@jidanni.org wrote: > >> set show-all-if-ambiguous on > > This is the problem. I'll take a look. This is an interesting issue. The problem is as I described: globbing can result in multiple matches without any common prefix, which causes the glob pattern itself to be replaced with the common prefix (nothing). It works for tab without show-all-if-ambiguous set because the bash glob completion function clears the match list if there are multiple matches. You'd like not to do this for show-all-if-ambiguous, though. I'm going to experiment with a small change: if show-all-if-ambiguous or show-all-if-unmodified are set, and the common match prefix is shorter than the text being completed, readline will inhibit inserting the match. The guess is that replacing text with a shorter match will not be wanted. Should readline do this only if there are multiple matches? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
