On 9/23/19 1:38 PM, Grisha Levit wrote:
> Currently nocaseglob and nocasematch both control case insensitivity
> of RE matching (in lib/sh/smatch.c):
>
> if (glob_ignore_case || match_ignore_case)
> rflags |= REG_ICASE;
>
> However, the documentation suggests that on
Currently nocaseglob and nocasematch both control case insensitivity
of RE matching (in lib/sh/smatch.c):
if (glob_ignore_case || match_ignore_case)
rflags |= REG_ICASE;
However, the documentation suggests that only nocasematch should have
this effect. I'm guessing this behavior
On 3/2/17 4:57 PM, Lukáš Bařinka wrote:
> A description of the bug behaviour:
>When the nocaseglob option is set, the [:upper:] class in pattern
>does not match capital or small letters. On the other hand,
>[:lower:] works fine.
Thanks for the report. Character class n
On Thu, Mar 02, 2017 at 10:57:57PM +0100, Luká?? Ba??inka wrote:
> A short script or ???recipe??? which exercises the bug and may be used
> to reproduce it:
>$ touch a A
>$ echo [[:upper:]]
>A
>$ shopt -s nocaseglob
>$ echo [[:lower:]]
>
The version number of Bash:
GNU bash, version 4.4.11(1)-release
The hardware and operating system:
x86_64-pc-linux-gnu, Debian GNU/Linux 9
A description of the bug behaviour:
When the nocaseglob option is set, the [:upper:] class in pattern
does not match capital or small letters
nocaseglob affects regex matching in [[ but according to the man page only
nocasematch should:
nocaseglob
If set, bash matches filenames in a case-insensitive fashion when
performing pathname expansion (see Pathname Expansion above).
nocasematch
If set, bash matches patterns in a case
included only files begin with b and c/C)
Well, let us run:
ale...@ubuntu64:/tmp$ shopt -u nocaseglob; shopt -s nullglob; for a in
[b-c]* ; do echo $a; done
bigstore
clipboardcache
clipboardcache-1
clipboardcache-2
clipboardcache-3
cLnlY6
codeblocks_dbgrpt-30651-20100903T011749
codeblocksIJ8lud
On Mon, Oct 04, 2010 at 08:14:32PM +0700, Alexey Vinogradov wrote:
ale...@ubuntu64:/tmp$ shopt -u nocaseglob; shopt -s nullglob; for a in
[B-C]* ; do echo $a; done
But the range search here is thow out only non-capital bigstore from the
listing, and still included both-cased files begin
Alexey Vinogradov wrote:
ale...@ubuntu64:/tmp$ shopt -u nocaseglob; shopt -s nullglob; for a in
[B-C]* ; do echo $a; done
Since you do not mention your locale setting I assume that you are not
aware of how it affects ranges. Here if your locale setting uses
dictionary sort ordering then [B-C
Tim Waugh wrote:
strcoll indicates that, in the en_US locale, `h' sorts between `A' and
`Z'. In the C locale, it does not. This is consistent with the
collating sequences I posted earlier.
Here is what Ulrich Drepper has to say on the matter (see
On Tue, 2007-01-23 at 14:14 -0500, Chet Ramey wrote:
The portable, standard way to perform character comparison using the
current locale is strcoll(). If I can't get the same results using
strcoll(), glibc is clearly doing something different internally. (And
there is no portable standard
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 helpful.
Aharon Robbins wrote:
Chet Ramey wrote:
You need to force the issue. Add
export LC_COLLATE=C
to your startup files.
I prefer to use an even bigger hammer:
export LC_ALL=C
That is a big hammer! But today I prefer to use UTF-8 character sets
and the associated machinery. It is
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
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, 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
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
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
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 1/20/07, Bob Proulx [EMAIL PROTECTED] wrote:
I think you have the nocaseglob right. I think this is a variable set
but not exported problem. Just guessing though.
Excellent guess. No cigar, tho:
$ echo [a-z]*
bin bk-archives Bugzilla core cron Desktop [[...]]
$ LC_COLLATE=C echo [a-z
Hi,
This cannot have been overseen, so perhaps I am not understanding
how nocaseglob is supposed to work:
$ bash --version
GNU bash, version 3.1.17(1)-release (i586-suse-linux)
Copyright (C) 2005 Free Software Foundation, Inc.
$ shopt|fgrep caseglob
nocaseglob off
$ echo tpdsrc/umod/nodesvr
Bruce Korb [EMAIL PROTECTED] writes:
$ echo tpdsrc/umod/nodesvr/test/[a-z]*
tpdsrc/umod/nodesvr/test/Makefile tpdsrc/umod/nodesvr/test/SCCS
tpdsrc/umod/node
What are the Makefile and SCCS entries doing on the line?
Please read the Bash FAQ, Question E9.
Andreas.
--
Andreas Schwab, SuSE
Andreas Schwab wrote:
Bruce Korb [EMAIL PROTECTED] writes:
$ echo tpdsrc/umod/nodesvr/test/[a-z]*
tpdsrc/umod/nodesvr/test/Makefile tpdsrc/umod/nodesvr/test/SCCS
tpdsrc/umod/node
What are the Makefile and SCCS entries doing on the line?
Please read the Bash FAQ, Question E9.
I did
Bruce Korb wrote:
This cannot have been overseen, so perhaps I am not understanding
how nocaseglob is supposed to work:
I think you have the nocaseglob right. I think this is a variable set
but not exported problem. Just guessing though.
$ bash --version
GNU bash, version 3.1.17(1)-release
26 matches
Mail list logo
