[GRASS-dev] Re: [GRASS GIS] #32: r.what: shouldn't use static buffers for the inputs

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>>> I did it as %c like r.cats, other modules are more liberal and
 >>>> allow %s.  Shrug.

 >>> I have no use for %s just now, but there should probably be a
 >>> GRASS-wide policy on using either %c or %s for `fs'.  (In order for
 >>> the user to learn this exactly once.)

 >> Since the function above allows strings, I'd opt for allowing a
 >> string for `sep' everywhere.

	s/sep/fs/

 > When a string is used as a separator, the behaviour isn't entirely
 > obvious. If the string is passed as the separator argument to
 > G_tokenize(), it treats the string as a set of characters, all of
 > which are treated as separators.

	I should have been more specific.  I had in mind the /output/
	field separator option only.

 > For a module to provide this behaviour, it would be more natural to
 > use e.g. "opt.sep->multiple = YES" and require the individual values
 > to be single characters (after any parsing of backslash sequences).

	It may make sense.

	Alternatively, it may be suggested to follow the Awk approach
	and allow a regular expression as an input field separator.  (It
	looks like that Gnulib contains an RE matching module.)