Re: [bash-bug] parsing error with heredoc and command substitution
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' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include > -I../bash/lib -g -O2 -Wall > uname output: Linux alexk 2.6.32-gg173-generic #gg173 SMP Wed Jun 23 > 05:24:15 UTC 2010 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > 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: line 3: unexpected EOF while looking for matching `)' > /tmp/bug.sh: line 8: syntax error: unexpected end of file > > The following works correctly (changed /bin/cat to cat): > > -- > #!/bin/bash > > a=$(cat << EOF | wc -l > a > b > EOF > ) > - > > and so does this (removed | wc -l): > > -- > #!/bin/bash > > a=$(/bin/cat << EOF > a > b > EOF > ) > - Hmmm ... I would expect that a=$((/bin/cat|wc -l) <
Re: [bash-bug] parsing error with heredoc and command substitution
"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
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
> 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 sure that you'll get ASCII sorting order if you set LANG=C. 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/
Re: BASH ignores language for command completion
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 fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: BASH ignores language for command completion
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 true enough, but Bruce said he already removed all the LC_ variables from his environment, so LANG should work. 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/
Re: parsing error with heredoc and command substitution
> 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: line 3: unexpected EOF while looking for matching `)' > /tmp/bug.sh: line 8: syntax error: unexpected end of file Thanks for the report. This will be fixed in the next release of bash. 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/
Re: BASH ignores language for command completion
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 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_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= So, for future reference, put this in my bashrc? eval $(locale | sed 's/=.*/=C/;s/^/export /') and remove the unset stuff? Of course, this is a GNU C Lib thingey, so it only works on GNU C Lib based systems. By the way, Chet, once upon a time long ago and far away, I patched BASH to support BASH_TRACEFD because where I worked there were 10's of thousands of lines of BASH scripting that presumed that output to stderr meant command failure. Well, I've moved on and lo and behold there's more scripting that makes that assumption. This time, merely thousands of lines. I'll re-do my old patch if you're ready to deal with it. :) Thanks! Regards, Bruce
Re: BASH ignores language for command completion
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_CTYPE="POSIX" >> LC_NUMERIC="POSIX" >> LC_TIME="POSIX" >> LC_COLLATE="POSIX" >> LC_MONETARY="POSIX" >> LC_MESSAGES="POSIX" >> LC_PAPER="POSIX" >> LC_NAME="POSIX" >> LC_ADDRESS="POSIX" >> LC_TELEPHONE="POSIX" >> LC_MEASUREMENT="POSIX" >> LC_IDENTIFICATION="POSIX" >> LC_ALL= > > So, for future reference, put this in my bashrc? > > eval $(locale | sed 's/=.*/=C/;s/^/export /') > > and remove the unset stuff? Of course, this is a GNU C Lib thingey, > so it only works on GNU C Lib based systems. Aren't the C and POSIX locales the same on glibc systems? Even if they're not, you should just have to change only LC_COLLATE and possibly LC_CTYPE anyway. > By the way, Chet, once upon a time long ago and far away, I > patched BASH to support BASH_TRACEFD because where I > worked there were 10's of thousands of lines of BASH scripting > that presumed that output to stderr meant command failure. > Well, I've moved on and lo and behold there's more scripting > that makes that assumption. This time, merely thousands of lines. > I'll re-do my old patch if you're ready to deal with it. :) ? bash-4.1 implements BASH_XTRACEFD. 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/
Re: BASH ignores language for command completion
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 ghastly code to undo things that should never have been done in the first place.
Re: BASH ignores language for command completion
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: This i18n stuff has become ludicrous. When my system is installed, it should have been possible to say, "I want an ASCII environment with letter sized paper" and not have some silly app find an obscure reference to A4 or en_US some place and give me what I've explicitly said I don't want. That overkill expression was a way of saying, "en_US -- DIE, DIE, DIE". :) > If something is setting LC_* variables you don't want, track it down and > stop it from doing so. Don't write ghastly code to undo things that > should never have been done in the first place. That involves getting app developers to agree on how to express "GOSH DARN IT, I WANT ASCII LANGUAGE". Chet maintains the one app that this en_US thing trips over the most. Cheers - Bruce
Substitution PE parsed wrong or doesn't work correctly
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.
It looks like the construct is incorrectly parsed (because it uses
slashes itself), but I may be wrong, I didn't inspect the code.
Regards,
Jan
