[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