Re: feature proposal: expand associative arrays in lexicographic order of keys

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, but
> this 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/

-----BEGIN PGP SIGNATURE-----

wmMEABEIACMWIQR8ATX7CIqvbGbGULm7WGnwZOp0qwUCaoyw4QUDAAAAAAAKCRC7WGnwZOp0q9JY
AJ90HE+FJZHVXoh+AToRYaRpmIgyHQCgi1GRN+kgLRmyS9qlKOV/Niz6g/M=
=dqr3
-----END PGP SIGNATURE-----