It's worth noting here that bash's globbing of '[A-Z]*' etc is
definitely different from the system collation sequence (i.e. using
fnmatch() or glob() functions). There is an open bug report about this
here:
On the contrary, the bash globbing of [A-Z] is using exactly the system's
collating
Chet Ramey wrote:
This shows the collating sequence for alphabetics in the en_US locale. (Since
I don't set LC_ALL anywhere in my startup files, my system's default locale is
apparently en_US.UTF-8.)
Is _that_ the deal, then? There is such a thing as a system default locale
that does not
[EMAIL PROTECTED] 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-pc-linux-gnu'
-DCONF_VENDOR='pc'
Bruce Korb wrote:
Chet Ramey wrote:
This shows the collating sequence for alphabetics in the en_US locale. (Since
I don't set LC_ALL anywhere in my startup files, my system's default locale is
apparently en_US.UTF-8.)
Is _that_ the deal, then? There is such a thing as a system default
Chet Ramey [EMAIL PROTECTED] writes:
On the contrary, the bash globbing of [A-Z] is using exactly the system's
collating sequence. Bash uses strcoll; glibc/python probably use character
value comparisons for old-style bracket range expressions.
glibc definitely uses strcoll as well. Most
On Tue, 23 Jan 2007, Chet Ramey wrote:
[EMAIL PROTECTED] 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'
On Tue, 2007-01-23 at 17:17 +0100, Andreas Schwab wrote:
glibc definitely uses strcoll as well. Most likely python has its own
implementation which gets it wrong.
No, really, this is going through glibc's __collseq_table_lookup
function. The Python example is just an easy-to-run distilled
On Tue, 23 Jan 2007 11:04:58 -0500
Chet Ramey [EMAIL PROTECTED] wrote:
One of the changes between bash-3.1 and bash-3.2 was to unify the
handling of the pattern in the `==' and `=~' conditional command
operators. Pattern characters on the rhs are quoted to represent
themselves (remove their
Tim Waugh wrote:
On Tue, 2007-01-23 at 17:17 +0100, Andreas Schwab wrote:
glibc definitely uses strcoll as well. Most likely python has its own
implementation which gets it wrong.
No, really, this is going through glibc's __collseq_table_lookup
function. The Python example is just an
Paul A. Clarke [EMAIL PROTECTED] wrote:
The man page states, for the -c option:
-c string If the -c option is present, then commands are read from
string. If there are arguments after the string, they are
assigned to the positional parameters,
I don't get this; I must be missing something. If I do, in bash-3.1:
I get identical results with fully-patched versions of bash-3.1 and bash-3.2:
$ cat x17
V=alphabet
[[ $V == alphabet ]] echo yes 1
[[ $V == alphabet ]] echo yes 2
[[ $V == 'alphabet' ]] echo yes 3
[[ $V =~ alphabet ]]
Chet Ramey wrote:
(Since I don't set LC_ALL anywhere in my startup files, my system's
default locale is apparently en_US.UTF-8.)
Even if you don't actively set the LANG, LC_COLLATE, LC_ALL locale
variables in your shell startup files they may be getting set in your
environment through
Tim Waugh wrote:
Further to this, I am having trouble porting existing scripts to
bash-3.2's new style of regex matching.
Here is one example that is problematic: I want to use a character class
in my regex, but bash seems to get confused by the ':]]' closing the
class, and apparently takes
Chet Ramey wrote:
Chet Ramey wrote:
(Since I don't set LC_ALL anywhere in my startup files, my system's
default locale is apparently en_US.UTF-8.)
Even if you don't actively set the LANG, LC_COLLATE, LC_ALL locale
variables in your shell startup files they may be getting set in your
On Tue, 23 Jan 2007, Chet Ramey wrote:
Bash Version: 3.2
Patch Level: 0
Release Status: release
Install the patches. One (patch 3) deals with this issue. The following
transcript shows the difference between the patched and unpatched versions
of bash-3.2.
That was it. Sorry about missing
15 matches
Mail list logo
