Harald van Dijk posted on Wed, 09 Jun 2010 21:21:44 +0200 as excerpted:
> Firstly, don't use == with test. It's not portable. The bash built-in
> test supports ==. Other test implementations don't, such as the one from
> GNU coreutils, and the built-in test in other shells, don't. If you use
> test in a context where you're absolutely sure the built-in version will
> be used, and the executing shell is bash, then I suppose you can use ==,
> but at that point you're better off using [[ ]] anyway.
Good point about [[ ]].
> That said, to test if a variable is set, use ${VAR+set} over
> ${VAR-unset}. ${VAR-unset} evaluates to "unset" if VAR is unset, and if
> VAR is set to the string "unset". I suppose that's why you used %UNSET%,
> to reduce the possibility of accidents. You can reduce it to 0, using
> for example
>
> if [[ -z ${LINGUAS+set} ]]; then
> # LINGUAS is unset
> fi
While we're talking style, a question (well, a couple):
I've seen code like that posted frequently, but always wonder why the -z
is even used at all. Also, why use the if/then form? Is that Gentoo
style guidelines (like always using the brace-var form apparently is,
${LINGUAS} vs. $LINGUAS)? Why not simply (: instead of # to avoid an
empty subshell):
[[ ${LINGUAS} ]] || {
: LINGUAS is unset
}
>> If yes, it's easy to write such code and put in eclass. If no, how do
>> we live with inconsistency that some packages will install all
>> languages some, will install nothing (document in handbook and add
>> portage warning in case LINGUAS is unset?)?
>
> Unfortunately, consistency either way is bad. Making unset LINGUAS
> install nothing changes gettext's design, when the whole idea behind
> LINGUAS was to mimic gettext's design. Making unset LINGUAS install
> everything causes massive disk space requirements for the default
> settings for some packages such as openoffice. In my opinion, either of
> those would be worse than having LINGUAS behave inconsistently.
++
>> 3. What is the purpose of strip-linguas function
> It's used for some packages that fail to build with certain LINGUAS
> values. If I recall correctly, binutils had a bug where putting en_GB in
> your LINGUAS made the build fail, for example. binutils doesn't support
> en_GB anyway, so it gets filtered out,
Here's a simple question I've wondered for awhile, not documented anywhere
I could find, but should be.
What do those of us who only speak English (whatever form, US is fine) put
in LINGUAS, to ensure no "extras" we can't use anyway get installed?
Currently, I have in one of my make.conf include files: LINGUAS="en",
hoping to avoid the "everything installed" scenario above. But then on
binutils, I get the message "en" is not supported, which is fine, it
works, but with it stripped, does that mean it's installing unnecessary
language stuff that's of no use to me anyway? Should it be "en_US" or
"en_US.UTF-8" instead? Or maybe it should be simply "C"?
A line or two in the l10n guide, plus possibly the handbook, telling what
to set if "plain English" is "plain OK" to avoid the "unset installs it
all" problem, would be useful.
And if there is no such single value available presently, as looks likely,
how big a project would it be to add it? Or perhaps an alternate
approach, a table of packages and the setting to be added to a file in
/etc/portage/env (or whatever), would be more appropriate? I haven't a
clue on this. Perhaps all I need is pointed at the right documentation,
but if so, that "right documentation" should probably be a bit more
visible, as I've certainly looked.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
