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