Opened 7 years ago

Closed 7 years ago

#1727 closed defect (fixed)

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

Reported by: antonioall Owned by: grass-dev@…
Priority: critical Milestone: 6.4.3
Component: Vector Version: svn-trunk
Keywords: v.in.lines, g.tempfile Cc: marisn
CPU: x86-64 Platform: MSWindows 7

Description (last modified by neteler)

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

Change History (23)

comment:1 Changed 7 years ago by neteler

Description: modified (diff)

comment:2 Changed 7 years ago by neteler

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

comment:3 Changed 7 years ago by 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)

comment:4 Changed 7 years ago by 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

comment:5 Changed 7 years ago by 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

comment:6 Changed 7 years ago by 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

comment:7 Changed 7 years ago by hamish

Keywords: g.tempfile added
Priority: normalcritical

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

comment:8 Changed 7 years ago by 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())

comment:9 in reply to:  8 Changed 7 years ago by 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

comment:10 Changed 7 years ago by 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

comment:11 in reply to:  10 Changed 7 years ago by 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

comment:12 Changed 7 years ago by antonioall

Resolution: fixed
Status: newclosed

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

Thank you

comment:13 Changed 7 years ago by 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

comment:14 Changed 7 years ago by 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

comment:15 Changed 7 years ago by hamish

make that ticket #1945, first comment.

comment:16 Changed 7 years ago by hamish

Resolution: fixed
Status: closedreopened

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

comment:17 Changed 7 years ago by hamish

Cc: marisn added

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

comment:18 Changed 7 years ago by 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

comment:19 Changed 7 years ago by 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

comment:20 Changed 7 years ago by 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

comment:21 in reply to:  17 Changed 7 years ago by 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

comment:22 Changed 7 years ago by 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

comment:23 Changed 7 years ago by hamish

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.