[GRASS-dev] Re: [bug #4905] (grass) gis.m: d.text.freetype does not allow spaces in text

[Glynn Clements]

Moritz Lennert wrote:

> >>> There are two separate issues. gis.m has previously had problems with
> >>> arguments containing spaces, but there have been some fixes in that
> >>> area. If you come across this problem in the current CVS version, file
> >>> a bug report.
> >> That is what this bug report is actually about (what I call the "gis.m 
> >> part of the bug") and it is still open as of CVS-head from yesterday.
> > 
> > So the gis.m bug is still present? I.e. you can't include spaces in
> > the text?
> 
> Yes, unless I use the curly braces solution you suggested, i.e.:
> 
> d.text.freetype -n {text=Population totale} ...
> 
> Just to make sure we understand each other: this is when adding the 
> d.text.freetype command as a command layer to gis.m (I don't know of 
> another way...).

Right. If you are using a command layer, then you need to use braces
for any arguments which contain spaces. More precisely, the string for
a command layer needs to be a well-formed Tcl list, where each item in
the list constitutes a single argument. Using a backslash should also
work, i.e.:

	d.text.freetype -n text=Population\ totale ...

That isn't a bug; if you want to represent a list of strings (e.g. a
command) as a single string (i.e. the contents of a text field), and
you want list items to be able to contain the item separator, you
inevitably need some syntax to distinguish between use of the
separator as a separator and its use as a literal character.

With the Bourne shell, you need to use quotes; with Tcl, it's braces.

BTW, if an argument contains an unmatched brace, you have to use
backslashes, e.g.:

	d.text.freetype -n text=this:\ \{\ is\ a\ brace ...

as there's no way to include an unmatched brace in a brace-delimited
string.

-- 
Glynn Clements <glynn at gclements.plus.com>