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

[Moritz Lennert]

On 05/02/08 16:08, Michael Barton wrote:
> 
> 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.

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.


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

if g.parser accepts "|" as entry, why not ?


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

I've always found '|' quite useful as it is a symbol you are pretty sure 
not to find in any text fields you might import. All others (e.g. ',' 
';', etc) are more likely to be used in a text field.

Moritz