After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 559528 - Cannot restrict language install using LINGUAS/ALL_LINGUAS
Cannot restrict language install using LINGUAS/ALL_LINGUAS
Status: RESOLVED FIXED
Product: intltool
Classification: Deprecated
Component: general
0.40.x
Other Solaris
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
Depends on:
Blocks:
 
 
Reported: 2008-11-05 22:48 UTC by Eric Lamarque
Modified: 2009-04-08 17:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
escape ^ character in grep expression (1000 bytes, patch)
2008-11-05 22:51 UTC, Eric Lamarque
rejected Details | Review
Fix quotations in Makefile.in.in (1.06 KB, patch)
2009-04-08 10:18 UTC, Peter Hjalmarsson
none Details | Review
Same as above, but with all quotes fixed. (1.06 KB, patch)
2009-04-08 10:51 UTC, Peter Hjalmarsson
rejected Details | Review

Description Eric Lamarque 2008-11-05 22:48:55 UTC
Please describe the problem:
Trying to restrict language installation does not work on Solaris if shell is a real sh (no bash nor tcsh)

Steps to reproduce:
1. export LINGUAS="en fr" ALL_LINGUAS="en fr"
2. ./configure
3. make


Actual results:
The following traces appears

Making all in po
Usage: grep -hblcnsviw pattern file . . .
/bin/sh: en$: not found
Usage: grep -hblcnsviw pattern file . . .
/bin/sh: fr$: not found 
[...]

Expected results:
build only fr and en messages files

Does this happen every time?
yes

Other information:
Here is the root cause :
with bash/tcsh

> echo foo\^bar
foo^bar
> echo foo^bar
foo^bar 

with old sh - in fact '^' is or exclusive operator
$ echo foo\^bar
foo^bar
$ echo foo^bar
bar: not found
Comment 1 Eric Lamarque 2008-11-05 22:51:41 UTC
Created attachment 122064 [details] [review]
escape ^ character in grep expression
Comment 2 Sven Neumann 2008-11-06 08:34:17 UTC
Reassigning to intltool. I don't see any point in fixing this in GIMP when the actual file is pulled in from another package.

And intltool will probably reassign it to gettext ...
Comment 3 Rodney Dawes 2008-11-17 13:42:06 UTC
I'm rejecting this patch, because it was made against gimp, not intltool, and because we prefer to use quoting over \ for escaping here. I have committed a fix to SVN though. Thanks for the report.
Comment 4 Peter Hjalmarsson 2009-04-08 10:18:15 UTC
Created attachment 132319 [details] [review]
Fix quotations in Makefile.in.in

The 'fix' for this bug broke other things (bug 577133).

I propose the following fix for these two bugs, and am attaching it here hoping Eric could try if this work on Solaris also (tried it on Gentoo linux using bash 4.0).
Comment 5 Peter Hjalmarsson 2009-04-08 10:51:44 UTC
Created attachment 132324 [details] [review]
Same as above, but with all quotes fixed.
Comment 6 Peter Hjalmarsson 2009-04-08 16:19:31 UTC
Ok, that was flawed, and did not work as it should.

But can someone please tell me why the '^' is there to begin with? Removing it and it works still nice (at least with bash/gnu make) and I cannot find any references to what it is supposed to do.
Comment 7 Rodney Dawes 2009-04-08 17:23:33 UTC
(In reply to comment #6)
> Ok, that was flawed, and did not work as it should.
> 
> But can someone please tell me why the '^' is there to begin with? Removing it
> and it works still nice (at least with bash/gnu make) and I cannot find any
> references to what it is supposed to do.
> 

It is there to provide an increased level of strictness when matching locales. Without it, both "en_US" and "leet-en_US" would match when you only want "en_US" for example.

Also, unless you intend to reopen this bug, please discuss the issues in bug #577133 and not in this report, as it remains RESOLVED FIXED.