Re: process result code in if
"A.P. Horst" writes: > I ended up using this: > if ! test $var -gt 0 > /dev/null 2>&1; then Incidentally, test should never produce any output on stdout, so you can just use "2>/dev/null" instead of "> /dev/null 2>&1"... :] -miles -- P.S. All information contained in the above letter is false, for reasons of military security. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On 7-6-2013 5:13, Miles Bader wrote: "Gary V. Vaughan" writes: On 7 Jun 2013, at 08:41, Miles Bader wrote: Wait, why can't you use "test $x -gt 0"...? You mean "test 0 -lt $x", otherwise if x starts with a hyphen (e.g -1) things will go awry! I dunno, test here (both coreutils test, and the bash builtin) seems to handle negative numbers just fine using "test $x -gt 0" ... [I suppose maybe there are broken versions of test out there, the usual issue with just about anything in autoconf... typically Sun... >< ] -miles Thanks for all the great input! Seems google isn't always your best friend, at least not when it comes to autoconf. The solution with the test command is very elegant and readable. I ended up using this: if ! test $var -gt 0 > /dev/null 2>&1; then fi This works also when something else than a number or nothing at all is given. I will try to remember autoconf also eats brackets. arie ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
"Gary V. Vaughan" writes: > On 7 Jun 2013, at 08:41, Miles Bader wrote: >> Wait, why can't you use "test $x -gt 0"...? > > You mean "test 0 -lt $x", otherwise if x starts with a hyphen (e.g -1) > things will go awry! I dunno, test here (both coreutils test, and the bash builtin) seems to handle negative numbers just fine using "test $x -gt 0" ... [I suppose maybe there are broken versions of test out there, the usual issue with just about anything in autoconf... typically Sun... >< ] -miles -- `The suburb is an obsolete and contradictory form of human settlement' ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On 7 Jun 2013, at 08:41, Miles Bader wrote: > Wait, why can't you use "test $x -gt 0"...? You mean "test 0 -lt $x", otherwise if x starts with a hyphen (e.g -1) things will go awry! Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
Wait, why can't you use "test $x -gt 0"...? -miles -- Logic, n. The art of thinking and reasoning in strict accordance with the limitations and incapacities of the human misunderstanding. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
implement workaround for header files
Hi autoconfers, I have the following case: I maintain a library that uses boost heavily. Recently I learnt that is broken with certain version of GCC (4.4.7 for example). I would like provide a workaround for users of the library (myself e.g.) so we won't even notice the breakage. I've implemented a compile test with AC_COMPILE_IFELSE that tests whether the compiler and 'exception_ptr.hpp' get along or not, but now I'm not sure what is the best way to use this test. If I wrote an application I would AC_DEFINE and whether depending on that define or not I could include a patched header file first. But since I'm writing a library and the problem is exposed in header files that are installed I'm not sure what is the best way to accomplish that. I already have a 'public_config.h' with a subset of content in 'config.h', which is installed. Yet I'm not sure what is the best way to accomplish a good solution here. If I need to install a patched boost header file, it must be hidden away so people won't include it by mistake; otherwise I might get a mob after me rightfully. Anyone having experience with this kind of workaround? I looked at gnulib but it seems focused on workarounds for end applications and not installed headers, which is slightly different. Thanks in advance. Cheers, Peter ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: test for CXXLD
On Thu, Jun 6, 2013 at 8:08 PM, Nicolas Bock wrote: > Hi, > > The C++ compiler I am using (charmc) needs an additional command line > argument during the linker stage (-language charm++). I am unsure how to > best add this argument. The generated makefiles use CXX for compilation and > CXXLD for linking, both of which are set to "charmc". How would I change > CXXLD to add a flag? Or is there a cleaner way to accomplish this? > One way would be to pass in the flags on the command line when you invoke make, e.g. "make CXXLDFLAGS='-language charm++'". Ideally autoconf would set CXXLD correctly for you but it looks like it this hasn't been implemented for this compiler. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
test for CXXLD
Hi, The C++ compiler I am using (charmc) needs an additional command line argument during the linker stage (-language charm++). I am unsure how to best add this argument. The generated makefiles use CXX for compilation and CXXLD for linking, both of which are set to "charmc". How would I change CXXLD to add a flag? Or is there a cleaner way to accomplish this? Thanks already, nick ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On 6 June 2013 13:41, Eric Blake wrote:
> > A more robust, (and more portable), formulation may be:
> >
> > echo $var | grep '^+\{0,1\}[0-9]\{1,\}$' > /dev/null 2>&1
>
> Why fork, when straight shell will do?
>
> case $var in
> ...
>
Agreed, avoiding the fork is a good idea, and I do often use case
statements myself, much as you suggest, (although it may be considered
a less obvious solution).
My point was more that the OP's use of grep didn't use a particularly
effective expression for his (perceived) task, and that his use of
grep options wasn't portable.
--
Regards,
Keith.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
- Original Message -
>
> A more robust, (and more portable), formulation may be:
>
> echo $var | grep '^+\{0,1\}[0-9]\{1,\}$' > /dev/null 2>&1
Why fork, when straight shell will do?
case $var in
+*) tmp=$var ;;
*) tmp=+$var ;;
esac
case $tmp in
+*[!0-9]* | +) echo "not numeric" ;;
*) echo integer ;;
esac
Again, when placing this in autoconf.ac, you need to quote the
[0-9] since m4 eats one level of [], either by writing [[0-9]]
in place, or by using [] around the entire case snippet.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On 6 June 2013 12:54, Keith Marshall wrote:
> On 6 June 2013 12:12, Earnie Boyd wrote:
>
>> On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote:
>> > Also when I just have:
>> > echo "$var" | grep -Eq '^[0-9]+$'
>> > ...
>>
>> How is the var variable set? If you're using the output of a compiled
>> program, I'm guessing the issue is CRLF versus just LF. ...
>>
>
> Another (more likely) possibility is that the shell fragment is under
> quoted, where it appears in configure.ac. ...
>
BTW, even when you've corrected the under quoting issue, this
echo $var | grep -Eq '^[0-9]+$'
test that $var represents a positive integer doesn't really "cut the
mustard"; there are two reasons:
1) It completely neglects to consider any initial unary + sign, so
would reject any representation such as var=+50
2) grep -Eq ... is not portable; not all implementations of grep support
GNU grep's -E and -q options.
A more robust, (and more portable), formulation may be:
echo $var | grep '^+\{0,1\}[0-9]\{1,\}$' > /dev/null 2>&1
--
Regards,
Keith.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On 6 June 2013 12:12, Earnie Boyd wrote: > On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote: > > Also when I just have: > > echo "$var" | grep -Eq '^[0-9]+$' > > echo "$?" > -->8-- > > I am on a win7 x64 machine with MinGW 3.20 and W32API 3.17 > > sh --version > > GNU bash, version 3.1.17(1)-release (i686-pc-msys) > > How is the var variable set? If you're using the output of a compiled > program, I'm guessing the issue is CRLF versus just LF. MSYS will not > remove the CR from the variable. Add the /mingw/lib/binmode.o to the > compiled program or use _setmode on stdout to make it _O_BINARY. > http://msdn.microsoft.com/en-us/library/tw4k6df8(v=vs.110).aspx > > Another (more likely) possibility is that the shell fragment is under quoted, where it appears in configure.ac. Look for that fragment in the generated configure script: I suspect you may find that the [] surrounding the [0-9] expression have been swallowed by autoconf; (they are the autoconf quoting characters. -- Regards, Keith. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: process result code in if
On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote: > Also when I just have: > echo "$var" | grep -Eq '^[0-9]+$' > echo "$?" -->8-- > I am on a win7 x64 machine with MinGW 3.20 and W32API 3.17 > sh --version > GNU bash, version 3.1.17(1)-release (i686-pc-msys) How is the var variable set? If you're using the output of a compiled program, I'm guessing the issue is CRLF versus just LF. MSYS will not remove the CR from the variable. Add the /mingw/lib/binmode.o to the compiled program or use _setmode on stdout to make it _O_BINARY. http://msdn.microsoft.com/en-us/library/tw4k6df8(v=vs.110).aspx -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
process result code in if
Hi, I am trying to do a simple check to validate a value is a positive integer. There are many variations to do this but in general this should do the trick: var=100 if echo "$var" | grep -Eq '^[0-9]+$' > /dev/null 2>&1; then echo "positive integer" else echo "something else" fi if I put this in a file and execute it, it works as expected. But if I put it in my configure.ac, it doesn't work! Also when I just have: echo "$var" | grep -Eq '^[0-9]+$' echo "$?" the 'normal' script prints "0" if var is set to an integer and "1" when set to something else. But the configure script prints "1" no matter what I set var to. I must be missing out on something because I took this construct from another configure.ac which worked just fine. I am on a win7 x64 machine with MinGW 3.20 and W32API 3.17 sh --version GNU bash, version 3.1.17(1)-release (i686-pc-msys) Arie ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
