I found that names of enviroment variables set in g.parser
are converted in execlp(?) to uppercase.
Consequently variable GIS_OPT_input for example is not defined
and script fails. The name of variable was converted to GIS_OPT_INPUT.
Any ideas how to resolve this?
Radim
Radim Blazek wrote:
I found that names of enviroment variables set in g.parser
are converted in execlp(?) to uppercase.
Consequently variable GIS_OPT_input for example is not defined
and script fails. The name of variable was converted to GIS_OPT_INPUT.Any ideas how to resolve this?
This appears to be done by both Cygwin and the MSys version of bash.
Windows itself preserves the case of environment variables (although
lookups are case-insensitive).
I have no idea how to resolve this, other than changing both g.parser
and all of the scripts which use it.
It might be worth checking whether the Korn shell from Microsoft's
Services for Unix exhibits the same behaviour.
--
Glynn Clements <glynn@gclements.plus.com>
On 3/30/06, Glynn Clements <glynn@gclements.plus.com> wrote:
Radim Blazek wrote:
> I found that names of enviroment variables set in g.parser
> are converted in execlp(?) to uppercase.
> Consequently variable GIS_OPT_input for example is not defined
> and script fails. The name of variable was converted to GIS_OPT_INPUT.
>
> Any ideas how to resolve this?This appears to be done by both Cygwin and the MSys version of bash.
Windows itself preserves the case of environment variables (although
lookups are case-insensitive).I have no idea how to resolve this, other than changing both g.parser
and all of the scripts which use it.
OK, I'll change the parser to set both GIS_OPT_xxxxx and GIS_OPT_XXXXX
and scripts in CVS to use GIS_OPT_XXXXX.
That means users' scripts will continue to work on Linux/Mac
and scripts included in standard distribution will also work on Windows.
Radim
It might be worth checking whether the Korn shell from Microsoft's
Services for Unix exhibits the same behaviour.--
Glynn Clements <glynn@gclements.plus.com>