Re: POSIXLY_CORRECT not correctly unset in getopt.m4?

[Dustin J. Mitchell]

On Tue, Sep 7, 2010 at 10:17 AM, Eric Blake <address@hidden> wrote:
>> I explained in the first email: at the beginning of the macro,
>
> Which macro?  You didn't mention that in the first email.

Oops, sorry!  gl_GETOPT_CHECK_HEADERS

> Yes, /bin/sh has two namespaces - exported vs. locally-set variables, but
> they are inter-related, effectively making variable tracking a three-state
> system.
>
>> The gnulib getopt macro then sees that POSIXLY_CORRECT is set and
>> exports it.  *That* is the bug.
>
> Not necessarily.  Generally, POSIXLY_CORRECT should be exported (not just
> set), because it should affect all children, not just the parent. I'd almost
> argue that the bug is in the outer macro (which one?) that's setting it
> locally only in the first place.

There's no outer macro that does this, it's just the shell:

bash$ echo $POSIXLY_CORRECT

bash$ /bin/sh -c 'echo $POSIXLY_CORRECT'
y
bash$ /bin/sh -c '/usr/bin/env' | grep POSIXLY

so the variable is set when bash is invoked as /bin/sh, but is not exported.

> Yes there is - unset it, then reassign (but not export) it.  The state
> transitions mandated by POSIX and honored by shells are:
>
> undefined -> local      via assignment
> undefined -> exported   via export (portable), or export + assignment
> (required by POSIX, but not portable)
> local -> exported       via export (portable), or export + assignment
> (required by POSIX, but not portable)
> local -> undefined      via unset
> exported -> undefined   via unset
>
> Some shells, like bash, provide extensions like unexport to flush out the
> remaining transitions, but portable shell code can't rely on those.

Ah, good!  That's an alternate solution, then.  So that's an alternate
solution that does not require the setenv module.

> But since setenv() is not portable, we'd have to make sure that the C code
> that plays with the variable is bullet-proof.  I find it far easier to come
> up with a solution that works using just shell code.
>
> Does the (minimally-tested) patch below work better for you?

I like the approach in this patch, but sadly it doesn't work.

This line:
+       case ${POSIXLY_CORRECT:+x}`/bin/sh -c 'echo ${POSIXLY_CORRECT:+x}'` in
does not do what you want, because the /bin/sh in the `` will re-set
POSIXLY_CORRECT.  That is, it incorrectly determines POSIXLY_CORRECT
to be exported when it is not.  I'm not sure what a portable
workaround is.  I've been using `env | grep POSIXLY_CORRECT` to check,
locally, but I don't think 'env' is very portable -- and it's probably
sometimes implemented as a shell builtin, which would defeat the
purpose.

Also, your comment says "Some people", as if this were some oddball
configuration this freaky Dustin guy is asking you to support.  This
is not my doing.  The machine I'm seeing this on is a bare-bones
Fedora 12 build machine, and it also occurs on a number of other
distros and versions.  This is arguably a bash bug, but it's in
released and widely used versions of bash, so gnulib will need to
support it.  The comment should be adjusted to reflect that.

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com