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 only nocasematch should ha
On 8/4/15 11:33 PM, isabella parakiss wrote:
> 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).
> n
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]
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 begi
On 2/16/07, Chet Ramey <[EMAIL PROTECTED]> wrote:
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
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
> https://bugzilla.redhat.com/b
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
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.
>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 "
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
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
> 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
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
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, 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
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
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
On Mon, 2007-01-22 at 08:04 -0800, Bruce Korb wrote:
> There seems to be something else aside from LC_ALL, LC_COLLATE
> and LANG that affects collating sequence. Notice the difference
> between "[a-d]*" and "[a-D]*". Whatever collating sequence is being used
> do select files puts "D" after "d",
On 1/22/07, Bob Proulx <[EMAIL PROTECTED]> wrote:
Unfortunately in this case setting the variable on the command line
for that command won't do what you want. Since file globbing takes
I figured that out. :}
(unset LC_ALL LC_COLLATE LANG ; echo [a-z]*)
(LC_COLLATE=en_US.UTF-8 ; echo [a-z
Bruce Korb wrote:
> $ echo [a-z]*
> bin bk-archives Bugzilla core cron Desktop [[...]]
> $ LC_COLLATE=C echo [a-z]*
> bin bk-archives Bugzilla core cron Desktop [[...]]
Unfortunately in this case setting the variable on the command line
for that command won't do what you want. Since file globbing
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]*
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)-re
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, Ques
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 Sch
26 matches
Mail list logo
