one last collating sequence data point

[Bruce Korb]

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 "bash" is wrong.  One of the two has
to be wrong.

(Just to be clear:  bash is selecting files with "[a-z]*" and then
ls sorts them based on some collating sequence.  The sorting
collating order should be identical to the selection order.)

$ unset LC_COLLATE
$ ls -go
total 0
-rw-r--r-- 1 0 Jan 25 07:47 AZZ
-rw-r--r-- 1 0 Jan 25 07:47 BZZ
-rw-r--r-- 1 0 Jan 25 07:47 YZZ
-rw-r--r-- 1 0 Jan 25 07:47 ZZZ
-rw-r--r-- 1 0 Jan 25 07:47 aZZ
-rw-r--r-- 1 0 Jan 25 07:47 bZZ
-rw-r--r-- 1 0 Jan 25 07:47 yZZ
-rw-r--r-- 1 0 Jan 25 07:47 zZZ
$ ls -go [a-z]*
-rw-r--r-- 1 0 Jan 25 07:47 AZZ
-rw-r--r-- 1 0 Jan 25 07:47 BZZ
-rw-r--r-- 1 0 Jan 25 07:47 YZZ
-rw-r--r-- 1 0 Jan 25 07:47 aZZ
-rw-r--r-- 1 0 Jan 25 07:47 bZZ
-rw-r--r-- 1 0 Jan 25 07:47 yZZ
-rw-r--r-- 1 0 Jan 25 07:47 zZZ
$ export LC_COLLATE=C
$ ls -go [a-z]*
-rw-r--r-- 1 0 Jan 25 07:47 aZZ
-rw-r--r-- 1 0 Jan 25 07:47 bZZ
-rw-r--r-- 1 0 Jan 25 07:47 yZZ
-rw-r--r-- 1 0 Jan 25 07:47 zZZ
$ export LC_COLLATE=en_US
$ ls -go [a-z]*
-rw-r--r-- 1 0 Jan 25 07:47 aZZ
-rw-r--r-- 1 0 Jan 25 07:47 AZZ
-rw-r--r-- 1 0 Jan 25 07:47 bZZ
-rw-r--r-- 1 0 Jan 25 07:47 BZZ
-rw-r--r-- 1 0 Jan 25 07:47 yZZ
-rw-r--r-- 1 0 Jan 25 07:47 YZZ
-rw-r--r-- 1 0 Jan 25 07:47 zZZ


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

assigning variables at the end of a pipeline

[Elmar Stellnberger]

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/packages/BUILD/bash-3.1
-L/usr/src/packages/BUILD/bash-3.1/../readline-5.1
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2 -march=i586
-mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g
-D_GNU_SOURCE -DRECYCLES_PIDS -Wall -pipe -g -fbranch-probabilities
uname output: Linux sonic 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27
UTC 2006 i686 i686 i386 GNU/Linux
Machine Type: i586-suse-linux

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
sadasd

'hug' is supposed to be valid outside the loop as well!
Why is there an own fork of bash for the last process in the pipeline
(i.e. "while read hug; do echo $hug; done" or "read hug" respectively) ??
hug=$(
..
..
..
)
can easily become somewhat unhandy
Moreover we possibly want to assign to multiple variables when reading
from a file




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

bash gets confused by ANSI sequences

[Elmar Stellnberger]

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 postioning error after output without trailing newline seems to
be closely related.
Please have a look!

The use of ANSI sequences in konsole seems to confuse konsole's idea of
where the current write position is. When I run a bash shell inside
konsole and set the prompt string to contain ANSI escape sequences, then
when typing long lines the write position wraps back to the beginning of
the current line before the right margin has been reached. The same
behaviour can be observed with xterm, so the problem obviously has been
inherited from there.


/--- Additional Comment #1
 From Stephan Binner
 2002-09-21 14:48 --- /
What ANSI sequences? And you exclude an error of you when the two best
terminal emulators both show this behaviour? :-)


/--- Additional Comment #2
 From Thomas Koeller
 2002-09-21 14:56 --- /
Steps to reproduce:
 
1. Start a bash shell inside konsole.
2. Enter PS1="\e]2;\w\a\e[34;1m\! \s-\v \$\e[0m "
3. Type a long line (contents do not matter).


/--- Additional Comment #3
 From Stephan Binner
 2002-11-02 21:03 --- /
Likely a bash problem.


/--- Additional Comment #4
 From [EMAIL PROTECTED]
 2007-01-27 17:51 --- /
Even simple things like coloring the prompt will confuse konsole.
This is just too bad!
export PS1="\e[0;33m\u:\w> \e[0m"
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Typo in an include directive

[Pedro Saraiva]

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' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -Dqnx -Dqnx6   -I.  -I. -I./include -I./lib -I./lib/intl
-I/home/puto/bash-3.2/lib/intl  -g -O2
uname output: QNX localhost 6.3.0 2005/08/09-15:05:10EDT x86pc x86
Machine Type: i386-pc-nto-qnx6.3.0

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
   In the file "variables.c", there's a line which says "#include
". It should be .

Repeat-By:
   Not relevant.

Fix:
   Fix the typo.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash gets confused by ANSI sequences

[Andreas Schwab]

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 Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: bash gets confused by ANSI sequences

[Chet Ramey]

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 :
> cursor postioning error after output without trailing newline seems to
> be closely related.

Please read the Bash FAQ, question E3.

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: assigning variables at the end of a pipeline

[Chet Ramey]

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, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: one last collating sequence data point

[Chet Ramey]

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",
> then "ls" is wrong, otherwise "bash" is wrong.  One of the two has
> to be wrong.
> 
> (Just to be clear:  bash is selecting files with "[a-z]*" and then
> ls sorts them based on some collating sequence.  The sorting
> collating order should be identical to the selection order.)
> 
> $ unset LC_COLLATE

If LC_COLLATE is unset, LC_ALL and LANG both affect the collating order.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: one last collating sequence data point

[Benno Schulenberg]

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_COLLATE="en_GB.utf8"

$ unset LANG
$ locale | grep COLL
LC_COLLATE="POSIX"

Thanks, mystery solved.

Benno


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: one last collating sequence data point

[Bruce Korb]

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 an export issue, but I did show in a previous examples that
all LC_* variables plus LANG were not set.  Here is my standard
L* environment (NB: the LC_COLLATE is recently added):

$ set|egrep ^L
LC_COLLATE=C
LESS=-eMagis
LIBDIR=/home/usr/bkorb/Linux-i686/lib
LINES=63
LOGINLOG=/home/usr/bkorb/.hist/ZZLOGIN.log
LOGNAME=bkorb
$ env|egrep ^L
LOGINLOG=/home/usr/bkorb/.hist/ZZLOGIN.log
LIBDIR=/home/usr/bkorb/Linux-i686/lib
LC_COLLATE=C
LINES=63
LESS=-eMagis
LOGNAME=bkorb
$

There is an inconsistency and the cause is not readily discernible
by examining L* settings, exported or not.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: one last collating sequence data point

[Chet Ramey]

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, it has to do with what Posix calls the "native environment" (that
is the default locale).

One of the first things bash does when it starts is to call
setlocale(LC_ALL, ""), which returns the name of the default locale.  It's
set in an implementation-defined fashion using environment variables (or
to an "implementation-defined default."  The first time an instance of
bash starts up, at login, for instance, the call to setlocale selects the
native environment.  Bash doesn't export or set any of the locale variables
specially (though it will auto-export them if they're in the initial
environment), so if they are in the environment, either the user or the
"system" placed them there.

When the user modifies one of the locale environment variables, bash has to
reset the appropriate locale setting.  It does this by reproducing the
search order specified by Posix: LC_ALL, LC_???, LANG, and the native
environment.  Bash chooses the locale returned from the first call to
setlocale() as the native environment.

I could (and may) change bash to use "" to select the native environment
in the call to setlocale when none of the appropriate variables are set,
but that has problems of its own. setlocale() queries environment
variables, which requires bash to either replace getenv() (which it
attempts to do) or make `environ' point to bash's idea of its export
environment.  In either case, if bash is able to do it, only exported
variables will be returned.

There's no guarantee that this will work any better, either.  There's no
requirement that setlocale() call getenv() -- to satisfy Posix requirements
while still allowing library functions to be overridden, some systems do
the following:

getenv(name) calls __getenv(name) to do the real work
setlocale() calls __getenv to query environment variables

Sometimes this can be overcome by bash pointing environ to its own
exported environment, but other systems make `environ' an alias to the
`real' environment (e.g. (*_NSGetEnviron()).

On these systems (e.g., Mac OS X), the call to setlocale(var, "") will
end up querying the program's initial environment, regardless of any
changes.  You might even get an initial value of, for instance, LC_COLLATE
after you've unset it and changed LC_ALL or LANG.

Using "" to select the native environment would probably work better on
Linux, but nothing is going to work everywhere.  Maybe the best thing to
do is to call setlocale(var, "") only on systems that allow bash to replace
getenv().  There's no perfect solution.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash