v.in.lines not work on Window 7 64 bit

[antonioall]

Hello, v.in.lines not work on Window 7 64 bit

The file Coordinate.txt is:
496174.445494,4553975.166661,429.9415
495577.433542,4556363.214470,372.9797
NaN,NaN,NaN
496174.445494,4553975.166661,429.9415
497882.563024,4554290.256303,370.0215
NaN,NaN,NaN
495577.433542,4556363.214470,372.9797
497882.563024,4554290.256303,370.0215
NaN,NaN,NaN
497882.563024,4554290.256303,370.0215
497899.146689,4556479.300127,382.7335
NaN,NaN,NaN
497899.146689,4556479.300127,382.7335
495577.433542,4556363.214470,372.9797
NaN,NaN,NaN

The Text of Error is:
(Mon Sep 10 10:44:48 2012)                                                      
v.in.lines -z input=C:\myPATH\Coordinate.txt output=prova fs=,   
C:/GRASS GIS 6.4.3svn/scripts/v.in.lines: line 108:
/otherMyPath/PERMANENT/.tmp/4520.0: No such file or
directory
head: cannot open `/otherMyPath/PERMANENT/.tmp/4520.0' for reading: No
such file or directory
ERROR: Not enough data columns. (incorrect fs setting?)
(Mon Sep 10 10:44:48 2012) Comando terminato (0 sec) 

Thanks, Best regards

[neteler]

Please post the true path, I suspect that it contains white space.

[hamish]

AFAICT everything in 6.x is quoted,

L108 reads:

      tr "$fs" ' ' < "$GIS_OPT_INPUT" > "$TEMPFILE"

your test data works for me on Windows XP 32bit using 6.4.2 with the data file stored in 'C:\Documents and Settings\...', even from the wxGUI with file selected using the open file browser and without adding any additional quoting (so bug #1447 was not a problem)

you put the version as trunk but the milestone at 6.4.3. Which version of grass did you see this in?

?, Hamish

(trac still logs me out every bloody time I comment on a ticket! argh)

[hamish]

(Mon Sep 10 10:44:48 2012) Comando terminato (0 sec)

maybe the path contains a UTF8 char?

the module (the error looks like it comes from 6.x version of the script) should edit with an error if it couldn't create the temp file.

?, Hamish

[antonioall]

Hello,
yes, the path of the database contains a white space because the name of the folder of the database is "GIS<space>Database", that is the name assigned by Grass of default during the first installation.

Thanks,
Best regards

[hamish]

Hi, just testing with the latest wingrass 6.5 nightly build.

Your example works for me from the MSYS terminal, but not from the cmd.exe dos box prompt, as it can't find v.in.mapgen when called from within the v.in.lines script -- the old problem of calling scripts from inside of scripts is back, at least for the dos box.

looking at the v.in.mapgen.bat file in $GISBASE/bin/ I see that all the auto-gen .bat files there have UNIX line endings in them. (extra char shows up in notepad.exe) Seems that we need to do more unix2dos calls in the Makefiles to fix those (what changed?). In this case it doesn't fix it; also from the dos box window also module guis and g.gui fail with "no module named grass.script".

Hamish

[hamish]

ok, I can reproduce the error on XP 32bit with the latest nightly 6.5 wingrass build, if I run it from the wxGUI File->Import vector data menu.

you wrote:

C:/GRASS GIS 6.4.3svn/scripts/v.in.lines: line 108:
/otherMyPath/PERMANENT/.tmp/4520.0: No such file or
directory
head: cannot open `/otherMyPath/PERMANENT/.tmp/4520.0' for reading: No
such file or directory

the problem seems to be with g.tempfile, it's leaving the C: off the temp file name. It creates the tempfile ok, but I think in the script it needs to start with "/c/" ? .. right, changing v.in.lines to:

TEMPFILE=/c"g.tempfile pid=$$"

allows v.in.lines process the temp file. (but then v.in.mapgen chokes on its tempfile).

g.tempfile pid=123 run from the wxGUI Command Console shows the same behaviour: the tempfile name in the output canvas is "/Documents and Settings/Username/My Documents/GIS DataBase/spearfish60/user1/.tmp/123.0", without /c or C: to start it. (also not very good if you data is on D: but grass is installed to C:\Program Files)

Hamish

[hamish]

the GISDBASE string without /c/ or C:\ is coming directly from g.gisenv's GISDBASE setting. (via lib/gis/gisdbase.c's G_gisdbase())

[hamish]

Replying to hamish:

the GISDBASE string without /c/ or C:\ is coming directly from g.gisenv's GISDBASE setting. (via lib/gis/gisdbase.c's G_gisdbase())

that's it: editing the C:\Docs and Settings\Username\Application Data\GRASS6\grassrc6 file while GRASS is not running, or just adding "c:" in the GISDBASE box in the grass startup screen, allows v.in.lines to find its tempfile and import the file correctly.

Hamish

[hamish]

Attempt at giving the script .bat files DOS line endings committed to devbr6 in r55904. hopefully it helps for that part of the problem.

I'm not sure how GISDBASE was losing its C: part, removing the %APPDATA%/GRASS6/grassrc file and starting over it puts it in and v.in.lines works...

the wingrass grassrc6 file is originally created by lib/init/Init.bat, and GISDBASE there by %USERPROFILE%" | g.dirseps -g, which preserves the full thing.

Maybe the result of some historical left-over, but it happened to both me and antonioall .. ?

Hamish

[neteler]

Replying to hamish:

Attempt at giving the script .bat files DOS line endings committed to devbr6 in r55904. hopefully it helps for that part of the problem.

Backported to relbranch64 (r55922) to get it into 6.4.3RC3

[antonioall]

Hello, I tested v.in.lines in version 6.4.3RC3 and work well.

Thank you

[hamish]

How C: got lost from GISDBASE for both of us is still a mystery, but now we know what to look out for.

reopen if it comes back..

we also need to test it from the CMD.EXE grass Command Line in 6.x before forgetting about it.

Hamish

[hamish]

DOS newlines in the bin/*.bat files seem ok, but the script-called-from-within-a-script does not yet work in the current cmd.exe Command Line grass, see #1845, so v.in.lines fails there.

Hamish

[hamish]

make that ticket #1945, first comment.

[hamish]

nope, not fixed. the GRASS Command Line startup option just ate the C: part of my GISDBASE again in %APPDATA%/GRASS6/grassrc6. (latest 6.5svn nightly build)

Hamish

[hamish]

it's the GRASS GIS 6.x Old TclTk GUI startup menu item which is eating the C: part of GISDBASE.

specifically this line in lib/init/gis_set.tcl:

if { [regexp -- {^GISDBASE.*:(.*)$} $thisline dummy env_database] } {
    set database [string trim $env_database]
}

looking into why it isn't like {|^GISDBASE: \(.*\)$} already with 'svn blame', looks like r45817 introduced it. Maris, do you remember what the problem is that was fixing, so we can avoid reintroducing it?

thanks, Hamish

[hamish]

Glynn suggested the reason that the script-with-a-script was not working from the C:\> Command line version of wingrass 6.x was that the $GISBASE\scripts dir was missing from the %PATH% there. This is indeed the case, and adding it to the %PATH% allows v.in.lines (and any other script which calls another shell script) to run successfully.

$GISBASE/bin is in there twice, that will need a test-before-adding too (maybe in env.bat?)

tcl/tk eating the C: string remains open.

Hamish

[hamish]

re. script-called-from-a-script failure from the 6.x wingrass Command Line and GIS.m, here's a patch.

Index: lib/init/init.bat
===================================================================
--- lib/init/init.bat	(revision 56002)
+++ lib/init/init.bat	(working copy)
@@ -24,8 +24,10 @@
 
 set SAVEPATH=%PATH%
 rem
-rem DON'T include the scripts/ directory in PATH -- The .bat files in the
-rem   bin/ directory are what execute the scripts on Windows.
+rem The .bat files in the \bin directory are what execute the scripts
+rem  on Windows. The \scripts dir is added to the PATH automatically by
+rem  the wxGUI; for Command Line mode and GIS.m, shell scripts called from
+rem  other shell scripts need to have %GISBASE%\scripts in the PATH.
 rem
 
 if exist "%APPDATA%\GRASS6\env.bat" (
@@ -121,9 +123,12 @@
 	set PYTHONPATH=%PYTHONPATH%;%GISBASE%\etc\python
 )
 
-if "%GRASS_GUI%"=="text" goto text
 if "%GRASS_GUI%"=="wxpython" goto wxpython
 
+PATH=%PATH%;%GISBASE%\scripts
+if "%GRASS_GUI%"=="text" goto text
+
+rem Tcl/Tk GUI setup
 if not "%GRASS_WISH%"=="" (
 	"%GRASS_WISH%" "%GISBASE%\etc\gis_set.tcl"
 ) else (

any comments before committing it?

Hamish

[hamish]

re. tcl/tk gui removing C:\ from GISDBASE,

Hamish wrote:

looking into why it isn't like {|^{GISDBASE: \(.*\)$} already with 'svn blame', looks like r45817 introduced it. Maris, do you remember what the problem is that was fixing, so we can avoid reintroducing it?}

?

re. patch for scripts within a script not working:

any comments before committing it?

last chance..

Hamish

[hamish]

Replying to hamish:

it's the GRASS GIS 6.x Old TclTk GUI startup menu item which is eating the C: part of GISDBASE.

specifically this line in lib/init/gis_set.tcl:

if { [regexp -- {^GISDBASE.*:(.*)$} $thisline dummy env_database] } {
    set database [string trim $env_database]
}

looking into why it isn't like {|^GISDBASE: \(.*\)$} already with 'svn blame', looks like r45817 introduced it. Maris, do you remember what the problem is that was fixing, so we can avoid reintroducing it?

it was a work-around for #1340, which was fixed a long time ago.

partial revert of r45817 done in devbr6 with r56071.

Hamish

[hamish]

• script-called-from-script (adding \scripts to %PATH%) done & tested in devbr6 r56092 (cmd.exe and tcl/tk gui startups) and backported to relbr64 in r56104 (still to be tested there).

• tcl/tk gui eating C:\ from GISDBASE done in grassrc6 in r56071 & tested for devbr6, backported to relbr64 in r56105 (still to be tested there).

Hamish

[hamish]

ok, now fixed & tested in relbr64:

• script-called-from-script in cmd.exe and tcl/tk wingrass startups
• .bat wrappers for shell scripts now have DOS newlines
• tcl/tk eating C:\ from GISDBASE in grassrc6

Hamish