[GRASS-dev] Re: [GRASS-user] 6.4 vs 7.0

[moving this to -dev]

Glynn wrote:

That's not good for the GUI, where the module won't have a
stdin (ideally, it will have been closed; if not, the module
will hang, waiting to read from whatever its stdin happens
to be).

does isatty(0) work on ms windows?
does it work from a pipe?

Hamish

Hi,
2010/1/17 Hamish <hamish_b@yahoo.com>:

If you use "
GRASS_OVERWRITE=1 \
r.mapcalc "result = map * 4
it will work on both versions.

In grass 6.4:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
##ok, raster result has been overwritten
100%

In grass7.0:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
### raster 'result' hasn't been overwritten

I have to setting GRASS_OVERWRITE variable and r.mapcalc command in
the same line as you suggest:
GRASS_OVERWRITE=1 r.mapcalc "r = rand(12,24)"
in this case it works in both version. Strange behaviour IMHO.

here "input=-" has been set to be a required input. AFAIU this is so the
option appears on the first tab of the module GUI window ("Required").
I've complained about that before, so won't repeat myself, but what is
really needed IMO is a new item added somewhere to help order the GUI
sections so these GUI-at-the-expense-of-the-CLI hacks can be avoided.

+1

thanks to all

Paolo C.

Hamish wrote:

> That's not good for the GUI, where the module won't have a
> stdin (ideally, it will have been closed; if not, the module
> will hang, waiting to read from whatever its stdin happens
> to be).

does isatty(0) work on ms windows?

Yes. But only the Windows console is a TTY, MSys' rxvt isn't (which is
why e.g. tclsh and python don't work as expected there).

Windows doesn't appear to have anything similar to ptys.

does it work from a pipe?

A pipe isn't considered a TTY on any platform.

isatty() is frequently misused. It can be a useful heuristic to
determine whether the program is being run interactively, but (as with
most heuristics), there should be a way for the user to override it.

The only situation where behaviour should depend solely upon the
result of isatty() is if you need to rely upon TTY-specific
functionality, e.g. tcsettattr().

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

Paolo Craveri wrote:

> If you use "
> GRASS_OVERWRITE=1 \
> r.mapcalc "result = map * 4
> it will work on both versions.

In grass 6.4:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
##ok, raster result has been overwritten
100%

In grass7.0:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
### raster 'result' hasn't been overwritten

I have to setting GRASS_OVERWRITE variable and r.mapcalc command in
the same line as you suggest:
GRASS_OVERWRITE=1 r.mapcalc "r = rand(12,24)"
in this case it works in both version. Strange behaviour IMHO.

This indicates a difference in the state of the shell between the two
cases, not a difference in GRASS.

Entering "GRASS_OVERWRITE=1" as a command sets the shell variable
GRASS_OVERWRITE. It doesn't necessarily cause it to be "exported" to
the environment used for child processes.

If the command "export GRASS_OVERWRITE" has been executed in the
current shell, the variable has been exported to the environment, and
any changes to the variable will affect the environment used for child
processes.

OTOH, the command "GRASS_OVERWRITE=1 r.mapcalc ..." executes r.mapcalc
with GRASS_OVERWRITE=1 in the environment for that specific process.

See the "bash" manual page for more information.

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

2010/1/18 Glynn Clements <glynn@gclements.plus.com>:

Paolo Craveri wrote:

> If you use "
> GRASS_OVERWRITE=1 \
> r.mapcalc "result = map * 4
> it will work on both versions.

In grass 6.4:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
##ok, raster result has been overwritten
100%

In grass7.0:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
### raster 'result' hasn't been overwritten

I have to setting GRASS_OVERWRITE variable and r.mapcalc command in
the same line as you suggest:
GRASS_OVERWRITE=1 r.mapcalc "r = rand(12,24)"
in this case it works in both version. Strange behaviour IMHO.

This indicates a difference in the state of the shell between the two
cases, not a difference in GRASS.

Entering "GRASS_OVERWRITE=1" as a command sets the shell variable
GRASS_OVERWRITE. It doesn't necessarily cause it to be "exported" to
the environment used for child processes.

If the command "export GRASS_OVERWRITE" has been executed in the
current shell, the variable has been exported to the environment, and
any changes to the variable will affect the environment used for child
processes.

OTOH, the command "GRASS_OVERWRITE=1 r.mapcalc ..." executes r.mapcalc
with GRASS_OVERWRITE=1 in the environment for that specific process.

See the "bash" manual page for more information.

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

Yes, I forgot "export ..."; my fault.

Thanks

--
--
Paolo C.