[Bug 2165] Sort the BSP lists in acinclude.m4 files.

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=2165

--- Comment #1 from Ralf Corsepius <ralf.corsepius at rtems.org> 2014-01-08 00:39:58 CST ---
(In reply to comment #0)
> This patch sorts the bsp lists in the acinclude.m4 to avoid conflicts if the
> file system orders the directories differently to the checked in file.

I think this proposal is insufficient and doesn't fix the issue it tries to
address. Why?

The order of the results returned by "ls" is implementation dependent. On some
(older) OSes, it is "filesystem (inode)-order", on some OSes it is
i18n-ordered, some OS it might "alpha-sorted".

Similarly for "sort": On some (older) OSes the results are "alpha-sorted", on
some OSes they are i18n-ordered.

On modern Linuxes, the results of ls and sort are both i18n sorted:

Example:
# export LANG=C
# ls
1  A  a
# ls | sort
1
A
a

# export LANG=en_US.utf_8
# ls
1  a  A
# ls | sort
1
a
A

# export LANG=en_US.utf_8
# export LC_COLLATE=C
# ls
1  A  a
# ls | sort
1
A
a


I.e. as far as Linux is concerned, piping through sort doesn't help.
Instead, unsetting/overriding LANG, LC_COLLATE and may-be other
i18n-environment variables would be required.

So, which OS are you having problems with?
How do the results of the examples above look like on this OS.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.