gawkextlib-developer — For internal communication between developers

[Gawkextlib-developer] 🚀 Struggling To Get A Constant Flow Of Customers?

[Maya C. <ma...@tr...>]

Meet ClickFunnels.

Getting People To Your Website And Turning Them Into 
Happy Paying Customers Is What We Do Best.
Zero Computer Skills Needed

Works 
For Every Type Of Business

Market, Sell, And Deliver Like A Pro

Learn More 
[Go Click 
Funnel](https://app.pesoso.com/p/aHR0cHM6Ly93d3cuY2xpY2tmdW5uZWxzLmNvbS9zaWduLXVwLWZsb3c_YWZmPTdjZWUxMGRlLTJlMWUtNDcyYS05YWEwLTI3NGE2YWY3ZTc2ZC0xV3pFd0xEUXhNVGsyWFE1/click/MTcwMTM5MjM5Mjk0NjYzMC42NTY5MzAwODk5OTk0QHRyYWZmaWNzZW5kLmNv)


Looking forward to helping you on your journey,

Maya. Sales Manager,

ClickFunnels

Dont Want Us: 
[Unsubscribe](https://app.pesoso.com/c/15a0a63dab339/unsubscribe/MTcwMTM5MjM5Mjk0NjYzMC42NTY5MzAwODk5OTk0QHRyYWZmaWNzZW5kLmNv)


[This is a tracking pixel][X-Client-Message-Id: 
170...@tr...]

Re: [Gawkextlib-developer] [gawkextlib:bugs] #8 gawk-gd translucency fix (fwd)

[Andrew J. S. <as...@te...>]

Ha. Thanks. I committed the patch. I guess I should push out a new
release of the GD library...

On Tue, Nov 14, 2023 at 09:15:10AM +0100, Jürgen Kahrs Google IMAP wrote:
> Hello Andrew,
> Evgeny's change adds just one line containing a function call.
> After this change all PNG files will be saved with an alpha
> translucency channel. I think this is a good idea.
> 
> Thanks to Evgeny for caring about this advanced feature and
> to Andrew for caring about the GIT stuff that causes me to acquire
> a spontaneous a skin rash whenevever I think about GIT.
> 
> Juergen Kahrs
> 
> 
> >Hi,
> >
> >In bug https://sourceforge.net/p/gawkextlib/bugs/8/, Evgeny is proposing the
> >attached patch. Is anybody able to evaluate whether this makes sense? I'm not
> >familiar with the GD API and extension.  It passes "make check" for me, but I
> >have no ability to validate it beyond that.
> >
> >Regards,
> >Andy
> >
> >----- Forwarded message from Evgeny Dobromilsky <nes...@us...> -----
> >
> >Date: Sat, 11 Nov 2023 16:27:13 -0000
> >From: Evgeny Dobromilsky <nes...@us...>
> >To: "[gawkextlib:bugs] " <8...@bu...>
> >Subject: [gawkextlib:bugs] #8 gawk-gd translucency fix
> >
> >Sorry for my bad English. Alpha channel was ignored WHILE saving a PNG-file,
> >but with gdImageSaveAlpha(im, 1) the file is saving with alpha-channel.
> >
> >━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >
> >[bugs:#8] gawk-gd translucency fix
> >
> >Status: open
> >Group: v1.0_(example)
> >Created: Sat Nov 11, 2023 04:24 PM UTC by Evgeny Dobromilsky
> >Last Updated: Sat Nov 11, 2023 04:24 PM UTC
> >Owner: nobody
> >Attachments:
> >
> >   • gd.c (19.2 kB; text/x-csrc)
> >
> >The gawk-gd library ignored alpha-channel due saving PNG-files, I've added this
> >line to a gd.c source:
> >gdImageSaveAlpha(im, 1); // save full alpha channel
> >Tested. Works great.
> >Please, update it in repo.
> >
> >━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
> >
> >Sent from sourceforge.net because you indicated interest in
> >https://sourceforge.net/p/gawkextlib/bugs/8/
> >
> >----- End forwarded message -----
> >
> >
> >_______________________________________________
> >Gawkextlib-developer mailing list
> >Gaw...@li...
> >https://lists.sourceforge.net/lists/listinfo/gawkextlib-developer
> 

Re: [Gawkextlib-developer] [gawkextlib:bugs] #8 gawk-gd translucency fix (fwd)

[<jue...@go...>]

Hello Andrew,
Evgeny's change adds just one line containing a function call.
After this change all PNG files will be saved with an alpha
translucency channel. I think this is a good idea.

Thanks to Evgeny for caring about this advanced feature and
to Andrew for caring about the GIT stuff that causes me to acquire
a spontaneous a skin rash whenevever I think about GIT.

Juergen Kahrs


> Hi,
>
> In bug https://sourceforge.net/p/gawkextlib/bugs/8/, Evgeny is proposing the
> attached patch. Is anybody able to evaluate whether this makes sense? I'm not
> familiar with the GD API and extension.  It passes "make check" for me, but I
> have no ability to validate it beyond that.
>
> Regards,
> Andy
>
> ----- Forwarded message from Evgeny Dobromilsky <nes...@us...> -----
>
> Date: Sat, 11 Nov 2023 16:27:13 -0000
> From: Evgeny Dobromilsky <nes...@us...>
> To: "[gawkextlib:bugs] " <8...@bu...>
> Subject: [gawkextlib:bugs] #8 gawk-gd translucency fix
>
> Sorry for my bad English. Alpha channel was ignored WHILE saving a PNG-file,
> but with gdImageSaveAlpha(im, 1) the file is saving with alpha-channel.
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> [bugs:#8] gawk-gd translucency fix
>
> Status: open
> Group: v1.0_(example)
> Created: Sat Nov 11, 2023 04:24 PM UTC by Evgeny Dobromilsky
> Last Updated: Sat Nov 11, 2023 04:24 PM UTC
> Owner: nobody
> Attachments:
>
>    • gd.c (19.2 kB; text/x-csrc)
>
> The gawk-gd library ignored alpha-channel due saving PNG-files, I've added this
> line to a gd.c source:
> gdImageSaveAlpha(im, 1); // save full alpha channel
> Tested. Works great.
> Please, update it in repo.
>
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/gawkextlib/bugs/8/
>
> ----- End forwarded message -----
>
>
> _______________________________________________
> Gawkextlib-developer mailing list
> Gaw...@li...
> https://lists.sourceforge.net/lists/listinfo/gawkextlib-developer

[Gawkextlib-developer] [gawkextlib:bugs] #8 gawk-gd translucency fix (fwd)

[Andrew J. S. <as...@te...>]

Hi,

In bug https://sourceforge.net/p/gawkextlib/bugs/8/, Evgeny is proposing the
attached patch. Is anybody able to evaluate whether this makes sense? I'm not
familiar with the GD API and extension.  It passes "make check" for me, but I
have no ability to validate it beyond that.

Regards,
Andy

----- Forwarded message from Evgeny Dobromilsky <nes...@us...> -----

Date: Sat, 11 Nov 2023 16:27:13 -0000
From: Evgeny Dobromilsky <nes...@us...>
To: "[gawkextlib:bugs] " <8...@bu...>
Subject: [gawkextlib:bugs] #8 gawk-gd translucency fix

Sorry for my bad English. Alpha channel was ignored WHILE saving a PNG-file,
but with gdImageSaveAlpha(im, 1) the file is saving with alpha-channel.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[bugs:#8] gawk-gd translucency fix

Status: open
Group: v1.0_(example)
Created: Sat Nov 11, 2023 04:24 PM UTC by Evgeny Dobromilsky
Last Updated: Sat Nov 11, 2023 04:24 PM UTC
Owner: nobody
Attachments:

  • gd.c (19.2 kB; text/x-csrc)

The gawk-gd library ignored alpha-channel due saving PNG-files, I've added this
line to a gd.c source:
gdImageSaveAlpha(im, 1); // save full alpha channel
Tested. Works great.
Please, update it in repo.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gawkextlib/bugs/8/

----- End forwarded message -----

Re: [Gawkextlib-developer] Rework gawk-csv as gawk-csvio, and more

[Andrew J. S. <as...@te...>]

Hi,

Just to be clear -- I don't consider myself a gatekeeper. If you'd
like to contribute one or more packages, that's entirely up to you.

Now for my 2 cents, which you are free to disregard:

First, a question: why would gawkextlib need a CSV input parser if
core gawk has been enhanced to parse CSV files properly?
I suspect that you're going to say that this is because the core
gawk handling of CSV files has some shortcomings...

Second: my general impression is that people really dislike building
extension libraries from C code, so a pure gawk library may have a greater
chance of being used.

But you have a far better understanding of CSV issues than I do,
so I certainly defer to your judgement. IMO, you should do what makes
the most sense to you.

Best,
Andy

On Thu, Apr 20, 2023 at 07:42:09PM +0200, Manuel Collado wrote:
> After the long discussion on the gawk-devel mailinglist about gawk
> CSV support, I find my previous work on the gawk-csv extension
> (gawkextlib) and the csvmode.awk library (on my website)
> unnecessarily complicated.
> 
> So I've started to rework them as a very simplified CSV support. As
> either a CSV input parser (extension) or a pure gawk library, ready
> to be used.
> 
> Would it be Ok to have a gawkextlib project distributing more than
> one package? Say
> - gawk-csvio-ext.x.x.x.tar.gz, (input parser) and
> - gawk-csvio-lib.x.x.x.tar.gz  (pure gawk library alternative)
> 
> Users willing to compile sources could select the first, and lazy
> users could prefer the second, probably less efficient but
> effective.
> 
> The pure gawk library version can also be rewritten without any use
> of non-posix language extensions. So it could be also used with
> other awk processors (mawk, nawk, ..). In that case a third distro
> could be provided
> - awk-csvio-lib.x.x.x.tar.gz
> 
> If all that sounds reasonable, I'll provide details about their
> simple user interface and implementation details, to be discussed.
> 
> Regards.
> -- 
> Manuel Collado - http://mcollado.z15.es

[Gawkextlib-developer] Rework gawk-csv as gawk-csvio, and more

[Manuel C. <mco...@gm...>]

After the long discussion on the gawk-devel mailinglist about gawk CSV 
support, I find my previous work on the gawk-csv extension (gawkextlib) 
and the csvmode.awk library (on my website) unnecessarily complicated.

So I've started to rework them as a very simplified CSV support. As 
either a CSV input parser (extension) or a pure gawk library, ready to 
be used.

Would it be Ok to have a gawkextlib project distributing more than one 
package? Say
- gawk-csvio-ext.x.x.x.tar.gz, (input parser) and
- gawk-csvio-lib.x.x.x.tar.gz  (pure gawk library alternative)

Users willing to compile sources could select the first, and lazy users 
could prefer the second, probably less efficient but effective.

The pure gawk library version can also be rewritten without any use of 
non-posix language extensions. So it could be also used with other awk 
processors (mawk, nawk, ..). In that case a third distro could be provided
- awk-csvio-lib.x.x.x.tar.gz

If all that sounds reasonable, I'll provide details about their simple 
user interface and implementation details, to be discussed.

Regards.
-- 
Manuel Collado - http://mcollado.z15.es

Re: [Gawkextlib-developer] CSV parsing

[Manuel C. <mco...@gm...>]

Forgot to ask. Where is the bwk-awk code with the CSV patch?

Thanks.

El 12/3/23 a las 23:27, Manuel Collado escribió:
> El 12/3/23 a las 21:18, Jürgen Kahrs via Gawkextlib-developer escribió:
>> Hello,
>> Kernighan has commented on the quality of his CSV source code change.
>> Look at the very last sentence of the article.
>>
>> https://arstechnica.com/gadgets/2022/08/unix-legend-who-owes-us-nothing-keeps-fixing-foundational-awk-code/
>>    Kernighan, now 80, offhandedly mentions in the interview  that
>>    he has also patched something "quick and dirty" to let AWK handle 
>> CSV files.
> 
> Interesting. So there is hope about suggesting him a "quick but not 
> dirty" approach.
> 
> Will elaborate on that. In brief: think of CSV as just an external 
> import format. Discarded after importing data.
> 
>>
>> The interview is now 6 months old, maybe he has worked
>> a bit on his original idea. But I doubt that he has.
>> Unicode changes seemed to be much more important for him.
> 

-- 
Manuel Collado - http://mcollado.z15.es

Re: [Gawkextlib-developer] CSV parsing

[Manuel C. <mco...@gm...>]

El 12/3/23 a las 21:18, Jürgen Kahrs via Gawkextlib-developer escribió:
> Hello,
> Kernighan has commented on the quality of his CSV source code change.
> Look at the very last sentence of the article.
> 
> https://arstechnica.com/gadgets/2022/08/unix-legend-who-owes-us-nothing-keeps-fixing-foundational-awk-code/
>    Kernighan, now 80, offhandedly mentions in the interview  that
>    he has also patched something "quick and dirty" to let AWK handle CSV 
> files.

Interesting. So there is hope about suggesting him a "quick but not 
dirty" approach.

Will elaborate on that. In brief: think of CSV as just an external 
import format. Discarded after importing data.

> 
> The interview is now 6 months old, maybe he has worked
> a bit on his original idea. But I doubt that he has.
> Unicode changes seemed to be much more important for him.

-- 
Manuel Collado - http://mcollado.z15.es

Re: [Gawkextlib-developer] CSV parsing

[<jue...@go...>]

Hello,
Kernighan has commented on the quality of his CSV source code change.
Look at the very last sentence of the article.

https://arstechnica.com/gadgets/2022/08/unix-legend-who-owes-us-nothing-keeps-fixing-foundational-awk-code/
   Kernighan, now 80, offhandedly mentions in the interview  that
   he has also patched something "quick and dirty" to let AWK handle CSV files.

The interview is now 6 months old, maybe he has worked
a bit on his original idea. But I doubt that he has.
Unicode changes seemed to be much more important for him.


> He often doesn't respond if he doesn't want to. Frustrating,
> but that's how it goes...
>
> Arnold
>
> "Andrew J. Schorr" <as...@te...> wrote:
>
>> Perhaps nothing? Or does he tend to take a long time to respond to emails? :-)
>> Maybe it ended up in his spam folder...
>>
>> Regards,
>> Andy
>>
>> On Wed, Mar 08, 2023 at 01:10:24AM -0700, ar...@sk... wrote:
>>> I saw. Thanks. It will be interesting to see what happens.
>>>
>>> "Andrew J. Schorr" <as...@te...> wrote:
>>>
>>>> OK, I took a shot at it.
>>>>
>>>> Regards,
>>>> Andy
>>>>
>>>> On Tue, Mar 07, 2023 at 10:50:41AM -0700, ar...@sk... wrote:
>>>>> Yes, bw...@cs....
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Arnold
>>>>>
>>>>> "Andrew J. Schorr" <as...@te...> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> OK -- I can try that if you think it's better coming from me.
>>>>>> Is it best to send to the cs.princeton.edu email address?
>>>>>>
>>>>>> Thanks,
>>>>>> Andy
>>>>>>
>>>>>> On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
>>>>>>> I suspect that Brian doesn't really realize how badly it breaks
>>>>>>> backwards compatibility, but heck, he's *Brian Kernighan*, it's
>>>>>>> really hard to tell him he's making a mistake.
>>>>>>>
>>>>>>> I think that if you were to compose a (polite) note introducing yourself
>>>>>>> as a gawk contributor and raising some of the issues, he would
>>>>>>> certainly give it attention and respond. He's very down-to-earth.
>>>>>>> (You can cc me.)
>>>>>>>
>>>>>>> In any case, other than perhaps allowing FS="," to be special only
>>>>>>> with --compat, I don't plan any changes to the existing CSV support.
>>>>>>> I want it to exactly match his awk, no more, and no less.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Arnold
>>>>>>>
>>>>>>> "Andrew J. Schorr" <as...@te...> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
>>>>>>>>> (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
>>>>>>>>> is given. I'm not sure. However, it certainly doesn't do CSV if
>>>>>>>>> --posix is given.)
>>>>>>>> This aspect of breaking backwards compatibility concerns me.  I feel that
>>>>>>>> upgrading to a new version of gawk ought not to break existing code. I tend to
>>>>>>>> agree with Manuel that some additional option ought to be required to activate
>>>>>>>> this new, incompatible behavior.  I don't know whether that should be --compat
>>>>>>>> or --csv, although --csv seems to make more sense in terms of
>>>>>>>> comprehensibility.
>>>>>>>>
>>>>>>>> Other than that, I think you both make good points, but I think that Brian is
>>>>>>>> being injudicious in slamming in this change in a way that can break existing
>>>>>>>> scripts. Has he truly thought this through?
>>>>>>>>
>>>>>>>> Thanks Manuel for identifying some important issues. I think the
>>>>>>>> point about setting PROCINFO["FS"] is also a valid one, although I doubt
>>>>>>>> that many scripts rely on this.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Andy
>>>> -- 
>>>> Andrew Schorr                      e-mail: as...@te...
>>>> Telemetry Investments, L.L.C.      phone:  917-305-1748
>>>> 152 W 36th St, #402                fax:    212-425-5550
>>>> New York, NY 10018-8765
>> -- 
>> Andrew Schorr                      e-mail: as...@te...
>> Telemetry Investments, L.L.C.      phone:  917-305-1748
>> 152 W 36th St, #402                fax:    212-425-5550
>> New York, NY 10018-8765
>
> _______________________________________________
> Gawkextlib-developer mailing list
> Gaw...@li...
> https://lists.sourceforge.net/lists/listinfo/gawkextlib-developer

Re: [Gawkextlib-developer] CSV parsing

[<ar...@sk...>]

He often doesn't respond if he doesn't want to. Frustrating,
but that's how it goes...

Arnold

"Andrew J. Schorr" <as...@te...> wrote:

> Perhaps nothing? Or does he tend to take a long time to respond to emails? :-)
> Maybe it ended up in his spam folder...
>
> Regards,
> Andy
>
> On Wed, Mar 08, 2023 at 01:10:24AM -0700, ar...@sk... wrote:
> > I saw. Thanks. It will be interesting to see what happens.
> > 
> > "Andrew J. Schorr" <as...@te...> wrote:
> > 
> > > OK, I took a shot at it.
> > >
> > > Regards,
> > > Andy
> > >
> > > On Tue, Mar 07, 2023 at 10:50:41AM -0700, ar...@sk... wrote:
> > > > Yes, bw...@cs....
> > > > 
> > > > Thanks,
> > > > 
> > > > Arnold
> > > > 
> > > > "Andrew J. Schorr" <as...@te...> wrote:
> > > > 
> > > > > Hi,
> > > > >
> > > > > OK -- I can try that if you think it's better coming from me.
> > > > > Is it best to send to the cs.princeton.edu email address?
> > > > >
> > > > > Thanks,
> > > > > Andy
> > > > >
> > > > > On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
> > > > > > I suspect that Brian doesn't really realize how badly it breaks
> > > > > > backwards compatibility, but heck, he's *Brian Kernighan*, it's
> > > > > > really hard to tell him he's making a mistake.
> > > > > > 
> > > > > > I think that if you were to compose a (polite) note introducing yourself
> > > > > > as a gawk contributor and raising some of the issues, he would
> > > > > > certainly give it attention and respond. He's very down-to-earth.
> > > > > > (You can cc me.)
> > > > > > 
> > > > > > In any case, other than perhaps allowing FS="," to be special only
> > > > > > with --compat, I don't plan any changes to the existing CSV support.
> > > > > > I want it to exactly match his awk, no more, and no less.
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Arnold
> > > > > > 
> > > > > > "Andrew J. Schorr" <as...@te...> wrote:
> > > > > > 
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > > > > > > > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > > > > > > > is given. I'm not sure. However, it certainly doesn't do CSV if
> > > > > > > > --posix is given.)
> > > > > > >
> > > > > > > This aspect of breaking backwards compatibility concerns me.  I feel that
> > > > > > > upgrading to a new version of gawk ought not to break existing code. I tend to
> > > > > > > agree with Manuel that some additional option ought to be required to activate
> > > > > > > this new, incompatible behavior.  I don't know whether that should be --compat
> > > > > > > or --csv, although --csv seems to make more sense in terms of
> > > > > > > comprehensibility.
> > > > > > >
> > > > > > > Other than that, I think you both make good points, but I think that Brian is
> > > > > > > being injudicious in slamming in this change in a way that can break existing
> > > > > > > scripts. Has he truly thought this through?
> > > > > > >
> > > > > > > Thanks Manuel for identifying some important issues. I think the
> > > > > > > point about setting PROCINFO["FS"] is also a valid one, although I doubt
> > > > > > > that many scripts rely on this.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Andy
> > > > 
> > >
> > > -- 
> > > Andrew Schorr                      e-mail: as...@te...
> > > Telemetry Investments, L.L.C.      phone:  917-305-1748
> > > 152 W 36th St, #402                fax:    212-425-5550
> > > New York, NY 10018-8765
> > 
>
> -- 
> Andrew Schorr                      e-mail: as...@te...
> Telemetry Investments, L.L.C.      phone:  917-305-1748
> 152 W 36th St, #402                fax:    212-425-5550
> New York, NY 10018-8765

Re: [Gawkextlib-developer] CSV parsing

[Andrew J. S. <as...@te...>]

Perhaps nothing? Or does he tend to take a long time to respond to emails? :-)
Maybe it ended up in his spam folder...

Regards,
Andy

On Wed, Mar 08, 2023 at 01:10:24AM -0700, ar...@sk... wrote:
> I saw. Thanks. It will be interesting to see what happens.
> 
> "Andrew J. Schorr" <as...@te...> wrote:
> 
> > OK, I took a shot at it.
> >
> > Regards,
> > Andy
> >
> > On Tue, Mar 07, 2023 at 10:50:41AM -0700, ar...@sk... wrote:
> > > Yes, bw...@cs....
> > > 
> > > Thanks,
> > > 
> > > Arnold
> > > 
> > > "Andrew J. Schorr" <as...@te...> wrote:
> > > 
> > > > Hi,
> > > >
> > > > OK -- I can try that if you think it's better coming from me.
> > > > Is it best to send to the cs.princeton.edu email address?
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > > On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
> > > > > I suspect that Brian doesn't really realize how badly it breaks
> > > > > backwards compatibility, but heck, he's *Brian Kernighan*, it's
> > > > > really hard to tell him he's making a mistake.
> > > > > 
> > > > > I think that if you were to compose a (polite) note introducing yourself
> > > > > as a gawk contributor and raising some of the issues, he would
> > > > > certainly give it attention and respond. He's very down-to-earth.
> > > > > (You can cc me.)
> > > > > 
> > > > > In any case, other than perhaps allowing FS="," to be special only
> > > > > with --compat, I don't plan any changes to the existing CSV support.
> > > > > I want it to exactly match his awk, no more, and no less.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Arnold
> > > > > 
> > > > > "Andrew J. Schorr" <as...@te...> wrote:
> > > > > 
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > > > > > > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > > > > > > is given. I'm not sure. However, it certainly doesn't do CSV if
> > > > > > > --posix is given.)
> > > > > >
> > > > > > This aspect of breaking backwards compatibility concerns me.  I feel that
> > > > > > upgrading to a new version of gawk ought not to break existing code. I tend to
> > > > > > agree with Manuel that some additional option ought to be required to activate
> > > > > > this new, incompatible behavior.  I don't know whether that should be --compat
> > > > > > or --csv, although --csv seems to make more sense in terms of
> > > > > > comprehensibility.
> > > > > >
> > > > > > Other than that, I think you both make good points, but I think that Brian is
> > > > > > being injudicious in slamming in this change in a way that can break existing
> > > > > > scripts. Has he truly thought this through?
> > > > > >
> > > > > > Thanks Manuel for identifying some important issues. I think the
> > > > > > point about setting PROCINFO["FS"] is also a valid one, although I doubt
> > > > > > that many scripts rely on this.
> > > > > >
> > > > > > Regards,
> > > > > > Andy
> > > 
> >
> > -- 
> > Andrew Schorr                      e-mail: as...@te...
> > Telemetry Investments, L.L.C.      phone:  917-305-1748
> > 152 W 36th St, #402                fax:    212-425-5550
> > New York, NY 10018-8765
> 

-- 
Andrew Schorr                      e-mail: as...@te...
Telemetry Investments, L.L.C.      phone:  917-305-1748
152 W 36th St, #402                fax:    212-425-5550
New York, NY 10018-8765

Re: [Gawkextlib-developer] CSV parsing

[<ar...@sk...>]

I saw. Thanks. It will be interesting to see what happens.

"Andrew J. Schorr" <as...@te...> wrote:

> OK, I took a shot at it.
>
> Regards,
> Andy
>
> On Tue, Mar 07, 2023 at 10:50:41AM -0700, ar...@sk... wrote:
> > Yes, bw...@cs....
> > 
> > Thanks,
> > 
> > Arnold
> > 
> > "Andrew J. Schorr" <as...@te...> wrote:
> > 
> > > Hi,
> > >
> > > OK -- I can try that if you think it's better coming from me.
> > > Is it best to send to the cs.princeton.edu email address?
> > >
> > > Thanks,
> > > Andy
> > >
> > > On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
> > > > I suspect that Brian doesn't really realize how badly it breaks
> > > > backwards compatibility, but heck, he's *Brian Kernighan*, it's
> > > > really hard to tell him he's making a mistake.
> > > > 
> > > > I think that if you were to compose a (polite) note introducing yourself
> > > > as a gawk contributor and raising some of the issues, he would
> > > > certainly give it attention and respond. He's very down-to-earth.
> > > > (You can cc me.)
> > > > 
> > > > In any case, other than perhaps allowing FS="," to be special only
> > > > with --compat, I don't plan any changes to the existing CSV support.
> > > > I want it to exactly match his awk, no more, and no less.
> > > > 
> > > > Thanks,
> > > > 
> > > > Arnold
> > > > 
> > > > "Andrew J. Schorr" <as...@te...> wrote:
> > > > 
> > > > > Hi,
> > > > >
> > > > > On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > > > > > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > > > > > is given. I'm not sure. However, it certainly doesn't do CSV if
> > > > > > --posix is given.)
> > > > >
> > > > > This aspect of breaking backwards compatibility concerns me.  I feel that
> > > > > upgrading to a new version of gawk ought not to break existing code. I tend to
> > > > > agree with Manuel that some additional option ought to be required to activate
> > > > > this new, incompatible behavior.  I don't know whether that should be --compat
> > > > > or --csv, although --csv seems to make more sense in terms of
> > > > > comprehensibility.
> > > > >
> > > > > Other than that, I think you both make good points, but I think that Brian is
> > > > > being injudicious in slamming in this change in a way that can break existing
> > > > > scripts. Has he truly thought this through?
> > > > >
> > > > > Thanks Manuel for identifying some important issues. I think the
> > > > > point about setting PROCINFO["FS"] is also a valid one, although I doubt
> > > > > that many scripts rely on this.
> > > > >
> > > > > Regards,
> > > > > Andy
> > 
>
> -- 
> Andrew Schorr                      e-mail: as...@te...
> Telemetry Investments, L.L.C.      phone:  917-305-1748
> 152 W 36th St, #402                fax:    212-425-5550
> New York, NY 10018-8765

Re: [Gawkextlib-developer] CSV parsing

[Andrew J. S. <as...@te...>]

OK, I took a shot at it.

Regards,
Andy

On Tue, Mar 07, 2023 at 10:50:41AM -0700, ar...@sk... wrote:
> Yes, bw...@cs....
> 
> Thanks,
> 
> Arnold
> 
> "Andrew J. Schorr" <as...@te...> wrote:
> 
> > Hi,
> >
> > OK -- I can try that if you think it's better coming from me.
> > Is it best to send to the cs.princeton.edu email address?
> >
> > Thanks,
> > Andy
> >
> > On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
> > > I suspect that Brian doesn't really realize how badly it breaks
> > > backwards compatibility, but heck, he's *Brian Kernighan*, it's
> > > really hard to tell him he's making a mistake.
> > > 
> > > I think that if you were to compose a (polite) note introducing yourself
> > > as a gawk contributor and raising some of the issues, he would
> > > certainly give it attention and respond. He's very down-to-earth.
> > > (You can cc me.)
> > > 
> > > In any case, other than perhaps allowing FS="," to be special only
> > > with --compat, I don't plan any changes to the existing CSV support.
> > > I want it to exactly match his awk, no more, and no less.
> > > 
> > > Thanks,
> > > 
> > > Arnold
> > > 
> > > "Andrew J. Schorr" <as...@te...> wrote:
> > > 
> > > > Hi,
> > > >
> > > > On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > > > > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > > > > is given. I'm not sure. However, it certainly doesn't do CSV if
> > > > > --posix is given.)
> > > >
> > > > This aspect of breaking backwards compatibility concerns me.  I feel that
> > > > upgrading to a new version of gawk ought not to break existing code. I tend to
> > > > agree with Manuel that some additional option ought to be required to activate
> > > > this new, incompatible behavior.  I don't know whether that should be --compat
> > > > or --csv, although --csv seems to make more sense in terms of
> > > > comprehensibility.
> > > >
> > > > Other than that, I think you both make good points, but I think that Brian is
> > > > being injudicious in slamming in this change in a way that can break existing
> > > > scripts. Has he truly thought this through?
> > > >
> > > > Thanks Manuel for identifying some important issues. I think the
> > > > point about setting PROCINFO["FS"] is also a valid one, although I doubt
> > > > that many scripts rely on this.
> > > >
> > > > Regards,
> > > > Andy
> 

-- 
Andrew Schorr                      e-mail: as...@te...
Telemetry Investments, L.L.C.      phone:  917-305-1748
152 W 36th St, #402                fax:    212-425-5550
New York, NY 10018-8765

Re: [Gawkextlib-developer] CSV parsing

[<ar...@sk...>]

Yes, bw...@cs....

Thanks,

Arnold

"Andrew J. Schorr" <as...@te...> wrote:

> Hi,
>
> OK -- I can try that if you think it's better coming from me.
> Is it best to send to the cs.princeton.edu email address?
>
> Thanks,
> Andy
>
> On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
> > I suspect that Brian doesn't really realize how badly it breaks
> > backwards compatibility, but heck, he's *Brian Kernighan*, it's
> > really hard to tell him he's making a mistake.
> > 
> > I think that if you were to compose a (polite) note introducing yourself
> > as a gawk contributor and raising some of the issues, he would
> > certainly give it attention and respond. He's very down-to-earth.
> > (You can cc me.)
> > 
> > In any case, other than perhaps allowing FS="," to be special only
> > with --compat, I don't plan any changes to the existing CSV support.
> > I want it to exactly match his awk, no more, and no less.
> > 
> > Thanks,
> > 
> > Arnold
> > 
> > "Andrew J. Schorr" <as...@te...> wrote:
> > 
> > > Hi,
> > >
> > > On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > > > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > > > is given. I'm not sure. However, it certainly doesn't do CSV if
> > > > --posix is given.)
> > >
> > > This aspect of breaking backwards compatibility concerns me.  I feel that
> > > upgrading to a new version of gawk ought not to break existing code. I tend to
> > > agree with Manuel that some additional option ought to be required to activate
> > > this new, incompatible behavior.  I don't know whether that should be --compat
> > > or --csv, although --csv seems to make more sense in terms of
> > > comprehensibility.
> > >
> > > Other than that, I think you both make good points, but I think that Brian is
> > > being injudicious in slamming in this change in a way that can break existing
> > > scripts. Has he truly thought this through?
> > >
> > > Thanks Manuel for identifying some important issues. I think the
> > > point about setting PROCINFO["FS"] is also a valid one, although I doubt
> > > that many scripts rely on this.
> > >
> > > Regards,
> > > Andy

Re: [Gawkextlib-developer] CSV parsing

[Andrew J. S. <as...@te...>]

Hi,

OK -- I can try that if you think it's better coming from me.
Is it best to send to the cs.princeton.edu email address?

Thanks,
Andy

On Tue, Mar 07, 2023 at 04:59:59AM -0700, ar...@sk... wrote:
> I suspect that Brian doesn't really realize how badly it breaks
> backwards compatibility, but heck, he's *Brian Kernighan*, it's
> really hard to tell him he's making a mistake.
> 
> I think that if you were to compose a (polite) note introducing yourself
> as a gawk contributor and raising some of the issues, he would
> certainly give it attention and respond. He's very down-to-earth.
> (You can cc me.)
> 
> In any case, other than perhaps allowing FS="," to be special only
> with --compat, I don't plan any changes to the existing CSV support.
> I want it to exactly match his awk, no more, and no less.
> 
> Thanks,
> 
> Arnold
> 
> "Andrew J. Schorr" <as...@te...> wrote:
> 
> > Hi,
> >
> > On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > > is given. I'm not sure. However, it certainly doesn't do CSV if
> > > --posix is given.)
> >
> > This aspect of breaking backwards compatibility concerns me.  I feel that
> > upgrading to a new version of gawk ought not to break existing code. I tend to
> > agree with Manuel that some additional option ought to be required to activate
> > this new, incompatible behavior.  I don't know whether that should be --compat
> > or --csv, although --csv seems to make more sense in terms of
> > comprehensibility.
> >
> > Other than that, I think you both make good points, but I think that Brian is
> > being injudicious in slamming in this change in a way that can break existing
> > scripts. Has he truly thought this through?
> >
> > Thanks Manuel for identifying some important issues. I think the
> > point about setting PROCINFO["FS"] is also a valid one, although I doubt
> > that many scripts rely on this.
> >
> > Regards,
> > Andy

Re: [Gawkextlib-developer] CSV parsing

[<ar...@sk...>]

Hi.

I suspect that Brian doesn't really realize how badly it breaks
backwards compatibility, but heck, he's *Brian Kernighan*, it's
really hard to tell him he's making a mistake.

I think that if you were to compose a (polite) note introducing yourself
as a gawk contributor and raising some of the issues, he would
certainly give it attention and respond. He's very down-to-earth.
(You can cc me.)

In any case, other than perhaps allowing FS="," to be special only
with --compat, I don't plan any changes to the existing CSV support.
I want it to exactly match his awk, no more, and no less.

Thanks,

Arnold

"Andrew J. Schorr" <as...@te...> wrote:

> Hi,
>
> On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> > (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> > is given. I'm not sure. However, it certainly doesn't do CSV if
> > --posix is given.)
>
> This aspect of breaking backwards compatibility concerns me.  I feel that
> upgrading to a new version of gawk ought not to break existing code. I tend to
> agree with Manuel that some additional option ought to be required to activate
> this new, incompatible behavior.  I don't know whether that should be --compat
> or --csv, although --csv seems to make more sense in terms of
> comprehensibility.
>
> Other than that, I think you both make good points, but I think that Brian is
> being injudicious in slamming in this change in a way that can break existing
> scripts. Has he truly thought this through?
>
> Thanks Manuel for identifying some important issues. I think the
> point about setting PROCINFO["FS"] is also a valid one, although I doubt
> that many scripts rely on this.
>
> Regards,
> Andy

Re: [Gawkextlib-developer] CSV parsing

[Andrew J. S. <as...@te...>]

Hi,

On Mon, Mar 06, 2023 at 12:08:51PM -0700, ar...@sk... wrote:
> (Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
> is given. I'm not sure. However, it certainly doesn't do CSV if
> --posix is given.)

This aspect of breaking backwards compatibility concerns me.  I feel that
upgrading to a new version of gawk ought not to break existing code. I tend to
agree with Manuel that some additional option ought to be required to activate
this new, incompatible behavior.  I don't know whether that should be --compat
or --csv, although --csv seems to make more sense in terms of
comprehensibility.

Other than that, I think you both make good points, but I think that Brian is
being injudicious in slamming in this change in a way that can break existing
scripts. Has he truly thought this through?

Thanks Manuel for identifying some important issues. I think the
point about setting PROCINFO["FS"] is also a valid one, although I doubt
that many scripts rely on this.

Regards,
Andy

Re: [Gawkextlib-developer] CSV parsing

[<ar...@sk...>]

Hi Manuel,

Thanks for the note.

I find myself in a "damned if you do and damned if you don't" situation.

Brian decided to add CSV support to his awk.  IIRC I told him that I
didn't think it was a good idea to make this change so late in the
game, but it's done. He is revising his awk book and it documents
how "awk" behaves when FS is set to ",".

As much as I dislike it, gawk needs to follow his lead; the POSIX
people will give much more weight to what he does than to what I do.

(Maybe, *maybe*, I should only allow FS="," to do CSV if --compat
is given. I'm not sure. However, it certainly doesn't do CSV if
--posix is given.)

As I have stated before, I don't want to add major new code to gawk
itself. All of your suggestions have merit, but (a) it's a ton of code
that I, personally, have no desire to write, and (b) it's a ton of code
that even if someone else writes it, I would still have to maintain,
which I also have no desire to do.

I believe that an input extension can do just about everything
you've described, and perhaps the gawkextlib csv extension already
does, I haven't looked at it in detail, or even recently.

I think I disagree about this:

| - What I think is important is to be consistent between $0 and
| $1-$NF. It is Ok to have $0 in the original CSV format and $k
| with the unquoted values. But to be consistent a $k="some value"
| assignment should put a CSV quoted "some value" in $0 instead
| of just a copy of the clean value of $k. For instance:
|
|      $1 = $1; print
|
| prints a fouled-up copy of the original record if $1
| contains commas or quotes.

$ echo 'a,"12,34",b,c,d' | ./gawk -F, '{ $1 = $1 ; print }'
a 12,34 b c d

I would not call that "fouled up". Gawk (and BWK awk) are consistent
with the behavior of $1=$1 as in any other case: the record
is reconstructed with the values of the fields separated
by OFS.

Yes, the CSV-ness of the record is lost. IMHO, too bad; this
is awk, not Excel.

In short, I agree with you -- it's a mess. But it's a compatible
mess, and I don't see a path to doing something "better" without
a lot of personal pain, for little or no personal gain.

Sorry,

Arnold

Manuel Collado <mco...@gm...> wrote:

> I've done a quick check of the new CSV feature. Maybe I've missed
> some facts.
>
> El 23/2/23 a las 15:59, Andrew J. Schorr escribió:
> > 
> > I just noticed that gawk 5.3.0 will have built-in CSV file parsing
> > to match BWK...
> > 
> > As far as I can tell, it more or less does the right thing, with one notable
> > exception: it does not support newlines embedded inside CSV fields.
>
> A good CSV support in gawk will make the gawk-csv extension
> unnecessary, as well as the CSVMODE pure gawk code library.
> But in its current state the native CSV support lacks some
> desirable features. And IMHO is a bit inconsistent.
>
> > 
> > So this raises the question of how we should best support CSV,
> > in view of Manuel's existing CSV extension.
>
> See below.
>
> > 
> > I can think of a couple of ways to leverage the new built-in CSV support:
> > 
> > 1. Submit a patch to enhance the built-in CSV support to recognize correctly
> > where records end if a special command-line option is enabled.  Arnold might
> > well reject such an approach, since his stated objective is to match BWK
> > behavior.
> > 
> > 2. Build an input parser that correcty identifies CSV records
> > and use that with the built-in CSV parser to parse the record.
> > The input parser would just need to be smart enough to ignore newlines
> > that are contained inside quotes. Maybe that's not as easy as I imagine
> > it might be...
> > 
> > Thoughts?
>
> Possible improvements:
>
> - The CSV input parsing mode is in fact a new mayor mode.
> PROCINFO["FS"] should be set to "CSV" instead of "FS".
>
> - The CSV mode should temporarily ignore RS, and use
> /\r?\n/ instead. Currently data files with MS-DOS EOLs
> give $0 with a trailing CR char.
>
> - The CSV parser could deliver lint warnings if the input record
> is not well-formed CSV (the gawk-csv extension does this).
>
> - If FS="," enables CSV parsing unconditionally, then it
> can break backward compatibility. The CSV mode should only
> be enabled by FS="," if it is previously declared as desirable.
> For instance, by a --csv="," command line option. In particular
> this option could also be used to specify an alternate delimiter
> other that comma. Like --csv=";".
>
> - What I think is important is to be consistent between $0 and
> $1-$NF. It is Ok to have $0 in the original CSV format and $k
> with the unquoted values. But to be consistent a $k="some value"
> assignment should put a CSV quoted "some value" in $0 instead
> of just a copy of the clean value of $k. For instance:
>
>      $1 = $1; print
>
> prints a fouled-up copy of the original record if $1
> contains commas or quotes.
>
> The approach used by the gawk-csv extension is to rebuild a
> consistent $0 by concatenating the clean field values delimited
> by a suitable fixed mark (OFS, or perhaps SUBSEP). The original
> CSV record is not lost, but stored in a CSVRECORD variable. If
> a new predefined variable is not acceptable, perhaps it could
> be stored in $-1. Heresy?
>
> - And a dream: in addition to a CSV input parser gawk could
> supply a CSV output writer. Enabled by OFS=",". Example:
>
>      year = 2022
>      amount = "1,234.56"
>      print year, "$ " amount
>
> could deliver
>
>      2022,"$ 1,234.56"
>
> Well, perhaps it is too late for suggesting such improvements,
> after merging the feature/bwk-csv branch into master. Anyway,
> if there is some interest I'm ready to elaborate and discuss
> those ideas as a more detailed proposal. Including suggestions for
> embedded newlines support.
>
> Regards.
> -- 
> Manuel Collado - http://mcollado.z15.es

Re: [Gawkextlib-developer] CSV parsing

[Manuel C. <mco...@gm...>]

I've done a quick check of the new CSV feature. Maybe I've missed
some facts.

El 23/2/23 a las 15:59, Andrew J. Schorr escribió:
> 
> I just noticed that gawk 5.3.0 will have built-in CSV file parsing
> to match BWK...
> 
> As far as I can tell, it more or less does the right thing, with one notable
> exception: it does not support newlines embedded inside CSV fields.

A good CSV support in gawk will make the gawk-csv extension
unnecessary, as well as the CSVMODE pure gawk code library.
But in its current state the native CSV support lacks some
desirable features. And IMHO is a bit inconsistent.

> 
> So this raises the question of how we should best support CSV,
> in view of Manuel's existing CSV extension.

See below.

> 
> I can think of a couple of ways to leverage the new built-in CSV support:
> 
> 1. Submit a patch to enhance the built-in CSV support to recognize correctly
> where records end if a special command-line option is enabled.  Arnold might
> well reject such an approach, since his stated objective is to match BWK
> behavior.
> 
> 2. Build an input parser that correcty identifies CSV records
> and use that with the built-in CSV parser to parse the record.
> The input parser would just need to be smart enough to ignore newlines
> that are contained inside quotes. Maybe that's not as easy as I imagine
> it might be...
> 
> Thoughts?

Possible improvements:

- The CSV input parsing mode is in fact a new mayor mode.
PROCINFO["FS"] should be set to "CSV" instead of "FS".

- The CSV mode should temporarily ignore RS, and use
/\r?\n/ instead. Currently data files with MS-DOS EOLs
give $0 with a trailing CR char.

- The CSV parser could deliver lint warnings if the input record
is not well-formed CSV (the gawk-csv extension does this).

- If FS="," enables CSV parsing unconditionally, then it
can break backward compatibility. The CSV mode should only
be enabled by FS="," if it is previously declared as desirable.
For instance, by a --csv="," command line option. In particular
this option could also be used to specify an alternate delimiter
other that comma. Like --csv=";".

- What I think is important is to be consistent between $0 and
$1-$NF. It is Ok to have $0 in the original CSV format and $k
with the unquoted values. But to be consistent a $k="some value"
assignment should put a CSV quoted "some value" in $0 instead
of just a copy of the clean value of $k. For instance:

     $1 = $1; print

prints a fouled-up copy of the original record if $1
contains commas or quotes.

The approach used by the gawk-csv extension is to rebuild a
consistent $0 by concatenating the clean field values delimited
by a suitable fixed mark (OFS, or perhaps SUBSEP). The original
CSV record is not lost, but stored in a CSVRECORD variable. If
a new predefined variable is not acceptable, perhaps it could
be stored in $-1. Heresy?

- And a dream: in addition to a CSV input parser gawk could
supply a CSV output writer. Enabled by OFS=",". Example:

     year = 2022
     amount = "1,234.56"
     print year, "$ " amount

could deliver

     2022,"$ 1,234.56"

Well, perhaps it is too late for suggesting such improvements,
after merging the feature/bwk-csv branch into master. Anyway,
if there is some interest I'm ready to elaborate and discuss
those ideas as a more detailed proposal. Including suggestions for
embedded newlines support.

Regards.
-- 
Manuel Collado - http://mcollado.z15.es

Re: [Gawkextlib-developer] gawk-xml: Omissions in "make html-install"

[Manuel C. <mco...@gm...>]

El 25/2/23 a las 23:10, Manuel Collado escribió:
> As with gawk, this extension also fails to install image files for .html 
> documentation (and, of course, for .info docs).
> 
> Even worse, "make install-html and "make install-pdf" abort due to the 
> lack of an "install-html" target in po/Makefile (gawk has it).

What I've tested is the gawk-xml-1.1.1 distribution. It has been 
configured with gettext 0.18. Should be reconfigured with a most recent 
version. gawk-5.2.1 uses gettext 0.20. This solves the omission of the 
"install-html" target in po/.

> 
> What puzzles me is how po/Makefile is generated. There is no 
> po/Makefile.am. And after ./configure and make there are 
> po/Makefile.in.in, po/Makefile.in and po/Makefile. Magic?

I now understand that po/Makefile.in.in is created by gettextize.

Still working on fixing these minor issues. Any advise?

Regards.

-- 
Manuel Collado - http://mcollado.z15.es

[Gawkextlib-developer] gawk-xml: Omissions in "make html-install"

[Manuel C. <mco...@gm...>]

As with gawk, this extension also fails to install image files for .html 
documentation (and, of course, for .info docs).

Even worse, "make install-html and "make install-pdf" abort due to the 
lack of an "install-html" target in po/Makefile (gawk has it).

The solutions for gawk can probably work also for gawkextlib extensions 
that use graphic image files in their documentation.

What puzzles me is how po/Makefile is generated. There is no 
po/Makefile.am. And after ./configure and make there are 
po/Makefile.in.in, po/Makefile.in and po/Makefile. Magic?

I'm working on fixing these minor issues. Any advise?

Regards.
-- 
Manuel Collado - http://mcollado.z15.es

[Gawkextlib-developer] CSV parsing

[Andrew J. S. <as...@te...>]

Hi,

I just noticed that gawk 5.3.0 will have built-in CSV file parsing
to match BWK. From the NEWS file:

Changes from 5.2.2 to 5.3.0
---------------------------

...

2. In keeping with new features in BWK awk, gawk now has built-in
   CSV file parsing. The behavior is intended to be identical to
   that of the "One True AWK", when FS = "," is applied. See the
   manual for details.


As far as I can tell, it more or less does the right thing, with one notable
exception: it does not support newlines embedded inside CSV fields.

So this raises the question of how we should best support CSV,
in view of Manuel's existing CSV extension.

I can think of a couple of ways to leverage the new built-in CSV support:

1. Submit a patch to enhance the built-in CSV support to recognize correctly
where records end if a special command-line option is enabled.  Arnold might
well reject such an approach, since his stated objective is to match BWK
behavior.

2. Build an input parser that correcty identifies CSV records
and use that with the built-in CSV parser to parse the record.
The input parser would just need to be smart enough to ignore newlines
that are contained inside quotes. Maybe that's not as easy as I imagine
it might be...

Thoughts?

Regards,
Andy

[Gawkextlib-developer] WikiTeq - Introduction

[WikiTeq <ki...@wi...>]

Everyone knows the state-of-art old-fashioned file cabinet for the library. Its "analytical" boxes and dividers, like the cards themselves, have faithfully served more than one generation of librarians. Paper cards have been a very flexible medium, allowing librarians to expand datasets and tailor records to fit their library workflows by simply making notes on the card.

 

Today, we can combine the elegant simplicity of a filing system with the functional and visual richness of modern web and data processing technologies. Each piece of data about books on the shelves, authors, publishers, readers, and dates can be stored, retrieved, linked, and used as a filter or grouping criterion for many thousands of records.

 

The solution by [WikiTeq](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/g1dwrp5gu3V5CwrIFtbnr3GSnvP2LQBPdWeZCbjSYs2DnOTQSSyzJeoWizN5bMValnJrMRgbR4Yu8kAxrYJ5ak6DtMpP7MLXAlyIPRNd28-DrYXFQRCLJc0jbwE2SKJh3xcf8LFp3jZEeTcednpT1ag5A2zT1UfNq4v7x0QIBroEGeNlu2xswUyKIL2QWdsNiM4) is based on the world-renowned open-source content management system: [MediaWiki](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/XRRS9FGJTaLz8kI_haY2mwlzhdq-FD5H6hh4MBLMGz7mNs6NxuWYnYENGhF5ldgwG_K74e4PB17l6yhLCjmojoo7QK_9iL0J7eRFrLc1woQJZmZG12_P_IZQuo3NLYyYsvqDt6G92PAULXmRh7IbfCARR1CxedvY1heKe6sY1kbznd2wZO3ZeNgL3lGqsn5r9PrNqZJa0KzjGB0QKxxYrE2-YkA), the [Wikipedia](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/DFRMct8MX6_pMtPlwLnMCxlpNE8OISN9RtgaLaRaM6Tp4SSD3QNoiGcYy65A627cIaSljWd7sLmZ9y10Nd80R7ginHFgtn0CM0IkmFrsiWrL_3jn2VYXCTSrVPuBD6B0e1unR4E6lnsSVLDm6s778upMEcL0t3G3njB2hZr_vBDiLDGc8Zf59cDG4LogKRdAmP3fj-m-YhlnHjfKstTNmcX4yg) engine. Depending on your requirements, we transform it into a library data management system by implementing extensions ([Semantic MediaWiki](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/Qic2XETpnbkAlShEjJm0vFEf-2TUoRYaBeyagCa5LlcEJ36ktENTeKopBTViFiGPQlwLIyWKFIyLHGSWJIaApgdZ1OZIyk9woppKntvF8xb8xX1e76i99Vmt1X5OzFEME1rHDJ9ZQdmY8SowaIrmyIVtNH6bzaIb5eWikum5Tw0sO_FJHP2DC77gygxWQac62zC0TWrgcb2GXfVQxCrwfdEdqSfNskW32Rm2-tMLQSmGbEnSOF8) or [Wikibase](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/6dEB5AeUftOe-jloEgyAmODf4s7Q_4OkBAun85q37I4ncIHwPqqd7X_AGG0HVY7NCWO2Ox_8KGjp63sQIXUEtqUhr2W__jKFyMe_fMzHKxQLT-Rw9UDS18fTo4GjLm4thy_o1p6st3eG_M8Omw_sJyjOJkd1IFimjbemQNlgGe_QittGJa0Rcr6frsWgTeZITsoqIiTfZjoB2uPw6fs4YOMVdQ)), input forms, analytical interfaces, and interactive reports, paying special attention to the extensibility and adaptability of the system on the user side.

 

Unlike its [closest competitors](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/MPl-VnkJmws-xx9DtiiuKnT1uPNZr5BUc_lO37Qo7KHru_N3U4UzFinULU-9t2AaK9CPiLI-jGVLgH61qk027hRLk4XNflV0WULwQ0MwXjzWEljSb0GuoFl2YqZHL8qrEIlKwCjEXcfTe8xLtGgGdPSMKRnFYUF8Ts8-emVsooRzMgbuRA2_DtJ8UZlsoaD99__T0nFbKpM7u1by0xm9AsPqLpDtsNVTVsRgfghYpPmNi9NsHEaF), MediaWiki allows a unique solution designed, tested, and implemented specifically with your organization's goals in mind. Do not hesitate to contact us to take your library processes and [knowledge management](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/97V8U76LiVanNnDsFRCjOGpRRvZFs3QhSr1s0egLQAuGc48JkjHjw82tgYKYG0iIePNxryNSBGu1amhKeBlSZ87trkoq2ZwrZIyv_MQOBlWZbuYFRbRZC-9_oO6DWHFU99VMPCbFVnZ6oiK_V3IPiZpX5_bOmbfF4I4wCY0RqOcTUaeFRnOcwtXUQpccQYOACPSi8NHqkX6c-K3RycmZaPBpLFESEqHghOw0q69i8Q7FX1q7Gg) to the next level.

 

Sincerely yours,

Kirill Klimov - WikiTeq

Technical Project Manager

[Free Consultation](https://9ffck.r.ag.d.sendibm3.com/mk/cl/f/BrjYNLvnpgxcihQzVCdv15n9MRNvp_03-jP7FJEGqCBt2il_wsbHfJKSByu8MiFsEj08hFA9Hn62hz4WP4bDr4LSosmqxDzGPH2JrqAFPknH-4CyYRPnXo8Pru8AoC_tUk-pWUaARt20--KOOroGp_DArn9YFq0Jy04-aq2Nri2khLehllfdDG4hgry3aO3ElcMwmV3Px6Jq)

[Gawkextlib-developer] [Eshop SMASH] Vaše zpráva byla v pořádku odeslána #ct674 #tcocvou9kd7Z1K

[Martina P. <in...@es...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
<html>
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<title>Zpráva z obchodu Eshop SMASH</title>
</head>
<body>
				<table class="table table-mail" style="width:100%;margin-top:10px;-moz-box-shadow:0 0 5px #afafaf;-webkit-box-shadow:0 0 5px #afafaf;-o-box-shadow:0 0 5px #afafaf;box-shadow:0 0 5px #afafaf;filter:progid:DXImageTransform.Microsoft.Shadow(color=#afafaf,Direction=134,Strength=5)">
			<tr>
				<td class="space" style="width:20px;padding:7px 0">&nbsp;</td>
				<td align="center" style="padding:7px 0">
					<table class="table" bgcolor="#ffffff" style="width:100%">
						<tr>
							<td align="center" class="logo" style="border-bottom:4px solid #333333;padding:7px 0">
								<a title="Eshop SMASH" href="https://www.eshop-smash.cz/" style="color:#337ff1">
									<img src="cid:swi...@ww..."
alt="Eshop SMASH" />
								</a>
							</td>
						</tr>

<tr>
	<td align="center" class="titleblock" style="padding:7px 0">
		<font size="2" face="Open-sans, sans-serif" color="#555454">
			<span class="title" style="font-weight:500;font-size:28px;text-transform:uppercase;line-height:33px">Va&scaron;e zpr&aacute;va z&aacute;kaznick&eacute;mu centru Eshop SMASH</span>
		</font>
	</td>
</tr>
<tr>
	<td class="space_footer" style="padding:0!important">&nbsp;</td>
</tr>
<tr>
	<td class="box" style="border:1px solid #D6D4D4;background-color:#f8f8f8;padding:7px 0">
		<table class="table" style="width:100%">
			<tr>
				<td width="10" style="padding:7px 0">&nbsp;</td>
				<td style="padding:7px 0">
					<font size="2" face="Open-sans, sans-serif" color="#555454">
						<span style="color:#777">
							Va&scaron;e zpr&aacute;va byla &uacute;spě&scaron;ně odesl&aacute;na.<br /><br />
							<span style="color:#333"><strong>Obsah zpr&aacute;vy:</strong></span> Your Síte Has Been Hacked<br
/><br />PLEASE FORWARD THíS EMAiL TO SOMEONE iN YOUR COMPANY WHO íS ALLOWED TO MAKE íMPORTANT DECíSíONS!<br /><br />We have hacked your website http://gawkextlib.sourceforge.net and extracted your databases.<br /><br />How díd thís happen?<br /><br />Our team has found a vulnerability wíthin your síte that we were able to exploít. After findíng the vulnerabílity we were able to get your database credentials and extract your entire database and move the information to an offshore server.<br /><br />What does thís mean?<br /><br />We will systematícally go through a series of steps of totally damagíng your reputation. First your database will be leaked or sold to the híghest bídder which they will use with whatever their íntentíons are. Next if there are e-maíls found they will be e-mailed that their informatíon has been sold or leaked and your site http://gawkextlib.sourceforge.net was at fault thusly damaging your reputatíon and having angry
customers/assocíates with whatever angry customers/assocíates do. Lastly any línks that you have índexed ín the search engínes wíll be de-indexed based off of blackhat techniques that we used in the past to de-índex our targets.<br /><br />How do í stop this?<br /><br />We are wíllíng to refrain from destroyíng your site’s reputatíon for a small fee. The current fee is $3000 in bítcoins (BTC).<br /><br />Please send the bítcoin to the followíng Bítcoín address (Copy and paste as ít is case sensítive): <br /><br />bc1qagnzv4tmdkhw92fsg9p85rd9ha2zte6754h73z<br /><br /> Once you have paíd we will automatícally get informed that it was your payment. Please note that you have to make payment wíthin 5 days after receivíng thís e-maíl or the database leak, e-mails díspatched, and de-índex of your site WiLL start!<br /><br />How do í get Bítcoíns?<br /><br />You can easíly buy bítcoíns vía several websites or even offline from a Bítcoin-ATM. <br /><br
/>What íf i don’t pay?<br /><br />íf you decide not to pay, we will start the attack at the índícated date and uphold it until you do, there’s no counter measure to thís, you wíll only end up wastíng more money tryíng to find a solution. We will completely destroy your reputatíon amongst google and your customers.<br /><br />This is not a hoax, do not reply to thís emaíl, don’t try to reason or negotíate, we wíll not read any replies. Once you have paíd we wíll stop what we were doing and you wíll never hear from us agaín!<br /><br />Please note that Bítcoín ís anonymous and no one will fínd out that you have complíed.<br /><br />
							<span style="color:#333"><strong>Č&iacute;slo objedn&aacute;vky:</strong></span> -<br />
							<span style="color:#333"><strong>Produkt:</strong></span> <br />
							<span style="color:#333"><strong>Př&iacute;loha:</strong></span> -
						</span>
					</font>
				</td>
				<td width="10" style="padding:7px
0">&nbsp;</td>
			</tr>
		</table>
	</td>
</tr>
<tr>
	<td class="space_footer" style="padding:0!important">&nbsp;</td>
</tr>
<tr>
	<td class="linkbelow" style="padding:7px 0">
		<font size="2" face="Open-sans, sans-serif" color="#555454">
			<span>
				Odpov&iacute;me V&aacute;m v co nejkrat&scaron;&iacute;m čase.			</span>
		</font>
	</td>
</tr>

						<tr>
							<td class="space_footer" style="padding:0!important">&nbsp;</td>
						</tr>
						<tr>
							<td class="footer" style="border-top:4px solid #333333;padding:7px 0">
								<span>Obchod <a href="https://www.eshop-smash.cz/" style="color:#337ff1">Eshop SMASH</a> funguje v syst&eacute;mu <a href="http://www.prestashop.com/" style="color:#337ff1">PrestaShop&trade;</a></span>
							</td>
						</tr>
					</table>
				</td>
				<td class="space" style="width:20px;padding:7px 0">&nbsp;</td>
			</tr>
		</table>
	

</body>
</html>

[Gawkextlib-developer] [SPAM] [Spam]Free - IMF Donation

[Kristalina (IMF) <he...@sb...>]

INTERNATIONAL MONETARY FUND (IMF)
700 19th Street, N.W.
Washington, D.C. 20431, U.S.A

Date: 9/10/2022

IMF EMPOWERMENT GRANT AND DONATION

Dear gaw...@li...,

REFERENCE: IMF/WDC/0288/1022

You have been selected to receive our individual empowerment grant.

For more information, kindly reply via email and send your reference (IMF/WDC/0288/1022) for confirmation via WhatsApp message to the IMF Public Relations Center +1 (808) 213-7133.


Yours in service,
Kristalina I. Georgieva-Kinova
Managing Director, International Monetary Fund (IMF)