Date: Fri, 17 May 2024 10:20:57 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <ad885f6b-de1f-49be-af0d-897adff2b...@case.edu>
| If you set the variable to something that needs it, you have to accept
| the stat overhead -- otherwise, how could it do what you've requested?
Of course, I understand that, I'm just not sure about the average user
who might start complaining about how slow the shell has become when
expanding glob patterns. (There's also going to be some memory overhead,
as once you have stat'd the file once, you'd want to remember the value
of interest along with the name, or you'd have way too many stat() calls
if that was repeated for every comparison done by the sort algorithm).
| If `nosort' means no sorting, there is no imposed ordering, and ascending
| and descending are meaningless.
Sure, but directory order, and reverse directory order aren't (and that's
just a difference between the order in which you create the list as each
new dirent is read from the directory - does it go at the head or tail).
But in any case, it apparently isn't documented, if +nosort and -nosort
are to mean the same thing, then it should say so. Another possibility
(apart from reverse directory order, which I agree doesn't seem useful)
would be for "-nosort" to either be an error, or just be ignored, leading
to "names").
| I'll consider it. What name would you propose for it?
Now that's the difficult question, I hate inventing names for
things - perhaps "number" or "numeric" or "numname" or ...
(but for something like this, what string to use makes no difference
at all really, they could be s0 s1 s2 s3 ... and it would work
equally well - just slightly harder to remember which one to use).
All that matters is that it fall back to be "names" if the filenames are
not numeric (or at least if they don't start with digits, so atoi()
would just return 0), fully numeric names are the only ones that matter
to me.
| Because it's a complication that may or may not be worth implementing
| without some critical mass of people asking for it. Let's see how this
| goes first.
The doc also doesn't indicate what happens when the sort method chosen
produces equal answers - that can't happen for names, since the same name
can't occur twice in the same directory, but for everything else that's
in the list it can. Does it then sort by name, by directory order, or
just by whatever order the sort algorithm (qsort?) happens to leave them
in when it is done?
If you want common implementations of this, so it could eventually be
standardised, then all these kinds of details need to be made very precise
(even though your average man page reader probably wouldn't care.)
Actually, one more option that might be worth adding (as a sort type)
might be "random" - giving different results every time the same pattern
is expanded. That might be useful to help shake out bugs in some code.
(and no, I have no idea what -random would mean.) You'd just run a PRNG
to supply the sort key, where for the others you extract data from stat().
kre
