bug-gawk
[Top][All Lists]
Advanced

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

Re: [bug-gawk] empty AWK*PATH inconsistency


From: Aharon Robbins
Subject: Re: [bug-gawk] empty AWK*PATH inconsistency
Date: Sun, 12 Oct 2014 15:25:29 +0300
User-agent: Heirloom mailx 12.5 6/20/10

Hi Andy.

> Date: Mon, 6 Oct 2014 13:03:32 -0400
> From: "Andrew J. Schorr" <address@hidden>
> To: address@hidden
> Cc: Aharon Robbins <address@hidden>
>
> Hi,
>
> In comp.lang.awk, Kenny McCormack noted an inconsistency in how AWKPATH
> and AWKLIBPATH (henceforth called AWK*PATH) are handled.
>
> When you set AWK*PATH="" in the environment, the logic in io.c to find code
> decides that it should use the default value, since the value from the
> environment is empty.  But when ENVIRON["AWK*PATH"] is created in main.c, it
> inserts the default value only when AWK*PATH is entirely missing from the
> environment.  In other words, there's some inconsistency about how to handle
> the case when AWK*PATH is present in the environment, but equals the empty
> string.  This behavior appears to be very old.  The documentation does not
> appear to me to explain this behavior.
>
> Basically, there are 3 cases:
>    1. AWK*PATH not in environment -> use the default path
>    2. AWK*PATH in environment but equal to the empty string -> ?
>    3. AWK*PATH set and not empty -> use the environment value
>
> We are currently inconsistent about how we handle case #2.  So the
> first task is to decide how it should be handled.  If we want to 
> use the default value, then we should update the docs and ENVIRON
> setup to reflect that.
>
> There's also a question of whether the current working directory (cwd) should
> be searched automatically or not.  At the moment, the cwd is searched
> before AWKPATH, but not before AWKLIBPATH.
>
> In private communication, Arnold suggested having this discussion on the
> bug list.
>
> On Mon, Oct 06, 2014 at 07:15:55PM +0300, Aharon Robbins wrote:
> > AWKPATH was added at 2.10. From the code that I have for that, if
> > AWKPATH was empty, it continued to use the default value. I think that was
> > more of a "don't assign a null pointer to the path search variable" decision
> > than a "use the default if AWKLIBPATH is empty" decision but it was long
> > enough ago that I can't say 100% for sure.
> >
> > I agree that AWKPATH and AWKLIBPATH should behave identically.
> >
> > I think that gawk should always check "." before running the path search.
> >
> > A case could be made that if AWKPATH is in the env but empty that gawk
> > should not do a path search.  OTOH, it's been the way it is for 20+ years.
>
> I'm less certain that we should always check "." before searching AWKLIBPATH.
> While this is intuitive behavior for AWKPATH source code, it seems not so
> obvious to me for binary shared libraries.
>
> Thoughts?
>
> Regards,
> Andy

This whole business is a mess.  The behavior has evolved considerably.

2.10:   If AWKPATH exists but = "", use the default path
        Don't search "." if AWKPATH search fails, except on MS-DOS

3.1.8:  If AWKPATH exists but = "", use the default path
        If AWKPATH search fails, do try in "."

4.1.1:  If AWKPATH exists but = "", use the default path
        Explicitly search "." before trying AWKPATH.

Currently the default value for AWKPATH is ".$(PATH_SEPARATOR)$(pkgdatadir)",
set from Makefile.am.

I think that what should be done is:

1) If AWKPATH exists but = "", use the default path
2) Since it has been that way since forever, don't change it, but do
   document it.
3) Remove the code that always tries "." first. As another note pointed out,
   there may be security problems here.
4) Leave the current default which includes ".", as is.
5) Revise the doc appropriately.

6) AWKLIBPATH has a default that does not include ".". Leave that as is.
7) Make sure that if AWKLIBPATH exists but is "", gawk also uses the default,
   for consistency with AWKPATH.
8) Revise the doc appropriately.

9) In both cases, make sure that ENVIRON is set correctly.

Most of the work is in the documentation, but there are some
changes needed in the code.

Are you up to tackling this and submitting a patch for review?

If not, I'll get to it.

Thanks,

Arnold



reply via email to

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