[Top][All Lists]
[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
- Re: POSIXLY_CORRECT not correctly unset in getopt.m4?,
Eric Blake <=