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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
