zsh-workers
 help / color / mirror / code / Atom feed
* Re: Emulation and NUMERIC_GLOB_SORT
@ 1999-11-11 11:35 Sven Wischnowsky
  1999-11-11 11:42 ` Zefram
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 1999-11-11 11:35 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Emulation and NUMERIC_GLOB_SORT
  1999-11-11 11:35 Emulation and NUMERIC_GLOB_SORT Sven Wischnowsky
@ 1999-11-11 11:42 ` Zefram
  0 siblings, 0 replies; 4+ messages in thread
From: Zefram @ 1999-11-11 11:42 UTC (permalink / raw)
  To: Sven Wischnowsky; +Cc: zsh-workers

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Emulation and NUMERIC_GLOB_SORT
  1999-11-11 10:25 Bart Schaefer
@ 1999-11-11 11:01 ` Zefram
  0 siblings, 0 replies; 4+ messages in thread
From: Zefram @ 1999-11-11 11:01 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Emulation and NUMERIC_GLOB_SORT
@ 1999-11-11 10:25 Bart Schaefer
  1999-11-11 11:01 ` Zefram
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 1999-11-11 10:25 UTC (permalink / raw)
  To: zsh-workers

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1999-11-11 11:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-11 11:35 Emulation and NUMERIC_GLOB_SORT Sven Wischnowsky
1999-11-11 11:42 ` Zefram
  -- strict thread matches above, loose matches on Subject: below --
1999-11-11 10:25 Bart Schaefer
1999-11-11 11:01 ` Zefram

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).