[GRASS-dev] g.region print flags combination

[Glynn Clements]

Michael Barton wrote:

> 5. There should be no spaces or other extraneous characters between
> [key][separator][value], or at the end or beginning of this string.

However, there may be cases where the [value] can contain spaces or
other "awkward" characters.

We need to decide what, if any, processing should be performed in such
cases; if so, it should be done consistently by all relevant modules.

If you're targeting the shell's "eval", the easiest solution is to add
quotes, e.g.:

	string='this is a string'

or backslash characters, e.g.:

	string=this\ is\ a\ string

but that makes it harder for other languages.

In general, the easiest format would be to prohibit newlines and take
as the value everything from the character immediately following the
separator to the end of the line, so:

	string= this is a string

would have the value " this is a string" (with a leading space). That
can't be parsed by "eval", although it can be parsed by just about
anything having regexp or pattern operations, e.g.:

	$ foo="string= this is a string"
	$ echo "$foo"
	string= this is a string
	$ echo "${foo%%=*}"		# key
	string
	$ echo "${foo#*=}"		# value
	 this is a string

Note the use of one # but two % to handle the case where the value
contains the separator:

	$ foo="string= this is a = string"
	$ echo "$foo"
	string= this is a = string
	$ echo "${foo%%=*}"		# key (correct)
	string
	$ echo "${foo%=*}"		# key (removes too little)
	string= this is a 
	$ echo "${foo#*=}"		# value (correct)
	 this is a = string
	$ echo "${foo##*=}"		# value (removes too much)
	 string

> 6. There should be no warnings or other extraneous text printed with
> 'script' format. The assumption is that script format is not designed for
> humans to read (although they certainly can, of course). If it fails for
> some reason, it should get the standard error message. for that command. I
> would strongly suggest getting rid of the warnings in script format for
> g.region.

Scripts should be parsing stdout, not stderr. Modules can write
whatever they wish to stderr; it's gis.m's job to allow for the
possibility of warnings.

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