On 8/23/26 8:04 PM, Zachary Santer wrote:
given the current locale's collation order.I'm actually struggling to find where the devel branch's doc/bash.1 bothers to say that the expansion of indexed arrays subscripted by @ or * is in numerical order of indices and the expansion of associative arrays subscripted by @ or * is in arbitrary order.
It doesn't specify expansion order at all. It makes the most sense to expand indexed arrays in ascending order of indices, to sort of mirror C arrays. It doesn't make sense to impose some kind of ordering on associative arrays, which are essentially dicts/hash tables.
When expansion order matters at all, this is liable to be what the
shell programmer would prefer. ${!assoc[@]} expanding in lexicographic
order would make for a slight improvement in one of my scripts, at
least.
This is not a feature that has been in great demand (or any demand, really), especially not sorting in lexicographic order for keys. If you want to wait for the next devel branch push, I added a -I option to the `asort' loadable builtin to sort an associative array by keys and assign those keys in order to an indexed array. (The existing -i option is like awk's asorti, which sorts by values and then assigns the keys, so it was only a small change.) See if that does what you want without any other changes.
I can't imagine a scenario where a script would depend upon an associative array expanding in not necessarily a sorted order, butthis functionality could be controlled by a shopt option.
I think if such a feature were to be implemented, it would be better to implement it as a parameter transformation. When you need it, you get it.
Maybe it would save a few clock cycles if the programmer doesn't care. On the other hand, how would bash handle this shopt option being enabled after associative arrays have already been assigned to?
I don't think a shopt option is the way to go, but why would it matter? You only want an expansion, right? So you get a sorted expansion, where the ordering is whatever the current locale says it is at expansion time.
So that linked list would have to be maintained throughout the lifetime of the indexed array. The same would go for associative arrays with keys sorted.
You don't have to change the underlying data structure, nor do you have to keep keys (or values) sorted.
Some locales weight different strings equally, so that would add another little wrinkle. Elements with indices with equal lexicographic weight could be placed in arbitrary order, relative to each other. The shell programmer could always set LC_COLLATE to C.UTF-8 if it matters that much to them.
C.UTF-8 isn't valid everywhere, so you're already making assumptions. But
this also doesn't matter, or at least is easy to deal with, since a qsort
string comparison function using strcoll(3) hides all that and lets the
locale determine the order.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
