Re: Patch to check for required programs when building from source checkout
Eric Blake wrote:
According to Pádraig Brady on 10/21/2008 4:04 PM:
echo $ver | sed '
s/^\([0-9]\{,\}\)\.\([0-9]\{,\}\)[.0]*$/\1.\2.0/; #1.10 -
1.10.0
s/^\([0-9]\{,\}\)\.\([0-9]\{,\}\)\([a-z]\)/\1.\2.99\3/; #1.10a -
1.10.99a
For what it's worth, Autoconf does this by converting \([0-9]+\)\([a-z]+\)
to \1+1, -1, radix36(\2). In other words, 1.10a becomes 1.11.-1.10.
- From there, it is a simple numerical comparison, supplying a 0 for any
implicit field, and declaring results at the left-most field that differs:
1.10.x 1.11.-1.x, but 1.11.-1 1.11.0
Hmm. Since bootstrap requires the existence of autoconf, why not just use
autoconf, instead of reimplementing this in sed?
echo 'm4_divert(0)m4_version_compare('$ver,$prereq')' \
| autom4te --language=m4sugar -
outputs -1 if $ver is smaller, 0 if equal, 1 if greater than $prereq.
Cool tip, thanks!
There's a bit of a chicken and egg scenario here though :)
bootstrap does call autoconf but it doesn't explicitly depend on it.
Also if I use the above then I need to special case autoconf checking
which further complicates things. So leaving as is for now,
but I'll think more about it. If we want to be fully compatible
with old version format checking, then I agree we should not use sed,
and use something like:
#-1 if $ver1 $ver2
# 0 if $ver1 = $ver2
# 1 if $ver1 $ver2
#-2 on error
version_compare() {
ver1=$1
ver2=$2
echo m4_divert(0)m4_version_compare($ver1,$ver2) |
autom4te --language=m4sugar - 2/dev/null || echo -2
}
latest version is attached
(minor tweaks compared to previous).
cheers,
Pádraig.
From b9e5fe8076e7a55f152e5ffbd841310ba4994838 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Tue, 21 Oct 2008 22:40:12 +0100
Subject: [PATCH] Add better checks and docs for build tools
Prompted by a report from Ed Avis:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14710
* README-hacking: Organise LZMA and Valgrind as
as optional requirements rather than in their own sections.
Mention bootstrap will now check tool versions.
* README-prereq: Make a start on specific instructions
for optaining build tools. Currently we just have notes
for Fedora linux.
* bootstrap.conf: Add the list of tools and versions required.
* bootstrap: Add the logic to check for the required tools,
and list all required tools and versions if any are missing.
---
README-hacking | 35 +-
README-prereq | 30 +++
bootstrap | 86
bootstrap.conf | 17 +++
4 files changed, 154 insertions(+), 14 deletions(-)
create mode 100644 README-prereq
diff --git a/README-hacking b/README-hacking
index 2e3c83a..f51bb01 100644
--- a/README-hacking
+++ b/README-hacking
@@ -8,8 +8,8 @@ These requirements do not apply when building from a distribution tarball.
We've opted to keep only the highest-level sources in the GIT repository.
This eases our maintenance burden, (fewer merges etc.), but imposes more
requirements on anyone wishing to build from the just-checked-out sources.
-For example, you have to use the latest stable versions of the maintainer
-tools we depend upon, including:
+Specific tools and versions will be checked for and listed by the
+bootstrap script shown below, and will include:
- Automake http://www.gnu.org/software/automake/
- Autoconf http://www.gnu.org/software/autoconf/
@@ -22,13 +22,15 @@ tools we depend upon, including:
- Rsync http://samba.anu.edu.au/rsync/
- Tar http://www.gnu.org/software/tar/
-Valgrind http://valgrind.org/ is also highly recommended, if
-Valgrind supports your architecture.
-
Only building the initial full source tree will be a bit painful.
Later, a plain `git pull make' should be sufficient.
-* LZMA
+- Valgrind
+
+Valgrind http://valgrind.org/ is also highly recommended, if
+Valgrind supports your architecture. See also README-valgrind.
+
+- LZMA
This package's build procedure uses LZMA to create a compressed
distribution tarball. Using this feature of Automake requires
@@ -40,23 +42,24 @@ from http://tukaani.org/lzma/.
You can get a copy of the source repository like this:
- $ git clone git://git.sv.gnu.org/coreutils
+$ git clone git://git.sv.gnu.org/coreutils
+$ cd coreutils
-The next step is to get other files needed to build, which are
-extracted from other source packages:
+The next step is to get and check other files needed to build,
+which are extracted from other source packages:
- $ ./bootstrap
+$ ./bootstrap
And there you are! Just
- $ ./configure
- $ make
- $ make check
+$ ./configure
+$ make
+$ make check
At this point, there should be no difference between your local copy,
and the GIT master copy:
- $ git diff
+$ git diff
should output no difference.
@@ -78,3 +81,7 @@ GNU General Public License for more details.
You
pwd doesn't support -L or -P
These two switches are necessary for POSIX compatibility. I note that bash's pwd does support them; is the intention that bash's built-in pwd, which does, should fill this gap in a GNU system? -- http://rrt.sc3d.org/ | Quidquid latine dictum sit, altum viditur (Anon) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: pwd doesn't support -L or -P
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Reuben Thomas on 10/22/2008 6:08 AM: These two switches are necessary for POSIX compatibility. I note that bash's pwd does support them; is the intention that bash's built-in pwd, which does, should fill this gap in a GNU system? It simply means that no one has ever written the patch to supply them. Would you care to try? I tried, several years ago (the mailing list archives documents my initial attempt), but I abandoned the effort at that time when I realized that we couldn't necessarily rely on $PWD to be accurate, and that the gnulib path canonicalization routines didn't have a handy way to remove ./ and ../ elements from a bogus $PWD. But yes, you generally use the shell's builtin pwd anyway, so it's nice that bash already supplies these options. As for the fact that POSIX requires pwd to default to -L, but coreutils defaults to -P, I'm not sure whether we would be breaking the large number of scripts that have come to rely on /bin/pwd supplying -P semantics. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj/GUQACgkQ84KuGfSFAYAF7QCeM7YJZMPVxFVFQUKF2Fe0MUdb /CEAoMGh4/wMx7Cz+Rumjx8vuWj9PDjO =X5rW -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: pwd doesn't support -L or -P
Here's a suggestion that would be a lot simpler to implement: have pwd implement -P as a no-op, and document the lack of -L, and the conflict with the POSIX default behaviour. I'd be happy to write a documentation patch. That will enlighten users; if anyone cares enough about coreutils's pwd supporting -L (I don't) then they can code it. -- http://rrt.sc3d.org/ | Psalms 19:12 -- tagline for the guilty ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Patch to check for required programs when building from source checkout
Pádraig Brady [EMAIL PROTECTED] wrote: ... latest version is attached (minor tweaks compared to previous). From b9e5fe8076e7a55f152e5ffbd841310ba4994838 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED] Date: Tue, 21 Oct 2008 22:40:12 +0100 Subject: [PATCH] Add better checks and docs for build tools Prompted by a report from Ed Avis: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14710 * README-hacking: Organise LZMA and Valgrind as as optional requirements rather than in their own sections. Mention bootstrap will now check tool versions. * README-prereq: Make a start on specific instructions for optaining build tools. Currently we just have notes for Fedora linux. * bootstrap.conf: Add the list of tools and versions required. * bootstrap: Add the logic to check for the required tools, and list all required tools and versions if any are missing. Looks good. Please push it. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] : ls: clarify documentation of exit statuses
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Good thing I tried to compile before pushing! The above lacks \n\ on the 0 if OK line. It's also lacking a close-parenthesis in the text. Also, that wording is a bit verbose for my taste; the verbosity makes it a bit hard to see the exit-status pattern. How about this more-concise version? 2008-10-16 Paul Eggert [EMAIL PROTECTED] * src/ls.c (usage): Describe exit statuses more concisely. diff --git a/src/ls.c b/src/ls.c index ea35b17..34e43ed 100644 --- a/src/ls.c +++ b/src/ls.c @@ -4532,10 +4532,8 @@ colors, and can be set easily by the dircolors command.\n\ \n\ Exit status:\n\ 0 if OK,\n\ - 1 if minor problems (e.g., failure to access a file or directory not\n\ -specified as a command line argument,\n\ - 2 if serious trouble (e.g., memory exhausted, invalid option or failure\n\ -to access a file or directory specified as a command line argument).\n\ + 1 if minor problems (e.g., cannot access subdirectory),\n\ + 2 if serious trouble (e.g., cannot access command-line argument).\n\ ), stdout); emit_bug_reporting_address (); } I've just pushed that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils] coreutils-7.0 expr exposes long-standing bug in matlab startup script
Hello, Eric Blake is correct. I glossed over a short paragraph in the Open Group standard doc page for 'expr' at the end of the 'Application Usage' section where there is a statement that permits something like '-1' to look like an option not the integer, '-1'. This means that the MATLAB startup shell script is indeed not Open Group compliant. Obviously, no change will be necessary to the script if the proposed fixes are approved, as they appear to be. However, this non-compliance is somewhat of a concern and a minimum time frame for a fix has been established, but the actual details still need to be worked out. Sincerely, Martin Knapp-Cordes --- | Martin Knapp-Cordes [EMAIL PROTECTED] | | The MathWorks, Inc. http://www.mathworks.com | | 3 Apple Hill DriveNatick, MA 01760| | Tel: (508) 647-7321 Fax: (508) 647-7015 | --- [THREAD ID: 1-7QTC1H] On Tue, 21 Oct 2008, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Martin Knapp-Cordes on 10/21/2008 8:31 AM: Hello, I would like to respond to any earlier claim made that there is a long-standing bug in matlab startup script. We at the MathWorks disagree. Unfortunately, your disagreement is due to your misinterpretation of POSIX. Please observe the following by reading carefully the online documentation for the Open Group Standard, UNIX Version 3, expr command. The POSIX standard is subsumed under this standard. (IEEE Std 1003.1, 2004 edition) http://www.unix.org/version3 You will have to sign in to look at the standard. Several members of this list are also members of the Austin Group, responsible for the very pages you are quoting. In particular: 1. There are NO options allowed in the expr command. 2. A string argument is an argument that cannot be identified as an integer argument or as one of the expression operator symbols ... http://www.opengroup.org/onlinepubs/009695399/utilities/expr.html Also note that this volume of IEEE Std 1003.1-2001 permits implementations to extend utilities. The expr utility permits the integer arguments to be preceded with a unary minus. This means that an integer argument could look like an option. Therefore, the conforming application must employ the -- construct of Guideline 10 of the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines to protect its operands if there is any chance the first operand might be a negative integer (or any string with a leading minus). many scripts out there assume that expr -1 + 1 evaluates to zero. And coreutils has been patched, so that the next version will once again restore this behavior, AS AN EXTENSION to POSIX (since no POSIX-conforming app will ever invoke expr in this manner). This is NOT an assumption. It is the REQUIRED behavior in order to be a STANDARD conforming shell script. No, the standard REQUIRES that an application support -- as an argument separator for all except a small set of exceptions (think echo), and expr is not in the set of exceptions. It also REQUIRES that compliant apps use - -- if they are passing an argument that might be interpreted as an option by someone that extends the standard. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj+JzgACgkQ84KuGfSFAYAPUwCfRyQkYBCqWFDNndcpCnx/Sesz yCoAoKoa4qOB9XXSVXqmbBaUXVn8iYvX =4Yva -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils] coreutils-7.0 expr exposes long-standing bug in matlab startup script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Martin Knapp-Cordes on 10/22/2008 12:17 PM: This means that the MATLAB startup shell script is indeed not Open Group compliant. Obviously, no change will be necessary to the script if the proposed fixes are approved, as they appear to be. However, this non-compliance is somewhat of a concern and a minimum time frame for a fix has been established, but the actual details still need to be worked out. As pointed out earlier in this thread, and also in http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Usual-Tools, expr X$string : X'regex' coupled with any necessary postprocessing to account for the leading X, provides a portable solution for the case when $string starts with -, across ALL known implementations of expr (whether or not they obey the POSIX rules to honor --, and whether or not they provide options as extensions to POSIX). In the case of numeric analysis, you can use a leading '0 +' to avoid problems with interpreting a negative number as an option. And finally, in the particular example that started this thread: if [ `expr $lscmd : '.*-.*'` -ne 0 ]; then # do stuff here... fi can be rewritten as the following faster alternative (completely avoiding a fork, and any expr bugs, altogether): case $lscmd in *'-'* ) ;; *) # do stuff here... ;; esac - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj/6BUACgkQ84KuGfSFAYB5OgCeKQfVV0SY9ktVq5VCSIaSNj7F 5+sAnR7Sgmg/WZOJ+fXSLEKUpPVSUcSQ =hKqD -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
