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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
