Kevin F. Quinn wrote:
> On Tue, 23 Jan 2007 16:55:02 -0500
> Chet Ramey <[EMAIL PROTECTED]> wrote:
>
>>> 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:
>
> $ /data/g2/tmp/portage/app-she
Bruce Korb wrote:
> Exactly. And I want to learn how to shoot that dang thing down. Dead.
> If I've cleared my environment of LC_* and LANG values, then by gum
> ``echo [a-z]*'' should work the way it has for the past 35 years, and
> not some newfangled thing that somebody thought would be "help
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
On Tue, 23 Jan 2007 16:55:02 -0500
Chet Ramey <[EMAIL PROTECTED]> wrote:
> > 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:
$ /data/g2/tmp/portage/app-shells/bash-3.2_p9-r2/image/bin/ba
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 you
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
> 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 th
> 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 =~ alphab
> >> 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.
$ cat x16
DOG="Dog name - 01 - Wiggles"
if [[ $DOG =~ ([[:alpha
"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 param
Paul A. Clarke 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, starting with $0.
I th
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 PAM's /e
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/
Hello,
since some time I have the problem that on some machines that programs
(f.i. irssi) do not resize when I change the terminal size. At first I had
the idea that this has something to do with the shopt checkwinsize but
if I understood the manpage correctly this is only to set COLUMNS and
LINE
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
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 t
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 te
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' -DCONF_MACHTYPE='i686-pc-linux-gn
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. Mos
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 loca
[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' -DLOCA
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 no
> 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
collati
23 matches
Mail list logo
