Re: CSV extension status

[Neil R. Ormos]

Andrew J. Schorr wrote:
> Manuel Collado wrote:

>> [...]

> I think I understand the conceptual problem, but
> I feel as if maybe we're letting the perfect be
> the enemy of the good. In 99.9% of the cases
> where I use CSV files, I simply want to have
> read-only access to the fields. Actually, if I'm
> being honest, it's 100%. In other words, I want
> to be able to say something like:

> Perhaps I simply haven't dug deep enough into
> the wonders of CSV format, but if we could
> somehow have a csv library or include file that
> enabled CSV parsing to work transparently in the
> read-only case, I think that would be a big win.
> [...]

> If we in addition need to have an insanely
> complicated gawk library on top of that to
> enable reparsing and reconstruction and writing
> of records, that's fine, [...]

I would offer a slighly different perspective.  I
don't believe this is a matter of the perfect
being the enemy of the good.

What would be really useful to me would be a
facility that transparently and efficiently treats
real-world CSV input as though the equivalent
input had been received as FS-separated input,
with sensible handling of embedded newlines.  By
"transparent" I mean with the same side-effects
and without additional vexatious restrictions.

If the extension behavior is hard to understand or
the extension adds a bunch of restrictions to
remember, it's unclear why using it is better than
trivally converting the input before awk sees it,
or writing one's own bespoke awk function to do
the conversion.