Jan Schampera wrote:
I think the rationale about it is worth to read:
http://www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap09.html
(scroll down to "RE Bracket Expression")
IMHO this exception has clear historical reasons.
The discussion in the rationale captures the essentials of the di
Roman Rakus wrote:
> sequence, inclusive. In other locales, a range expression has
> unspecified behavior: strictly conforming applications shall not rely on
> whether the range expression is valid, or on the set of collating
> elements matched. A range expression shall be expressed as the startin
Roman Rakus wrote:
> I think in range [a-d] shouldn't be any upper char. These are 2
> different things. Collate orders and range match. Try to use glob and
> you will see difference.
> This is really not good behavior of bash.
This is and always has been locale-dependent. The collation sequence
Thanks for your replies. I didn't want to raise a portability and POSIX
discussion. I know about that. I was referring to either a bug in the
Bash manual or a bug in the Bash code, nothing else.
Let's try to rephrase that a bit (the topic is not POSIX nor portability):
The Bash manual allows the
Roman Rakus wrote:
Matthew Woehlke wrote:
Roman Rakus wrote:
When trying to match files [a-z] bash find files A-Z, depending on
LC_COLLATE.
The mistake is in usage of strcoll()/wcscoll(). It has nothing to do
with ranges. Instead should be used fnmatch().
I can try to change this behavior. Or
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
Matthew Woehlke wrote:
Roman Rakus wrote:
When trying to match files [a-z] bash find files A-Z, depending on
LC_COLLATE.
The mistake is in usage of strcoll()/wcscoll(). It has nothing to do
with ranges. Instead should be used fnmatch().
I can try to change this behavior. Or is this planned/done
Roman Rakus wrote:
When trying to match files [a-z] bash find files A-Z, depending on
LC_COLLATE.
The mistake is in usage of strcoll()/wcscoll(). It has nothing to do
with ranges. Instead should be used fnmatch().
I can try to change this behavior. Or is this planned/done for next bash
release?
When trying to match files [a-z] bash find files A-Z, depending on
LC_COLLATE.
The mistake is in usage of strcoll()/wcscoll(). It has nothing to do
with ranges. Instead should be used fnmatch().
I can try to change this behavior. Or is this planned/done for next bash
release?
begin:vcard
fn:Roma
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
On Thu, Jun 05, 2008 at 10:07:51AM +0200, Andreas Schwab wrote:
> Stephane Chazelas <[EMAIL PROTECTED]> writes:
>
> > I suspect this:
> > $ sh -c 'function() { echo a; }; function'
> > sh: -c: line 0: syntax error near unexpected token `('
> > sh: -c: line 0: `function() { echo a; }; function'
> >
Stephane Chazelas <[EMAIL PROTECTED]> writes:
> I suspect this:
> $ sh -c 'function() { echo a; }; function'
> sh: -c: line 0: syntax error near unexpected token `('
> sh: -c: line 0: `function() { echo a; }; function'
>
> breaks POSIX conformance, BTW (but then it's the same for AT&T
> ksh, pdksh
On Thu, Jun 05, 2008 at 06:31:36AM +0200, Jan Schampera wrote:
[...]
> The function definition is allowed in 3 forms:
> 1. NAME() ...
That's the Bourne and POSIX syntax
> 3. function NAME ...
That's the ksh syntax. It's probably only there for
compatibility with ksh (note
13 matches
Mail list logo
