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

[Glynn Clements]

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.

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

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

-- 
Glynn Clements <glynn at gclements.plus.com>