[coreutils] Re: new branch in gnulib: coreutils-8.9
Hi Jim, * Jim Meyering wrote on Tue, Jan 04, 2011 at 07:14:49PM CET: > In releasing coreutils-8.9, I left its gnulib submodule pointing at a > private commit that was going to be pushed, pending an ACK... Since a > slightly different commit was pushed, coreutils' submodule SHA1 was > invalid for a short interval. However, I have pushed my local commit > to the new gnulib branch named "coreutils-8.9". With that, anyone > cloning coreutils and trying to build from the 8.9 tag *will* get a > usable gnulib hierarchy. FYI, this would have also been a good point at which you could have merged the commit used for coreutils into the gnulib master branch. Even a fake merge 'git merge -s ours coreutils-8.9' would be appropriate, if the end result is semantically that the effects of your patch are incorporated in the tree. You could still do this. That way, the next update of gnulib as coreutils submodule could still be a fast-forward. Cheers, Ralf
Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f
* Jim Meyering wrote on Sun, Nov 07, 2010 at 12:22:13PM CET: > Ralf Wildenhues wrote: > > * Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: > >> Ralf Wildenhues wrote: > >> > - Posix does not require IFS to be set upon script startup. It only > >> > requires > >> > that, if IFS is unset, word splitting ought to behave as if it were set > >> > to > >> > space, tab, and newline, in that order. That is why the startup code of > >> > all > >> > autotools scripts explicitly sets IFS, so that saving and restoring > >> > works. > >> > >> Thanks. That's good to know, but it appears not to be an issue > >> for any shell that gets past the init.sh tests. > > > > Are you sure? It affects any test that saves and restores IFS in any > > way. > Do you know of a modern shell that acts as you describe? > I've run the following on a decent selection of systems, > and saw no failure: Some version of dash did that, IIRC. A wild guess would be RH 6 (yes, quite a while ago, I haven't come across it again since). Point is that Posix allows the behavior. > If some shell does fail, perhaps init.sh should use a patch like the > following. > I hesitate to add code like this, unless there's at least one > known system where it makes a difference. The fix looks good to me. Thanks, Ralf > --- a/tests/init.sh > +++ b/tests/init.sh > @@ -330,6 +330,12 @@ setup_() > || fail_ "failed to create temporary directory in $initial_cwd_" >cd "$test_dir_" > > + # As autoconf-generated configure scripts do, ensure that IFS is defined > + # initially, so that saving and restoring $IFS works. > + gl_init_sh_nl_=' > +' > + IFS=" "" $gl_init_sh_nl_" > + ># This trap statement, along with a trap on 0 below, ensure that the ># temporary directory, $test_dir_, is removed upon exit as well as ># upon receipt of any of the listed signals. >
Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f
* Jim Meyering wrote on Sat, Nov 06, 2010 at 06:14:05PM CET: > Ralf Wildenhues wrote: > > - Posix does not require IFS to be set upon script startup. It only > > requires > > that, if IFS is unset, word splitting ought to behave as if it were set to > > space, tab, and newline, in that order. That is why the startup code of all > > autotools scripts explicitly sets IFS, so that saving and restoring works. > > Thanks. That's good to know, but it appears not to be an issue > for any shell that gets past the init.sh tests. Are you sure? It affects any test that saves and restores IFS in any way. Cheers, Ralf
Re: [coreutils] Re: Builds of coreutils-8.6.19-1369f
Hello,
* Jim Meyering wrote on Sat, Nov 06, 2010 at 02:55:47PM CET:
> Jim Meyering wrote:
> > Andreas Schwab wrote:
> >> Jim Meyering writes:
> >>> cat <<\EOF > init.cfg
> >>> f()
> >>> {
> >>> case $IFS in '') exit 91;; esac
> >>> local s=$IFS
> >>> case $s in '') exit 97;; esac
> >>> }
> >>> f
> >>> EOF
> >>> $ /bin/sh -c '. init.cfg'
> >>> [Exit 97]
> >>
> >> Perhaps local isn't really the builtin local?
> Subject: [PATCH] init.sh: disqualify FreeBSD 8.1's /bin/sh
>
> * tests/init.sh: Arrange not to accept FreeBSD 8.1's /bin/sh, since
> it fails this test: /bin/sh -c 'f(){ local s=$IFS; test -n "$s"; }; f'
> @@ -115,6 +118,7 @@ fi
> # ? - not ok
> gl_shell_test_script_='
> test $(echo y) = y || exit 1
> +gl_local_test_(){ local s=$IFS; test -n "$s"; }; gl_local_test_ || exit 1
There may be two issues at work here:
- there is no requirement that sh does not white-space-split the right hand
side of a 'local' assignment, 'local' isn't standardized anywhere. At least
one version of dash is guilty here.
- Posix does not require IFS to be set upon script startup. It only requires
that, if IFS is unset, word splitting ought to behave as if it were set to
space, tab, and newline, in that order. That is why the startup code of all
autotools scripts explicitly sets IFS, so that saving and restoring works.
Cheers,
Ralf
[coreutils] debbugs
[ sorry for the xpost; please followup to the automake list, replyto set ] Hello coreutils developers, Gary was nice to point us at the debbugs you're using now for your bugs list. How do you like it, how's it working for you, it can be worked with email only, right? Automake has its Gnats, mostly unused and feature-poor, I don't like it much, and with Libtool, we've never been able to consistently use a bug tracker, either. The Savannah bug/patch tracker require lots of clicking and waiting for web scripts to ponder, that's not so much fun. Also, the number of unresolved bugs in autotools packages tends to infinity in the long run (not monotonically, but let's be honest, there are always more issues than we can address, be they bugs in the autotools themselves or in the way users use them, or in third-party packages). With that in mind, I'm looking for something that can keep things in order in some way, be that things added by users or ourselves. Who do we talk to if we want to try it out? Thanks, Ralf
[coreutils] [PATCH] Fix typo in texinfo annotation.
* doc/coreutils.texi (sort invocation): Use @pxref inside parentheses.
---
Hi coreutils maintainers,
this trivial patch avoids this warning from CVS texinfo's makeinfo:
coreutils.texi:3807: warning: `.' or `,' must follow @xref, not `)'.
coreutils.texi:3807: warning: for cross-references in parentheses, use @pxref.
Cheers,
Ralf
doc/coreutils.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 66309b1..13b6aa5 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3804,7 +3804,7 @@ converting to floating point.
@vindex LC_NUMERIC
Sort numerically, first by numeric sign (negative, zero, or positive);
then by @acronym{SI} suffix (either empty, or @samp{k} or @samp{K}, or
-one of @samp{MGTPEZY}, in that order; @xref{Block size}); and finally
+one of @samp{MGTPEZY}, in that order; @pxref{Block size}); and finally
by numeric value. For example, @samp{1023M} sorts before @samp{1G}
because @samp{M} (mega) precedes @samp{G} (giga) as an @acronym{SI}
suffix. This option sorts values that are consistently scaled to the
--
1.7.2.1
