bug-gnulib
[Top][All Lists]
Advanced

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

Re: POSIXLY_CORRECT not correctly unset in getopt.m4?


From: Eric Blake
Subject: Re: POSIXLY_CORRECT not correctly unset in getopt.m4?
Date: Tue, 07 Sep 2010 12:24:38 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2

[adding bug-standards, regarding whether env is portable]

On 09/07/2010 12:11 PM, Dustin J. Mitchell wrote:
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

Aha - bash itself is setting POSIXLY_CORRECT as a local variable upon 'set -o posix'; and /bin/sh (as bash) runs with 'set -o posix' already specified.

$ bash -c 'set -o posix; echo ${POSIXLY_CORRECT:+set}'
set

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.

Oh, yeah (I did say minimally-tested ;)

> I've been using `env | grep POSIXLY_CORRECT` to check,

Hmm, env is required by POSIX, but it is not (yet) listed in the list of programs safe to use in GNU Coding Standards:

http://www.gnu.org/software/automake/manual/standards.html#Utilities-in-Makefiles

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.

Nah - even if env is a shell builtin (any example of a shell that does that, by the way?), it would still have to obey POSIX rules.


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.

Yeah, I agree that this is a more widespread issue - autoconf itself forces bash into POSIX mode (even when not invoked as /bin/sh), because it is just impossible to guarantee portability otherwise. Which does indeed mean that POSIXLY_CORRECT will _always_ appear as set when running under bash, whether or not it is exported.

Any other ideas for portable ways of detecting whether a shell variable is currently local-only or exported?

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org



reply via email to

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