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