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

Michael Barton michael.barton at asu.edu
Tue Feb 5 10:08:18 EST 2008


On Feb 5, 2008, at 5:44 AM, Moritz Lennert wrote:

> On 05/02/08 06:00, Michael Barton wrote:
>> Hi Helena,
>> 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.

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 | ?  
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).

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?

Michael




More information about the grass-dev mailing list