[GRASS-dev] erratic behavior of v.in.ascii with WinGRASS

[Moritz Lennert]

On 05/02/08 17:17, Michael Barton wrote:
> 
> On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
> 
>>
>> I would rather guess that depending on how the command line was 
>> formulated, i.e. where the fs=| is placed, the command runs correctly 
>> with the default values (i.e. '|' as seperator) or doesn't.
>>
> 
> Not in the case of my Mac gui crash. Exact same command argument order 
> (in gui):
> 
> fs=|   + different number of fields in different records (i.e., data 
> file format bad) = crash TclTk
> fs=|   + same number of fields in all records (i.e., data file format 
> good) = OK
> fs="|" + different number of fields in different records (i.e., data 
> file format bad) = OK
> fs=,   + different number of fields in different records (i.e., data 
> file format bad) = OK
> 
> Windows may be a different story, however. I haven't had a chance to 
> check that.

On Windows (in GUI),

 > fs=|   + different number of fields in different records (i.e., data
 > file format bad)

provokes a dbf error, but that does not crash the GUI. v.in.ascii keeps 
running, though, and I have to kill it. I get exactly the same behaviour 
at the command line.

Using the "good" file format everything works.
Sometimes (but not systematically) the GUI then crashes if I kill the 
v.in.ascii process and then run the command again with the "good" file 
format.

So, at least in windows, the '|' field separator is not the problem. It 
is the fact that there is something keeping v.in.ascii from dealing with 
different line lengths. It does give the right diagnostics, though, i.e.

Maximum input row length: 89
Maximum number of columns: 7
Minimum number of columns: 5

but this is printed to the Output window only after I kill the 
v.in.ascii process.

Will have to debug some more...

Moritz