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

Michael Barton michael.barton at asu.edu
Wed Feb 6 11:48:27 EST 2008


On Feb 6, 2008, at 10:41 AM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>>>> It looks like the '|' is partly to blame, but not entirely.
>>>> If I use the original file with missmatched numbers of fields
>>>> between records AND use the '|' separator, I have trouble on my  
>>>> Mac.
>>>> However, if I fix the file so that all records have the same
>>>> number of fields (keeping '|' as separator) OR I leave the file
>>>> with messed up fields but replace '|' with ',' it works fine.
>>>> So it seems more a problem of reading the '|' separator in the
>>>> text file in some circumstances than it does having it in the
>>>> command string.
>>>
>>> Just to make sure: I don't think Helena meant that the '|' as
>>> separator causes any problems. It's the fact that you use
>>>
>>> v.in.ascii input=/Users/cmbarton/schools_el_lu.txt
>>> output=schools_lu format=point fs=| skip=0 x=1 y=2 z=0 cat=3
>>>
>>> with fs=| where | is unquoted and thus interpreted as pipe command.
>>
>> Yes,
>>
>> I understood. But it also looks like it's more complicated. In some
>> circumstances fs=| works OK (i.e., without quotes) and in other
>> circumstances it doesn't--suggesting that there also may be a problem
>> when v.in.ascii reads the | character in the ascii file in some  
>> cases.
>
> If the string is parsed by the shell, it needs to be quoted, otherwise
> it doesn't.
>
>> Given these tests and what Glynn said (subsequent post), it seems
>> safest to always quote or escape the | character in v.in.ascii. In
>> this regard, is there a problem with making the default separator for
>> the g.parser section of v.in.ascii "|" instead of the current | ?
>
> Yes. That would cause the quotes to be treated as part of the argument
> to the fs= option.

I don't understand. Helena suggested that I put quotes around "|",  
which I did and which worked--from the GUI. So why not make this the  
default

>
>> Seems like this would avoid problems when v.in.ascii is run in the
>> GUI (i.e., instead of having to change the default entry in the
>> separator field in each case).
>
> There shouldn't be any need for quotes when using the GUI. The GUI
> should not be using the shell at all.

This is where it seems to be needed nonetheless. If I run from the  
GUI and don't use quotes (and the file structure is bad), it crashes  
TclTk. If I run from the command line, it's not running in TclTk and  
so TclTk doesn't crash.

>
>> As an aside, the | character seems like an odd default separator for
>> data fields in GRASS. I suppose it's a holdover from the ancient
>> past. But the fact that this is also has meaning as a pipe seems to
>> make it a risky separator in general. What about switching this to
>> something else in GRASS 7?
>
> There's only thing that's "risky" about using "|" is that certain bugs
> in code which executes commands will show up rather than getting
> overlooked.
>
> If such bugs exist, they should be fixed, rather than having
> individual cases worked around.

OK. But I don't understand what needs to be fixed here (though I'd be  
happy to have whatever needs to be fixed, fixed). I'm hearing quote  
the | character and don't quote the | character. So I'm confused.

Michael




More information about the grass-dev mailing list