coreutils-6.9.92 released

[Jim Meyering]

Coreutils version 6.9.92 has been released.
This is a bug-fix-only release.  I expect the next release
to be coreutils-6.10, with a well-deserved "stable" rating.

Thanks to everyone who has contributed to this release.
For a summary of changes and contributors, see here:
  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v6.9.92

If you haven't heard about the GNU coreutils, the FAQ is a good
place to start: .

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.9.92.tar.gz   (8.8MB)
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.9.92.tar.lzma (3.6MB)

Here are the xdelta diffs (useful? if so, please tell [EMAIL PROTECTED]):
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.9.91-6.9.92.xdelta (220KB)

Here are the GPG detached signatures[*]:
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.9.92.tar.gz.sig
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.9.92.tar.lzma.sig

If you haven't heard about LZMA yet, see .
Since the lzma-compressed tarball is 2MB smaller than the .bz2 one,
and since it decompresses twice as fast, I no longer create bzip2-
compressed tarballs.

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify coreutils-6.9.92.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver wwwkeys.pgp.net --recv-keys B9AB9A16

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.61a.336-e6742
  Automake 1.10a
  Bison 2.3a
  Gnulib v0.0-182-g0e38bfe

*
How can you help?
*
If you're interested in lending a hand, or just want to use
the latest versions right now, you can build these programs
and run the test suite like this:

   gzip -dc coreutils-6.9.92.tar.gz | tar xf -
   cd coreutils-6.9.92
   ./configure
   make
   make -k check >& log
   grep FAIL log

Be sure to use make's -k option so that make doesn't stop
just because one of the earlier tests fails.
Please report any build problems or test failures to the
bug-coreutils@gnu.org mailing list.
There are detailed instructions in the `Reporting bugs:' section
of the README file.

For further reading, see the coreutils home page
  http://www.gnu.org/software/coreutils/
and the FAQ list:
  http://www.gnu.org/software/coreutils/faq/

*
NEWS
*
* Noteworthy changes in release 6.9.92 (2008-01-12) [beta]

** Bug fixes

  cp --parents no longer uses uninitialized memory when restoring the
  permissions of a just-created destination directory.
  [bug introduced in coreutils-6.9.90]

  tr's case conversion would fail in a locale with differing numbers
  of lower case and upper case characters.  E.g., this would fail:
  env LC_CTYPE=en_US.ISO-8859-1 tr '[:upper:]' '[:lower:]'
  [bug introduced in coreutils-6.9.90]

** Improvements

  "touch -d now writable-but-owned-by-someone-else" now succeeds
  whenever that same command would succeed without "-d now".
  Before, it would work fine with no -d option, yet it would
  fail with the ostensibly-equivalent "-d now".


pgpBeY0kxabii.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] Add svg to the dircolors list

[Jim Meyering]

Thanks applied.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [RFC] shred: --verbose output to stdout

[Jim Meyering]

Steven Schubiger <[EMAIL PROTECTED]> wrote:
> After skimming through a bit of code from shred, I was eager
> to see how easy it would be to change the corresponding calls
> of error() that are relevant to verbosity output to call some
> "equivalent" function, which outputs to stdout, i.e.
>
>  static void
>  output (const char const *fmt, ...)
>  {
>va_list ap;
>va_start (ap, fmt);
>fprintf (stdout, "%s: ", program_name);
>vfprintf (stdout, fmt, ap);
>fprintf (stdout, "\n");
>va_end (ap);
>  }
>
> This is a bit more terse than it ought to be, but it illustrates
> that it can be easily implemented for shred itself required that
> 3 non-fatal calls to error() are to be replaced with calls to output().
>
> It is also questionable whether the code should reside in some library and
> thus may also be used by mkdir and split or whether each program has its
> own piece of customized code.

shred uses stdout when FILE is "-", so its verbose output
must continue to go to stderr.

For mkdir.c and split.c, the above might work, assuming you add a call to
fflush (stdout).

Thanks for looking at this.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [RFC] shred: --verbose output to stdout

[Steven Schubiger]

Jim Meyering <[EMAIL PROTECTED]> wrote:
> shred uses stdout when FILE is "-", so its verbose output
> must continue to go to stderr.

TODO patch attached.

Steven Schubiger

diff --git a/TODO b/TODO
index 473eeca..b7e8a69 100644
--- a/TODO
+++ b/TODO
@@ -43,6 +43,8 @@ See if we can be consistent about where --verbose sends its 
output:
 head, tail, rm, cp, mv, ln, chmod, chown, chgrp, install, ln
   These send it to stderr:
 shred mkdir split
+  These send it to stderr and should not be changed:
+shred
   readlink is different
 
 Write an autoconf test to work around build failure in HPUX's 64-bit mode.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] split: --verbose output to stdout

[Steven Schubiger]

Patch attached (tested).

Steven Schubiger

diff --git a/src/split.c b/src/split.c
index 5807a1c..2ad0baf 100644
--- a/src/split.c
+++ b/src/split.c
@@ -208,7 +208,7 @@ cwrite (bool new_file_flag, const char *bp, size_t bytes)
 
   next_file_name ();
   if (verbose)
-   fprintf (stderr, _("creating file %s\n"), quote (outfile));
+   fprintf (stdout, _("creating file %s\n"), quote (outfile));
   output_desc = open (outfile,
  O_WRONLY | O_CREAT | O_TRUNC | O_BINARY,
  (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] split: --verbose output to stdout

[Jim Meyering]

Steven Schubiger <[EMAIL PROTECTED]> wrote:
> diff --git a/src/split.c b/src/split.c
> index 5807a1c..2ad0baf 100644
> --- a/src/split.c
> +++ b/src/split.c
> @@ -208,7 +208,7 @@ cwrite (bool new_file_flag, const char *bp, size_t bytes)
>
>next_file_name ();
>if (verbose)
> - fprintf (stderr, _("creating file %s\n"), quote (outfile));
> + fprintf (stdout, _("creating file %s\n"), quote (outfile));
>output_desc = open (outfile,
> O_WRONLY | O_CREAT | O_TRUNC | O_BINARY,
> (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP

That's probably ok. i.e., it's probably ok not to call fflush there.

You'll want to adjust the help output, too:

$ split --help|grep verb
  --verbose   print a diagnostic to standard error just

Please check the texinfo documentation, too.
It'd be nice if you were to include a ChangeLog entry.

No rush of course, since I won't apply such a change until
after the upcoming stable release.  In fact, why don't you
do both split and mkdir at the same time, and then you can
simply remove that item from TODO as part of the patch.

Finally, please run "make check" or even "make distcheck"
to make sure all tests pass with your changes.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

ls produces spurious message elements during tab completion

[Paul Coe]

Dear GNU core utils team, 
 
when using a partially completed path after ls and playing with tab
completion to remind oneself of the next directory or file
then the following message typically appears, as in this example...
 
prompt: ls -al /usr/lib/jvm/j
There are 4 There are %d %s, list them anyway? [n/y] , list them anyway?
[n/y] n
 
 
This text duplication bug with the C code style format specifiers
showing up is obviously only a minor issue,
but is certainly a symptom of incomplete coding and may lead you to
notice other problems.
 
At the very least it isn't pretty.
 
First noticed using ls under scientific linux 4 I've noticed the
following behaviour
I'm not sure but I may have also seen it in ubuntu and it may be a
problem across many linux flavours
 
regards
 
Paul Coe
---
 
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ls produces spurious message elements during tab completion

[Philip Rowlands]

On Sat, 12 Jan 2008, Paul Coe wrote:

when using a partially completed path after ls and playing with tab 
completion to remind oneself of the next directory or file then the 
following message typically appears, as in this example...


prompt: ls -al /usr/lib/jvm/j
There are 4 There are %d %s, list them anyway? [n/y] , list them anyway?
[n/y] n

This text duplication bug with the C code style format specifiers 
showing up is obviously only a minor issue, but is certainly a symptom 
of incomplete coding and may lead you to notice other problems.


Are you sure it's ls which is printing that message? Some shell 
tab-completion setups include calls to other processes, but as you've 
described file and directory listing is usually performed by the shell 
itself.


I'd expect the same problem to appear if you try other commands than ls.


Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

PATCH: source byte order option for od

[Robert Dodier]

Hello,

Here is a patch to enable two new options for od,
--source-byte-order and --force-byte-swap.

--source-byte-order=foo tells od to carry out end-to-end swap
on each output block when the source byte order, as
indicated by the argument of the option, differs from the host
byte order, as indicated by __BYTE_ORDER in endian.h.
od recognizes lsb and msb as source byte order specifications.

--force-byte-swap tells od to carry out end-to-end byte swap (unconditionally).

I'll be happy to write some Texinfo documentation and whatever
else is needed if it seems like this is going to fly.

Thanks in advance for your comments.

Robert Dodier


od.c-byte-order-patch
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

coreutils 6.9.92 fail to configure on *bsd

[Elias Pipping]

Hi,

on bsd-like systems(*), `./configure` fails with v6.9.92. The error is:

  checking for library containing crypt... none required
  sed: 1: "/^gl_INCLUDE_EXCLUDE_PR ...": bad flag in substitute command: '}'
  configure: error: internal error: g'l_INCLUDE_EXCLUDE_PROG's 2nd arg, ,
 does not match the list of default-not-installed programs
 (arch hostname su) also recorded in ./src/Makefile.am

The bug is easily fixed by inserting a newline right before the closing
'}', to make non-GNU sed(1) happy. I've attached a patch(*).

With it, v6.9.92 compiles on the aforementioned platforms -- while the
test suite passes on openbsd, though, on darwin 15 tests fail:

FAIL: help-version.log
FAIL: parent-perm.log
FAIL: file-perm-race.log
FAIL: parent-perm-race.log
FAIL: existing-perm-race.log
FAIL: backup-dir.log
FAIL: src-base-dot.log
FAIL: preserve-2.log
FAIL: fail-perm.log
FAIL: cp-parents.log
FAIL: basic-1.log
FAIL: create-leading.log
FAIL: misc.log
FAIL: test-frexpl
FAIL: test-printf-frexpl

I've attached the verbose output.


-- Elias

(*) tested on powerpc-unknown-openbsd4.2, i386-apple-darwin9.1.0

PS: I have yet to run expensive tests and check-root
diff --git a/configure.ac b/configure.ac
index 78c662a..768f13a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -279,7 +279,8 @@ no_install_progs_default=`echo "$t"|sed 's/ $//'`
 # The compromise is to ensure that the space-separated list extracted
 # above matches the literal 2nd argument below.
 c="$srcdir/configure.ac"
-t=`sed -n '/^g''l_INCLUDE_EXCLUDE_PROG(.* [\[\(.*\)\]])/{s//\1/;s/,/ /gp}' $c`
+t=`sed -n '/^g''l_INCLUDE_EXCLUDE_PROG(.* [\[\(.*\)\]])/{s//\1/;s/,/ /gp
+}' $c`
 case $t in
   $no_install_progs_default) ;;
   *) AC_MSG_ERROR([[internal error: g'l_INCLUDE_EXCLUDE_PROG's 2nd arg, $t,


coreutils-6.9.92-check.log.bz2
Description: Binary data


pgpyf2U9zAjFr.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils