* 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 3>&2; exec 2>/dev/null; unalias echo; exec 2>&3;
> exec 3>&-'
> $
>
> the indirect redirection of stderr prior to attempting t
[adding bug-autoconf for a potential optimization]
On 09/07/2010 06:14 PM, Bruno Haible wrote:
Eric Blake wrote:
$ ./gnulib-tool --help 2>&1 | 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 poin
Date: Fri, 20 Aug 2010 12:04:39 +0100
From: Reuben Thomas
To: bug-gnulib
Subject: Updated and completed patches to regex.texi
I (finally) installed these changes. Thanks much.
Eric Blake wrote:
> $ ./gnulib-tool --help 2>&1 | 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 3>&2
exec 2>/dev/null
unalias echo
exec 2>&3
exec 3>&-
?
Bruno
On Tue, Sep 7, 2010 at 4:58 PM, Eric Blake 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
* 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
---
>> Maybe the test whether the value of ENVIRON["POSIXLY_CORRECT"] is empty or
>> non-empty can be moved into the awk script. I'm not very
$ ./gnulib-tool --help 2>&1 | 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'
# comm
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 s
[ 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 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
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
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: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 ne
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:
$ 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 am
* doc/autoconf.texi (Special Shell Variables) :
Document bash behavior.
Reported by Dustin J. Mitchell, via bug-gnulib list.
Signed-off-by: Eric Blake
---
> 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' alre
[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 -
On Tue, Sep 7, 2010 at 1:10 PM, Eric Blake 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 anymore).
B
On Tue, Sep 7, 2010 at 10:17 AM, Eric Blake 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
> t
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. curl-con
On 09/07/2010 08:51 AM, Dustin J. Mitchell wrote:
On Tue, Sep 7, 2010 at 9:16 AM, Eric Blake 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 s
On Tue, Sep 7, 2010 at 9:16 AM, Eric Blake 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 appreciate the
On 09/05/2010 09:42 AM, Dustin J. Mitchell wrote:
The end of the story is that gnulib's getopt.m4 now sets
POSIXLY_CORRECT in perpetuity,
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 d
23 matches
Mail list logo
