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

Glynn Clements glynn at gclements.plus.com
Wed Feb 6 13:03:20 EST 2008


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
> > 
> 
> As Glynn said:
> > The Tcl/Tk GUI doesn't use the shell to execute commands, so it
> > shouldn't be an issue there.
> 
> So, since all the above are done via the gui my guess seems to be 
> totally off anyhow...

If you use quotes in the GUI, the quotes will get passed onto the
command, i.e.

	strcmp(argv[1], "fs=\"|\"") == 0

This will cause both " and | to be treated as field separators.

Note that Tcl "exec" and "open |..." only recognise | as a pipeline
command separator if it is a separate argument. They won't split fs=|
into fs= and | the way that the shell will.

> IIRC, you said that you cannot reproduce this behaviour on the command 
> line, i.e. even the first case works on the command line ?

fs=| will never work on the command line; the shell will always parse
the | as the pipeline command separator.

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


More information about the grass-dev mailing list