bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGw port of gawkextlib


From: Eli Zaretskii
Subject: Re: MinGw port of gawkextlib
Date: Mon, 16 May 2022 19:20:40 +0300

> Date: Mon, 16 May 2022 11:55:31 -0400
> From: "Andrew J. Schorr" <aschorr@telemetry-investments.com>
> Cc: mcollado2011@gmail.com, bug-gawk@gnu.org
> 
> >   $ gawk 'BEGIN {print ENVIRON["AWKLIBPATH"]}'
> >   d:/usr/lib/gawk/ext-3.1
> > 
> > However, AWKLIBPATH is a path, not a single file name, so we could
> > have several directories in it, as in /foo/bar/:/baz/quux:whatever.
> > It is, indeed, rather unusual to have the first directory in
> > AWKLIBPATH to be a single letter, but it's possible at least in
> > principle.
> 
> In reality, gawk puts only a single path in the default AWKLIBPATH.

Yes, but users could override that, and/or someone could build Gawk
with more than one directory in the default value.

> And I think what we really want here is the built-in AWKLIBPATH, not
> what the user has in the environment. So we can protect by unsetting
> it.

It's your call which customizations to support, but in general, it
isn't unthinkable for a user to set AWKLIBPATH in the environment as a
means of organizing the extensions in some way that is meaningful for
the user.

> > In my tests I needed to remove one backslash from the "\\\1" part, and
> > then I get the expected:
> > 
> >   $ gawk 'BEGIN {print gensub(/\<([[:alpha:]]):\//, "/\\1/", "g", 
> > ENVIRON["AWKLIBPATH"])}'
> >   /d/usr/lib/gawk/ext-3.1
> > 
> > With 3 backslashes, I get a funny face (binary 01 character) instead
> > of 'd' in "/d/".  I needed to make the same change on GNU/Linux, to
> > get this to DTRT.  Any idea why the difference vs your system?  What
> > kind of shell are you using?
> 
> I could be wrong, but I think you're missing another level of back quotes
> for the command substitution. In test.makefile, we've got:
> 
> AWK = LC_ALL=$${GAWKLOCALE:-C} LANG=$${GAWKLOCALE:-C} 
> AWKLIBPATH=../.libs$(PATH_SEPARATOR)`unset AWKLIBPATH && $(GAWKPROG) 'BEGIN 
> {print gensub(/\<([[:alpha:]]):\//, "/\\\1/", "g", ENVIRON["AWKLIBPATH"])}'` 
> PATH=$(GEBINPFX)$$PATH LD_LIBRARY_PATH=$(GELIBPFX)$$LD_LIBRARY_PATH 
> DYLD_LIBRARY_PATH=$(GELIBPFX)$$DYLD_LIBRARY_PATH $(VALGRIND) $(GAWKPROG)
> 
> So please try this:
> 
> echo `unset AWKLIBPATH && gawk 'BEGIN {print gensub(/\<([[:alpha:]]):\//, 
> "/\\\1/", "g", ENVIRON["AWKLIBPATH"])}'`
> 
> For me, that seems to work, but maybe I'm confused about how GNU make is
> going to run this.

Yes, you are right: the 3 backslashes are needed because of the `..`
thingy.

> >   $ AWKLIBPATH="C:\\foo\\bar" gawk 'BEGIN {print ENVIRON["AWKLIBPATH"]}'
> >   C:\foo\bar
> > 
> > Thus the conclusion that the gensub invocation should be prepared to
> > handle any style of slashes.
> 
> As I mentioned above, I propose to ignore the AWKLIBPATH value in the
> environment. Can you think of a reason we would need that? I think it
> would be helpful only in the case where the installer had chosen to install
> previous gawk libraries in a non-default location. That seems like a corner
> case.

See above.  I could imagine someone trying to keep separate extensions
that came from different sources or lend themselves to some other
grouping.  Whether this is an important use case, I cannot tell.

> I think this is all covered by the 'unset AWKLIBPATH'. I am able to
> build successfully on linux with AWK as defined above. Are you able to
> test with the attached patch to test.makefile?

Yes, the tests pass.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]