Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15738 > unrolled thread
| Started by | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| First post | 2019-12-16 11:39 -0500 |
| Last post | 2019-12-16 11:39 -0500 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: unquoted expansion not working (was Re: Not missing, but very hard to see) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-12-16 11:39 -0500
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-12-16 11:39 -0500 |
| Subject | Re: unquoted expansion not working (was Re: Not missing, but very hard to see) |
| Message-ID | <mailman.978.1576514378.1979.bug-bash@gnu.org> |
On Sat, Dec 14, 2019 at 02:48:16AM -0800, L A Walsh wrote: > On 2019/12/13 10:42, Greg Wooledge wrote: > > There's a larger issue to be addressed first. The man page says, > > [...] > > sary. When characters are supplied, the expression expands to each > > character lexicographically between x and y, inclusive, using the de‐ > > fault C locale. > ---- > If it says letters that lends stronger support to including > unicode ranges of letters and numbers since the shell handles unicode and > brace expansions with unicode filenames works just fine. That ranges don't > seems a bit of a wart. No, it won't include Unicode, because it very clearly says "C locale" right up there. The problem is, it is *not possible* to extract the set of characters out of an arbitrary locale. The locale interfaces simply are not built to allow it. You can do it in the C locale, simply because the C locale is a known, fixed quantity that you can hard-code. You can't do it in any other locale.
Back to top | Article view | gnu.bash.bug
csiph-web