On Tue, Sep 7, 2010 at 9:16 AM, Eric Blake ebl...@redhat.com wrote:
Thanks for the report. However, I fail to see how getopt.m4 sets
POSIXLY_CORRECT in perpetuity, because it is immediately followed by
AS_UNSET if it was determined that POSIXLY_CORRECT was not set prior to the
test. While I
On 09/07/2010 08:51 AM, Dustin J. Mitchell wrote:
On Tue, Sep 7, 2010 at 9:16 AM, Eric Blakeebl...@redhat.com wrote:
Thanks for the report. However, I fail to see how getopt.m4 sets
POSIXLY_CORRECT in perpetuity, because it is immediately followed by
AS_UNSET if it was determined that
On 09/05/2010 09:42 AM, Dustin J. Mitchell wrote:
I just had a very long chase for a new build error that began after a
recent gnulib upgrade. Briefly, the symptoms were that an invocation
of
curl-config --libs
was returning nothing when run by configure on systems with older
curls.
On Tue, Sep 7, 2010 at 10:17 AM, Eric Blake ebl...@redhat.com 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
On Tue, Sep 7, 2010 at 1:10 PM, Eric Blake ebl...@redhat.com wrote:
By the way, you should report this as a bug in curl-config; it should be
calling:
pkg-config --libs libcurl
to be safe to things like POSIXLY_CORRECT.
It's already fixed in newer versions (it doesn't call pkg-config at
all
[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 -
* doc/autoconf.texi (Special Shell Variables) POSIXLY_CORRECT:
Document bash behavior.
Reported by Dustin J. Mitchell, via bug-gnulib list.
Signed-off-by: Eric Blake ebl...@redhat.com
---
Aha - bash itself is setting POSIXLY_CORRECT as a local variable upon
'set -o posix'; and /bin/sh (as
On 09/07/2010 02:09 PM, Bruno Haible wrote:
$ env | grep POSIXLY_CORRECT
POSIXLY_CORRECT=1
$ echo ${POSIXLY_CORRECT+set}
Any other ideas for portable ways of detecting whether a shell variable
is currently local-only or exported?
'printenv' does not exist on Solaris.
But 'awk' is
Eric Blake wrote:
env is required by POSIX, but it is not (yet) listed in the list of
programs safe to use in GNU Coding Standards
And 'env' would not help much, because its output can easily be confused
by environment variable values that contain newlines:
$ foo='not
POSIXLY_CORRECT=1'
On 09/07/2010 02:09 PM, Bruno Haible wrote:
Eric Blake wrote:
env is required by POSIX, but it is not (yet) listed in the list of
programs safe to use in GNU Coding Standards
And 'env' would not help much, because its output can easily be confused
by environment variable values that contain
Hi Eric,
* Eric Blake wrote on Tue, Sep 07, 2010 at 10:13:49PM CEST:
POSIX guarantees that
awk supplies ENVIRON; are we assuming that this is reasonable
portable to all the old-and-crusty vendor implementations out there,
since the autoconf manual doesn't state otherwise?
No. /bin/awk on
On 09/07/2010 02:34 PM, Ralf Wildenhues wrote:
Hi Eric,
* Eric Blake wrote on Tue, Sep 07, 2010 at 10:13:49PM CEST:
POSIX guarantees that
awk supplies ENVIRON; are we assuming that this is reasonable
portable to all the old-and-crusty vendor implementations out there,
since the autoconf manual
On 09/07/2010 02:09 PM, Bruno Haible wrote:
But 'awk' is among the list of portable programs. This should work:
if test `awk 'BEGIN { print ENVIRON[POSIXLY_CORRECT] }' /dev/null | wc
-c` = 1; then
: # POSIXLY_CORRECT is not exported
else
: # POSIXLY_CORRECT is exported
fi
[ let's drop at least bug-standards ]
* Eric Blake wrote on Tue, Sep 07, 2010 at 10:38:52PM CEST:
More precisely, does AC_PROG_AWK guarantee us an awk that will
understand ENVIRON?
I think so, yes.
Cheers,
Ralf
On 09/07/2010 03:05 PM, Ralf Wildenhues wrote:
[ let's drop at least bug-standards ]
* Eric Blake wrote on Tue, Sep 07, 2010 at 10:38:52PM CEST:
More precisely, does AC_PROG_AWK guarantee us an awk that will
understand ENVIRON?
I think so, yes.
After further testing, I'm starting to think
$ ./gnulib-tool --help 21 | head -n3
alias: Not found
unalias: Not found
Usage: gnulib-tool --list
Using a more detailed trace, I see:
# Because of this, we have to play strange tricks with have_echo, to ensure
# that the top-level statement containing the test starts after the 'alias'
#
* m4/getopt.m4 (gl_GETOPT_CHECK_HEADERS): Restore pre-existing
export state of POSIXLY_CORRECT.
Reported by Dustin J. Mitchell.
Signed-off-by: Eric Blake ebl...@redhat.com
---
Maybe the test whether the value of ENVIRON[POSIXLY_CORRECT] is empty or
non-empty can be moved into the awk script.
On Tue, Sep 7, 2010 at 4:58 PM, Eric Blake ebl...@redhat.com wrote:
In complete patch form. I'll be pushing this soon, after more
testing completes.
This looks great, and works for me. Thanks!
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
Eric Blake wrote:
$ ./gnulib-tool --help 21 | head -n3
alias: Not found
unalias: Not found
Usage: gnulib-tool --list
What happens if you replace the command
unalias echo 2/dev/null
with
exec 32
exec 2/dev/null
unalias echo
exec 23
exec 3-
?
Bruno
Date: Fri, 20 Aug 2010 12:04:39 +0100
From: Reuben Thomas r...@sc3d.org
To: bug-gnulib bug-gnulib@gnu.org
Subject: Updated and completed patches to regex.texi
I (finally) installed these changes. Thanks much.
[adding bug-autoconf for a potential optimization]
On 09/07/2010 06:14 PM, Bruno Haible wrote:
Eric Blake wrote:
$ ./gnulib-tool --help 21 | head -n3
alias: Not found
unalias: Not found
Usage: gnulib-tool --list
What happens if you replace the command
unalias echo 2/dev/null
The point
* Eric Blake wrote on Wed, Sep 08, 2010 at 03:12:48AM CEST:
$ /bin/sh -c 'alias 2/dev/null'
alias: Not found
$ /bin/sh -c '(alias) 2/dev/null'
$ /bin/sh -c 'exec 32; exec 2/dev/null; unalias echo; exec 23;
exec 3-'
$
the indirect redirection of stderr prior to attempting the unfound
22 matches
Mail list logo
