variable scope
$ a=OUTSIDE
$ f1 () { local a=INSIDE; f2; }
$ f2 () { echo "before: $a";
unset a;
echo "after: $a"; }
$ f3 () { local a=INSIDE;
echo "before: $a";
unset a;
echo "after: $a"; }
$ f1
before: INSIDE
after: OUTSIDE
$ f3
before: INSIDE
after:
I can unset an 'external-local' variable, and then get his global scope
but I can't do the same with an 'internal-local' one
may be this is not perfectly coherent
(*imho*, local variables should not be seen in other functions...)
thanks for your job
bye
Re: =~ behaves differently in bash 3.2 and 3.0
Clark J. Wang schrieb: In bash 3.0.14, the condition [[ file.txt =~ .*\\.txt\$ ]] returns TRUE but in 3.2.39 it returns FALSE. But with the shopt option `compat31' set it also returns TRUE. Is that reasonable? In the bash manual, `compat31' makes sense only for quoted patterns. The string .*\\.txt\$ is considered to be quoted? I guess it doesn't work in 3.2.39 because there are to many backslashes: \\. tests for a literal \ followed by any character. \$ tests for a literal $ right after txt So this works as expected: [[ file.txt =~ .*\.txt$ ]]# condition is true Don't know about 3.0.14, but it looks like it performed expansion on the regexp, while 3.2.39 leaves it unchanged. Regards, Bernd -- Bernd Eggink http://sudrala.de
Re: =~ behaves differently in bash 3.2 and 3.0
2008-10-24, 14:56(+08), Clark J. Wang: > In bash 3.0.14, the condition [[ file.txt =~ .*\\.txt\$ ]] returns TRUE but > in 3.2.39 it returns FALSE. But with the shopt option `compat31' set it also > returns TRUE. Is that reasonable? In the bash manual, `compat31' makes sense > only for quoted patterns. The string .*\\.txt\$ is considered to be quoted? See question E14 in the bash FAQ. -- Stéphane
with bash 3.2 from source: hashmarks inside backticks cause parse error
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 uname output: Linux grid-ui.physik.uni-wuppertal.de 2.6.9-67.0.4.EL_SFS2.3_0smp #1 SMP Mon Jul 21 13:57:38 CEST 2008 i686 i686 i386 GNU/Linux Machine Type: i686-redhat-linux-gnu Bash Version: 3.2 Patch Level: 0 Release Status: release Description: A script containing some commands including hashmarks inside a backtick operator fails to run correctly. The hashmark(s) seem to be interpreted in a way that treats the rest of the line as comment, causing the closing backtick to be skipped, and finally resulting in a unexpected EOF parse error. This behaviour only occurs using a bash (3.2) I compiled from source on my machine. I reproduced the problem on a 32bit- and on my 64bit-machine. Repeat-By: Execute the following line: $ echo `seq -w 00 05 | sed -e 's# ##g'` The expected output is: 0 1 2 3 4 5 $ In bash compilations showing the described problem, the output is instead: $ echo `seq -w 00 05 | sed -e "s# ##g"` > (the bash is waiting for further input here... press CTRL+D) bash: unexpected EOF while looking for matching ``' bash: syntax error: unexpected end of file $
Re: with bash 3.2 from source: hashmarks inside backticks cause parse error
Tim München wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i686 > OS: linux-gnu > Compiler: gcc > Compilation > CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' > -DCONF_MACHTYPE='i686-redhat-linux-gnu' -DCONF_VENDOR='redhat' > -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. > -I. -I./include -I./lib -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g > -pipe -m32 -march=i386 -mtune=pentium4 > uname output: Linux grid-ui.physik.uni-wuppertal.de > 2.6.9-67.0.4.EL_SFS2.3_0smp #1 SMP Mon Jul 21 13:57:38 CEST 2008 i686 i686 > i386 GNU/Linux > Machine Type: i686-redhat-linux-gnu > > Bash Version: 3.2 > Patch Level: 0 > Release Status: release > > Description: > A script containing some commands including hashmarks inside a > backtick operator fails to run correctly. The hashmark(s) seem to be > interpreted in a way that treats the rest of the line as comment, causing the > closing backtick to be skipped, and finally resulting in a unexpected EOF > parse error. This was fixed in bash-3.2 patch 1. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: =~ behaves differently in bash 3.2 and 3.0
Clark J. Wang wrote: > In bash 3.0.14, the condition [[ file.txt =~ .*\\.txt\$ ]] returns TRUE but > in 3.2.39 it returns FALSE. But with the shopt option `compat31' set it also > returns TRUE. Is that reasonable? In the bash manual, `compat31' makes sense > only for quoted patterns. The string .*\\.txt\$ is considered to be quoted? The manual says that any part of the pattern may be quoted to force it to be matched as a string. This is the behavior that compat31 turns off. The backslash is one of the shell's quoting characters, so portions of the pattern above are quoted. The question is how the shell processes those quoted characters. When compat31 is off, during expansion, the shell converts the characters quoted using shell quoting in a way that removes their special meaning from the regexp matcher. This forces the characters to match themselves. The pattern passed to the regular expression matcher is exactly ".*\\.txt\$", since the backslash is also how one quotes characters to the regexp matcher When compat31 is enabled, the shell performs all word expansions on the pattern, including quote removal, and passes the result to the regexp matcher. In this case, the pattern passed is ".*\.txt$", which is what you had in mind. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: variable scope
Antonio Macchi wrote:
> $ a=OUTSIDE
>
> $ f1 () { local a=INSIDE; f2; }
>
> $ f2 () { echo "before: $a";
> unset a;
> echo "after: $a"; }
>
>
> $ f3 () { local a=INSIDE;
> echo "before: $a";
> unset a;
> echo "after: $a"; }
>
>
> $ f1
> before: INSIDE
> after: OUTSIDE
>
> $ f3
> before: INSIDE
> after:
>
>
> I can unset an 'external-local' variable, and then get his global scope
> but I can't do the same with an 'internal-local' one
>
> may be this is not perfectly coherent
This was a conscious design choice.
Local variables have a scope restricted to the function in which they're
declared and its descendants in the call tree. Local variables shadow
global variables with the same name. View it as a chain of symbol
tables searched from most recent back. When a descendant unsets a
variable it's inherited from it's caller, whether or not that variable
is local in its caller, it uncovers earlier-declared incarnations.
The choice to make a variable declared as local persist as local after
being was explicit, after I got a bunch of bug reports doing it the
other way. Folks wanted
f()
{
local a
foo
unset a
bar
a=biz
qux
}
to result in the assignment to a creating a local variable. In the end,
it may or may not have been the right choice, but that's the behavior
we have.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Using the arrow keys in vi-insert-mode frequently causes text to be deleted.
From: Wes To: bug-bash@gnu.org Subject: Using the arrow keys in vi-insert-mode frequently causes text to be deleted. Configuration Information [Automatically generated, do not change]: Machine: i686 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/home/eblake/bash-3.2.39-20/src/bash-3.2 -I/home/eblake/bash-3.2.39-20/src/bash-3.2/include -I/home/eblake/bash-3.2.39-20/src/bash-3.2/lib -O2 -pipe uname output: CYGWIN_NT-5.1 SchoolOfTiger 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin Machine Type: i686-pc-cygwin Bash Version: 3.2 Patch Level: 39 Release Status: release Description: I have only seen this problem on Cygwin. I've tried to duplicate it on RedHat and Arch Linux, but it works fine there. Basically, when using vi mode, I've noticed text get deleted when I use the arrow keys to move the cursor in insert mode. Repeat-By: 1. Switch to vi-mode. Doesn't matter how this is done. I have "set -o vi" in my .bashrc file. 2. Type a bunch of random or non-random characters. This will be in insert mode by default. 3. Now push the left arrow key down and hold it until it goes to the beginning of the line. Most of the time, a huge chunk of characters are deleted. 4. If this doesn't work, hold the right arrow key down to go back to the other end of the line to see if it happens. 5. Repeat. It happens pretty frequently for me, so it shouldn't be hard to replicate if it's going to happen at all.
