GNOME Bugzilla – Bug 152448
intltool doesn't expand shell escapes in GETTEXT_PACKAGE
Last modified: 2004-12-22 21:47:04 UTC
Discussion starts at http://lists.gnome.org/archives/gnome-i18n/2004-August/msg00289.html Rodney gives the reasoning here: http://lists.gnome.org/archives/gnome-i18n/2004-August/msg00292.html I'll attach a patch which fixes this in the following way: 1. turns file-existency test into "test -f" backticks-command, so module name would get expanded there as well 2. turns system("msgmerge ...") call into "print `msgmerge ...`" (to make use of shell-expansion as well)
Created attachment 31514 [details] [review] Use shell-escaping for module name everywhere (patch is against intltool-update; it should, of course, be commited against intltool-update.in) 2004-09-12 Danilo Šegan <dsegan@gmx.net> * intltool-update.in (GeneratePOTemplate): die() when cannot open file for writing. (POFile_Update): Test for file using `test -f`; use `msgmerge` instead of system() call.
Looks good. Don't know if we should add a comment or not.
It sounds as a good idea to add a comment. Rodney was talking about giving this issue another look, so perhaps he'll come up with entirely different solution.
I would like to fix it for all variables, since we parse them all, and any one may be referenced by another that we actually use. But given the majority of cases, this patch looks ok. Danilo, can you please comment the code and commit the patch? Thanks.
Created attachment 31909 [details] [review] Expand shell escapes in all variables Rodney, how about this one? (it uses the same idea on all variables, and the change is even simpler: two other changes are unrelated simple bugfixes) 2004-09-24 Danilo Šegan <dsegan@gmx.net> * intltool-update.in.in (GeneratePOTemplate): Bork out if we cannot write POTFILES.in.temp. * intltool-update.in.in (SubstituteVariable): Fix typo in re: s/$1)/$1/ (variables with quotes got ")" attached previously); use shell escaping (`echo -n "$str"`).
Created attachment 31911 [details] [review] Expand shell escapes (now with comment) Same patch with comment about why we do it this way
Please commit and add an entry to NEWS above the one I just added for another bug.
Ok, committed to HEAD along with NEWS entry for this bug (other fixes are not documented in NEWS, since I don't think we should replicate entire ChangeLog in there). Marking as RESOLVED/FIXED as well.