Re: Emulation and NUMERIC_GLOB_SORT

Re: Emulation and NUMERIC_GLOB_SORT

[Sven Wischnowsky]

Zefram wrote:

> Fundamentally, I view globbing as a programming feature, which should
> be utterly unaffected by locale.  Same for string comparisons in [[]].
> I think we do want a locale-dependent string comparison operation, but
> its use is very much the exception, not the rule.  Pattern matching and
> string comparisons are used on all sorts of strings, and only very rarely
> on natural-language text.

Sounds like a case for a matching flag, doesn't it? `(#L)' or
something to turn using locale-definitions on (and also in sorting if
the thing is globbed).

> ...
> 
> [1] That reminds me, one of the things I never got round to implementing
> as a builtin was the POSIX "printf" utility.  The advantage of having
> it as a builtin is that we could then use the same code for a "sprintf"
> builtin, which would put the result into a shell variable instead of
> sending it to standard output, which is a feature I often miss.

Oh yes.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Emulation and NUMERIC_GLOB_SORT

[Zefram]

Sven Wischnowsky wrote:
>Sounds like a case for a matching flag, doesn't it? `(#L)' or
>something to turn using locale-definitions on (and also in sorting if
>the thing is globbed).

I was going to mention that, but thought it would be obvious... we
need two things, a matching flag to use locale in character ranges and
case-insensitivity, and *separately* a globbing qualifier to use locale
when sorting the result of globbing.  Should probably have two separate
options for them too.  And if there's an option, then a matching flag
to turn *off* locale use also.

-zefram

Emulation and NUMERIC_GLOB_SORT

[Bart Schaefer]

In another thread, Sven wrote:
} And I hope there are no calls [in the completion function system]
} to `emulate -L zsh' at all -- I hate it ever since it once reset
} NUMERIC_GLOB_SORT for me

I've always been really ambivalent about whether glob sorting ought to
be controlled by emulate, but I also always conclude that there might
be some circumstance in which someone is relying on globbing order.
However, now that I think of it, globbing order is already going to be
altered by LC_COLLATE, so scripts that rely on it are out of luck in
the first place.

Anyone care to dispute the conclusion that either NUMERIC_GLOB_SORT
should not be reset by emulate, or else LC_COLLATE should not be used
in glob sorting?  (We already removed it from character ranges.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Emulation and NUMERIC_GLOB_SORT

[Zefram]

Bart Schaefer wrote:
>However, now that I think of it, globbing order is already going to be
>altered by LC_COLLATE, so scripts that rely on it are out of luck in
>the first place.

Erk.  I hope that's not POSIX.  I think we should probably remove that,
just as we removed it from character ranges, and for exactly the same
reason that we want NUMERIC_GLOB_SORT to be reset by emulation.

Fundamentally, I view globbing as a programming feature, which should
be utterly unaffected by locale.  Same for string comparisons in [[]].
I think we do want a locale-dependent string comparison operation, but
its use is very much the exception, not the rule.  Pattern matching and
string comparisons are used on all sorts of strings, and only very rarely
on natural-language text.

Exactly the same argument applies to numeric syntax; the use of "." as
the decimal point is part of the language syntax, and should not be
locale-dependent.  A builtin that could take a number in standard syntax
and render it in locale-dependent syntax would be nice.[1]

If use of LC_COLLATE in globbing is POSIX (and maybe even if it's not),
we could reasonably make that another option, which would itself be
affected by emulate (and I'd argue that it should be off by default in
all current emulation modes).

-zefram

[1] That reminds me, one of the things I never got round to implementing
as a builtin was the POSIX "printf" utility.  The advantage of having
it as a builtin is that we could then use the same code for a "sprintf"
builtin, which would put the result into a shell variable instead of
sending it to standard output, which is a feature I often miss.