[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnulib-tool-py] List of available modules
From: |
Bruno Haible |
Subject: |
Re: [gnulib-tool-py] List of available modules |
Date: |
Wed, 09 May 2012 00:02:23 +0200 |
User-agent: |
KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; ) |
Hi Dmitriy,
> I could do it in this way:
> 0. Create empty list to store strings.
> 1. Make recursive cycle using os.walk.
> 2. For every string:
> 2a. Don't append string if it is a directory;
> 2b. Don't append string if it is a special filename.
> 3. Sort list using list.sort() method
Yes, that sounds like an appropriate translation of a 'find' command to
pure Python.
> I could do it in the way described above, but it takes too much time to
> complete.
Yes, if you think it side-tracks you for too long, just leave the 'find'
invocation in place. I appreciate that you are keeping an eye on the time.
> So I think the best way is to do this:
> 1. Run subprocess `find modules -type f -print` and get output.
> 2. Send stdout to sed command with some arguments
> (func_sanitize_modulelist), then get output.
> 3. Split output by lines, then sort it
Yes. Of course don't forget the two other details that are in the
func_all_modules() code:
- If the --local-dir option was given, traverse it in the same way,
eliminating all files whose name matches '*.diff'.
- Eliminate all tests modules.
> BTW, why we set `LC_ALL=C` before we run `sort -u`? Is it necessary to use
> exactly C locale?
There is pro and cons:
* Pro current locale:
- Internationalization advocates want that every list that is sorted
and then output, wherever that is, be sorted according to the current
locale. The user can control this locale by setting the various
LC_* environment variables (LC_COLLATE for the sorting, LC_MESSAGES
for the error messages).
* Pro "C" locale:
- gnulib-tool's output is often used by other build tools. It is good
to have different people, in different locales, get the same result
from the same command, because that makes reproducing bug reports
easier.
For example, when I run 'makeinfo', I have to remember to always
use "LC_ALL=C" for English manuals, otherwise 'makeinfo' will insert
German navigation commands into an English manual.
- In my German locale, the sorting order ignores punctuation like dashes.
But for filenames I don't find that 'str-foo' should sort like 'strfoo'.
In other words, the entities being sorted are English abbreviations
or combinations of English words; it is odd to apply a German sorting
order to it.
IMO for build tools a good compromise is to internationalize error messages
and plain text, but leave the output that will be consumed by machines
locale independent (i.e. formatted for the "C" locale).
In summary, I let you decide.
Bruno