GNOME Bugzilla – Bug 338423
intltool should support po/LINGUAS string spanning multiple lines
Last modified: 2006-04-20 11:37:09 UTC
Not sure if this is a new regression or have been there for a long time, but just recently many modules started breaking with unterminated 's' command sed error. Probably because the same translator started adding translations to all those modules. Anyway, would be nice to handle it.
*** Bug 338414 has been marked as a duplicate of this bug. ***
Just confirmed it happens with intltool from CVS only.
*** Bug 338318 has been marked as a duplicate of this bug. ***
*** Bug 338415 has been marked as a duplicate of this bug. ***
many have seen this. confirming report.
*** Bug 338416 has been marked as a duplicate of this bug. ***
This is actually an issue with autoconf and/or sed, and not intltool. All the new intltool does differently at configure-time is that it calls AC_SUBST(ALL_LINGUAS), so that the resulting po/Makefile can use the values provided there, rather than in po/LINGUAS, in the event that ALL_LINGUAS is still being used. Any variable which contains newlines within a quoted string, that is subsequently AC_SUBST()ed, should cause this. The macros in intltool.m4 do not do any direct manipulation of the ALL_LINGUAS variable.
It's not only with ALL_LINGUAS, it's happening with po/LINGUAS too. I think they should be both handled.
Is the problem that both exist, i.e. that the original instructions for the Gnome Goal should be considered wrong and thus all the accepted patches are what broke things?
Oh, that's possible, right. The modules I see were broken all were reading po/LINGUAS in configure. So maybe just proceeding with the new instructions is enough.
OK. So, here's the thing. The configure.{ac,in} file is not a special data file like an XML description of things, or anything. It is a shell script. And you cannot use multi-line values for variables without escaping the newline. I can handle this for po/LINGUAS, as it is a data file that gets read in. I cannot change how bash interprets the configure script though. If you want to use newlines in variables in configure.{in,ac} or Makefiles, you must escape the newline with the \ character, just as is done for foo_SOURCES and other variables. I'm updating the summary to reflect the problem in po/LINGUAS, but the ALL_LINGUAS issue needs to be fixed properly in the applications, or by converting to po/LINGUAS, and dropping the use of ALL_LINGUAS completely. I'll fix the po/LINGUAS part later today.
I don't think it's that hard to fix dobey. All you need to do is to remove the newlines (convert to spaces) from ALL_LINGUAS before AC_SUBSTing it. Not sure what the portable way to do that is, but tr '\n' ' ' works for example.
AC_SUBST is not an intltool macro. And ALL_LINGUAS is NOT the only variable where this problem could occur. The correct way would be to s/$/\\/ on the variable, assuming the whole variable actually gets read in and is available to whatever does that. If that is what needs to be done, it needs to be done in autoconf, not in intltool. However, I presume that the autoconf hackers will tell you that you need to write proper shell in your configure script, as it is a shell script. I don't remember if I made it prefer the ALL_LINGUAS or po/LINGUAS method in Makefile.in.in. I'll look at it later, when I fix the handling of newlines in po/LINGUAS, and test a few more things, to make sure we at least avoid this situation.
If it's that you just don't want to fix it, I would be happy to just hear that. If you are willing to fix but don't know how, I will be happy to submit a patch, but what you wrote doesn't make much sense to me. I perfectly know how shell script, autoconf, and m4 works, and FWIW shell variables with newlines are perfectly valid. Intltool can very easily remove newlines from ALL_LINGUAS before passing it to AC_SUBST. Yes, you can do that even though AC_SUBST is not an intltool macro. I just cannot imagine how that can even matter...
It's not that I want to fix it or don't know how. However, I am not going to put a hack into intltool to workaround a problem that exists in far more potential situations than just the use of ALL_LINGUAS. If I create some other variable, that contains newlines, and I need to AC_SUBST() it, so that I may use it in a Makefile, where should I point the blame for that, when it causes the exact same problem you are stating here? Putting a workaround in intltool for this one case isn't fixing the problem, it's fixing a symptom, and I won't do that.
OK, So, intltool works fine already with po/LINGUAS having each locale on a separate line. The applications that the recently committed changes expose this issue with the sed failure in, need to be fixed properly. What is to prevent this occuring by some other means than AC_SUBST(ALL_LINGUAS) in thos applications? The only way you are going to be able to fix this, is to fix autoconf to properly handle newlines in the substitution of variables which get passed to sed. The script pasted below, will also exhibit this error. The sed program does not handle straight newlines in substitutions. So, I am marking this as NOTGNOME and refusing to workaround bad code by trying to automatically fix it. Please fix the applications properly. ----------------------------- #!/bin/sh FOO="BAR BAZ" echo "FOO = @FOO@" | sed -e "s/\@FOO\@/${FOO}/"
*** Bug 339130 has been marked as a duplicate of this bug. ***