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

[Moritz Lennert]

On 06/02/08 19:03, Glynn Clements wrote:
> 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.

Sorry, yes, obviously. I meant the second part of that case, i.e. 
"different number of fields in different records".

Moritz