[GRASS5] 5.0.2 trashes .grassrc5

[Glynn Clements]

Markus Neteler wrote:

> > I don't understand exactly what was intended in the general case
> > (changing $1 to $ARGS), but it's clear that this specific case is
> > wrong: in the "awk" commands, "$1" is an awk variable, not a shell
> > variable, so it shouldn't have been changed.
> > 
> > I'll fix the specific awk problem myself.
> > 
> > Regarding the more general changes, I'd appreciate it if Markus could
> > provide some insight into the motivation behind changing $1 to $ARGS.
> 
> AFAIK this change should not affect 5.0.2 as it was done in HEAD only.
> 
> $ARGS is set in line 49. Probably I have chosen a reserved word?
> So far it worked for me/us on Linux.

AFAICT, awk interprets $ARGS as $(ARGS); as the variable ARGS is
undefined (in awk), this is equivalent to $(). It appears that your
version of awk treats that as equivalent to $0 (the entire line),
while Chris' version treats it as a syntax error.

The point is that the $1 in the literal string which is passed to awk
is an awk field reference, not a shell variable (whereas all of the
other occurrences of $1 in the script are shell variables), and
shouldn't have been changed.

> The underlying idea is white space support as the CVS comment states.
> In case of white space the calling script which starts GRASS is
> sending several parameters to Init.sh, that's why $ARGS is constructed
> in line 49.

I see what you are trying to do, but it's the wrong approach. The
grass5 script itself needs to be changed to preserve argument
boundaries, e.g.

	exec "$GISBASE/etc/Init.sh" "$GRASS_GUI" "$@"

Actually, the grass5 script should be reduced to just:

	#!/bin/sh
	GISBASE=...
	export GISBASE
	exec "$GISBASE/etc/Init.sh" "$@"

with everything else moved into Init.sh. That will work for every
possible combination of arguments, even those which include embedded
spaces, newlines, quotes etc.

The key point in the above is that the expression "$@" evaluates to
the list of command-line arguments, with argument boundaries
preserved. This is handled as a special-case; there is no way to
obtain the same effect with ordinary variables. This feature exists
precisely to solve this particular problem.

Aside: the Bourne shell's biggest drawback as a general-purpose
programming language is that there is no reliable way to implement
lists. All variables are strings; if you try to represent a list as a
string, with the elements separated by a separator character, it fails
if one of the elements actually contains the separator character.

-- 
Glynn Clements <glynn.clements at virgin.net>