Re: [bash-bug] parsing error with heredoc and command substitution

2010-07-15 Thread Dr. Werner Fink
On Tue, Jul 13, 2010 at 01:51:31PM -0400, Alex Khesin wrote: > Configuration Information: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCAL

Re: [bash-bug] parsing error with heredoc and command substitution

2010-07-15 Thread Andreas Schwab
"Dr. Werner Fink" writes: > a=$((/bin/cat|wc -l) < a > b > EOF > ) Useless subshell. a=$({ /bin/cat | wc -l; } <

Re: [bash-bug] parsing error with heredoc and command substitution

2010-07-15 Thread Bernd Eggink
Am 15.07.2010 10:35, schrieb Andreas Schwab: "Dr. Werner Fink" writes: a=$((/bin/cat|wc -l)< Useless subshell. a=$({ /bin/cat | wc -l; }< ...and useless cat: a=$(wc -l

Re: BASH ignores language for command completion

2010-07-15 Thread Chet Ramey
> I've stripped all LC_* variables plus LANG from my environment: > > > $ env|fgrep LANG > > $ env|fgrep LC_ > > $ > > Command completion still used "EN_us" for sorting directories > in command completion. e.g.: If en_US happens to be the system's default locale, of course. You can only be sur

Re: BASH ignores language for command completion

2010-07-15 Thread Andreas Schwab
Chet Ramey writes: > If en_US happens to be the system's default locale, of course. You > can only be sure that you'll get ASCII sorting order if you set > LANG=C. No, you need to set LC_ALL=C, because LANG has the lowest priority. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fi

Re: BASH ignores language for command completion

2010-07-15 Thread Chet Ramey
On 7/15/10 8:19 AM, Andreas Schwab wrote: > Chet Ramey writes: > >> If en_US happens to be the system's default locale, of course. You >> can only be sure that you'll get ASCII sorting order if you set >> LANG=C. > > No, you need to set LC_ALL=C, because LANG has the lowest priority. That's tr

Re: parsing error with heredoc and command substitution

2010-07-15 Thread Chet Ramey
> Bash Version: 4.1 > Patch Level: 5 > Release Status: release > > Description: > > The following script used to work in bash 3.2 but does not work with > bash 4.x (I tried 4.0, 4.1.5, and 4.1.7) > > -- > #!/bin/bash > > a=$(/bin/cat << EOF | wc -l > a > b > EOF > ) > - > > /tmp/bug.sh

Re: BASH ignores language for command completion

2010-07-15 Thread Bruce Korb
On Thu, Jul 15, 2010 at 5:36 AM, Chet Ramey wrote: > On 7/15/10 8:19 AM, Andreas Schwab wrote: >> Chet Ramey writes: >> >>> If en_US happens to be the system's default locale, of course.  You >>> can only be sure that you'll get ASCII sorting order if you set >>> LANG=C. >> >> No, you need to set

Re: BASH ignores language for command completion

2010-07-15 Thread Chet Ramey
On 7/15/10 11:06 AM, Bruce Korb wrote: >>> No, you need to set LC_ALL=C, because LANG has the lowest priority. >> >> That's true enough, but Bruce said he already removed all the LC_ >> variables from his environment, so LANG should work. > > "It's too hard." :) > >> $ locale >> LANG= >> LC_CTY

Re: BASH ignores language for command completion

2010-07-15 Thread Greg Wooledge
On Thu, Jul 15, 2010 at 08:06:20AM -0700, Bruce Korb wrote: > So, for future reference, put this in my bashrc? > > eval $(locale | sed 's/=.*/=C/;s/^/export /') Gah! That's ludicrous. If something is setting LC_* variables you don't want, track it down and stop it from doing so. Don't write gh

Re: BASH ignores language for command completion

2010-07-15 Thread Bruce Korb
Hi Greg, On Thu, Jul 15, 2010 at 8:42 AM, Greg Wooledge wrote: > On Thu, Jul 15, 2010 at 08:06:20AM -0700, Bruce Korb wrote: >> So, for future reference, put this in my bashrc? >> >> eval $(locale | sed 's/=.*/=C/;s/^/export /') > > Gah!  That's ludicrous. That, actually, is part of my point: T

Substitution PE parsed wrong or doesn't work correctly

2010-07-15 Thread Jan Schampera
Hello, Tested versions: - 4.1.2(1)-release - 3.2.39(1)-release Reproduce by: string="1/2 3=" echo ${string//[= /]} Expected result: 123 Actual result: 1/2 3= Workaround: Escape the "inner" slash with a backslash. Within a bracket expression, the slash should lose its special meaning