Re: one last collating sequence data point

Bruce Korb wrote: >> If LC_COLLATE is unset, LC_ALL and LANG both affect the collating order. > > Neither of which were in the environment, but I didn't show that > "conclusively". "Trust me" (really). In any event, why would it be > that "bash" would use en_US and "ls" would use "C"? Again, i

Re: one last collating sequence data point

Chet Ramey wrote: > If LC_COLLATE is unset, LC_ALL and LANG both affect the collating order. Neither of which were in the environment, but I didn't show that "conclusively". "Trust me" (really). In any event, why would it be that "bash" would use en_US and "ls" would use "C"? Yes, it could be

Re: one last collating sequence data point

Chet Ramey wrote: > Bruce Korb wrote: > > $ unset LC_COLLATE > > If LC_COLLATE is unset, LC_ALL and LANG both affect the collating > order. Aha! So that is where the apparent "system default locale" comes from. $ locale | grep COLL LC_COLLATE=POSIX $ unset LC_COLLATE $ locale | grep COLL LC_CO

Re: one last collating sequence data point

Bruce Korb wrote: > In the listings below, two programs are involved: "ls" and "bash". > I am inclined to believe that "bash" treats a missing LC_COLLATE > as "en_US" and "ls" treats it as "C". If there is such a thing as > an invisible (not in environment variables) "system default locale", > th

Re: assigning variables at the end of a pipeline

Elmar Stellnberger wrote: > Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > estellnb:~> echo xx | while read hug; do echo $hug; done > xx >> echo $hug > sadasd > > estellnb:~> echo xx | read hug; echo $hug Please read the Bash FAQ, question E4. Chet -- ``The lyf so short, t

Re: bash gets confused by ANSI sequences

Elmar Stellnberger wrote: > This bug has already been reported for konsole under bugs.kde.org, > bug#Bug 48109 > In a fact it is an error of bash, because I get the same results in text > mode under vt01. > Additionally Bug 138411

Re: bash gets confused by ANSI sequences

Elmar Stellnberger <[EMAIL PROTECTED]> writes: > This bug has already been reported for konsole under bugs.kde.org, > bug#Bug 48109 Read , question E3. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Lin

Typo in an include directive

Configuration Information [Automatically generated, do not change]: Machine: i386 OS: nto-qnx6.3.0 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE=' nto-qnx6.3.0' -DCONF_MACHTYPE='i386-pc-nto-qnx6.3.0' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale

bash gets confused by ANSI sequences

This bug has already been reported for konsole under bugs.kde.org, bug#Bug 48109 In a fact it is an error of bash, because I get the same results in text mode under vt01. Additionally Bug 138411 : cursor postion

assigning variables at the end of a pipeline

From: [EMAIL PROTECTED] To: bug-bash@gnu.org Subject: assigning variables at the end of a pipeline Message-Id: <[EMAIL PROTECTED]> Date: Fri, 26 Jan 2007 17:18:28 +0100 (CET) Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux Compiler: gcc -I/usr/src/packag

one last collating sequence data point

In the listings below, two programs are involved: "ls" and "bash". I am inclined to believe that "bash" treats a missing LC_COLLATE as "en_US" and "ls" treats it as "C". If there is such a thing as an invisible (not in environment variables) "system default locale", then "ls" is wrong, otherwise