Salix OS

Hi. I just discovered on another distro that the 'ls' command, by default, produces a listing in which all entries are sorted alphabetically without regard to case, and with the leading '.' in each name ignored. I found that the '-v' option would produce the same listing which I get in Salix by default.

But, I can find no way in Salix to produce the listing seen in the other distro. It is as if the 'ls' command in Salix has the '-v' option turned on by default, but I could find no configuration file that does so.

The version of Bash in Salix is 5.1.016-x86_64-1, while the Bash version in the other distro is 5.2.15-2+b2, so is newer. Is this the reason why 'ls' in Salix cannot produce that listing? But if so, then why does the '-v' option exist (and appears to do nothing)?

Try the following in a terminal window:

export LS_OPTIONS=" -F -b -T 0 -l -a -h --group-directories-first --color=auto"

Then try the ls command.

If that provides a more helpful ls command then welcome to the rabbit hole of customizing the command.

This is working here
alias ls='ls -F -b -T 0 -l -a -h --group-directories-first --color=auto'
then type ls
or
alias='ls --color=auto'
or whatever you like to set.
You can add the line to ~/.bashrc file
and then type type or to see the output.

Thanks to both for the replies. I already had in ~/.bashrc, and aliases for '-l' and '-A', so I added '-h' to the options, but unfortunately that did not change the listing order.

So I tried just using on the command line, and again the order was not changed. Probably I didn't explain very well in the original post. The listing I'm seeing in the other distro looks something like this: so you can see that upper/lower case are mixed, and name and dot-name are mixed. But I haven't found any way to produce that listing in Salix. I wonder whether it has to do with the newer version of Bash?

Try adding the -f option

Thanks, but -f simply lists in the order of occurrence in the directory, which is completely random as far as any sorting criteria are concerned.

Doing some searching, I think it may have to do with some shell options (shopt) like globbing. But no matter which options I change, the ls listing never changes. Hmm... any thoughts

So, I found the answer to the original question. The difference between the two distros was one of the locale settings.

In Salix, LC_COLLATE=C was set, while in the other distro it was LC_COLLATE="en_US.UTF-8". Changing Salix to LC_COLLATE=en_US.utf8 (to match the other LC_ variables in Salix; it would seem that case and hyphen do not matter [.utf8 vs .UTF-8]) produced the other listing in question.

That still doesn't answer why none of the shopt options has any effect in a straight directory listing. Perhaps those (globbing) options only apply when using wildcards?

So, the collating order was still not what I desired it to be, which is:
1. to have directories listed first, then files (this is simply an 'ls' option)
2. within each of those two groups (directories/files) to have .dot files listed first, then non-dot files
3. to have each of those groups be case-insensitive (Aa before Bb before Cc, etc.)
4. within each case-insensitive group, to have upper-case before lower-case.

The only way I found to change that, was to modify the collating sequence for the locale being used. To do this, I copied the en_CA locale and modified it to change several settings, such as date format.

In order to change the collating sequence, I simply copied the LC_COLLATE section from the C locale to my custom locale (this is simply the first 127 characters in ASCII order, one per line), and then moved each lower-case letter (<U00061>, etc.) line, to a position directly below its upper-case equivalent (<U00041>, etc.) line. I then compiled the locale, and to test, I set the LC_COLLATE environment variable to the new, custom locale. Several test 'ls' listings showed the result to be as described above.

This is a simple brute-force approach that works for me on my system, but doesn't take into account the order of other non-alphanumeric characters, nor does it take into account any characters beyond the ASCII character set (the locale should, at a minimum, handle UTF-8)!

It would be appreciated if some Linux guru could point me to some resources where I could learn how to properly create such a collating sequence, and also to some instructions on how to configure the system to permanently use the new locale, either per-user or system-wide (right now, it is only temporary).

As for the last part, you can edit your /etc/profile.d/lang.sh. As long as you don't run (gtk)localesetup to reconfigure those, it won't change.