[PATCH] maint: use more readable operator: "||" rather than "|"

[Jim Meyering]

Here's a new-to-me reason to use "||" rather than "|":

>From dc0f5eb6a01b759c92478be7f21de3e685ebfbca Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Mon, 4 Jan 2010 16:46:44 +0100

* src/cp.c (make_dir_parents_private): Use "||" rather than "|",
so that clang understands there is no undefined pointer dereference.
---
 src/cp.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/cp.c b/src/cp.c
index 980c058..b2a7269 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -411,8 +411,8 @@ make_dir_parents_private (char const *const_dir, size_t 
src_offset,
   *slash = '\0';
   missing_dir = (stat (dir, &stats) != 0);

-  if (missing_dir | x->preserve_ownership | x->preserve_mode
-  | x->preserve_timestamps)
+  if (missing_dir || x->preserve_ownership || x->preserve_mode
+  || x->preserve_timestamps)
 {
   /* Add this directory to the list of directories whose
  modes might need fixing later. */
--
1.6.6.384.g14e6a

[PATCH] maint: always free a buffer, to avoid even semblance of a leak

[Jim Meyering]

As the log says...

>From be6c13e7e0abc46121c4250c82019179fd5e85c2 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Mon, 4 Jan 2010 16:49:30 +0100

* src/tac.c (main): Free the input buffer in most cases.
---
 src/tac.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/src/tac.c b/src/tac.c
index 465a089..c7af6c1 100644
--- a/src/tac.c
+++ b/src/tac.c
@@ -633,6 +633,7 @@ main (int argc, char **argv)
   if (! (read_size < half_buffer_size && half_buffer_size < G_buffer_size))
 xalloc_die ();
   G_buffer = xmalloc (G_buffer_size);
+  void *buf = G_buffer;
   if (sentinel_length)
 {
   strcpy (G_buffer, separator);
@@ -661,6 +662,10 @@ main (int argc, char **argv)
   output ((char *) NULL, (char *) NULL);

   if (have_read_stdin && close (STDIN_FILENO) < 0)
-error (EXIT_FAILURE, errno, "-");
+{
+  error (0, errno, "-");
+  ok = false;
+}
+  free (buf);
   exit (ok ? EXIT_SUCCESS : EXIT_FAILURE);
 }
--
1.6.6.384.g14e6a

new snapshot available: coreutils-8.2.52-4db2f

[Jim Meyering]

I'm aiming for a release of coreutils-8.3 tomorrow or Thursday,
so if you can find time to build this and run tests before then,
please do.

coreutils snapshot: (.gz files are here, too)
  http://meyering.net/cu/coreutils-ss.tar.xz  4.3 MB
  http://meyering.net/cu/coreutils-ss.tar.xz.sig
  http://meyering.net/cu/coreutils-8.2.52-4db2f.tar.xz

There are .gz and .sig files here, too:
  http://people.redhat.com/meyering/cu/coreutils-ss.tar.xz
  http://people.redhat.com/meyering/cu/coreutils-8.2.52-4db2f.tar.xz

Here's the NEWS, then shortlogs for coreutils and gnulib:

** Bug fixes

  ls -l --color no longer prints "argetm" in front of dangling
  symlinks when the 'LINK target' directive was given to dircolors.
  [bug introduced in fileutils-4.0]

  rm -r --one-file-system works once again.
  The rewrite to make rm use fts introduced a regression whereby
  a commmand of the above form would fail for all subdirectories.
  [bug introduced in coreutils-8.0]

  stat -f recognizes more file system types: k-afs, fuseblk, gfs/gfs2, ocfs2,
  and rpc_pipefs. Also Minix V3 is displayed correctly as minix3, not minux3.
  [bug introduced in coreutils-8.1]

  tail -f (inotify-enabled) once again works with remote files.
  The use of inotify with remote files meant that any changes to those
  files that was not done from the local system would go unnoticed.
  [bug introduced in coreutils-7.5]

  tail -F (inotify-enabled) would abort when a tailed file is repeated
  renamed-aside and then recreated.
  [bug introduced in coreutils-7.5]

  tail -F (inotify-enabled) could fail to follow renamed files.
  E.g., given a "tail -F a b" process, running "mv a b" would
  make tail stop tracking additions to "b".
  [bug introduced in coreutils-7.5]

  touch -a and touch -m could trigger bugs in some file systems, such
  as xfs or ntfs-3g, and fail to update timestamps.
  [bug introduced in coreutils-8.1]

  wc now prints counts atomically so that concurrent
  processes will not intersperse their output.
  [the issue dates back to the initial implementation]

==
Changes in coreutils since 8.2:

Eric Blake (5):
  touch: fix ctime regression in 'touch -a'
  tac: supply link dependency
  maint: ignore more built files
  touch: work around ntfs-3g bug
  ls: fix color of broken symlinks colored as target

Giuseppe Scrivano (2):
  tail: remove `fdspec' from the hash table before changing its key
  tail -F: don't stop following the target of a rename

Jim Meyering (33):
  post-release administrivia
  build: update gnulib submodule to latest; adapt a patch
  factor: add a missing va_end
  tests: tail-without-inotify: avoid spurious test failure
  maint: move definitions from maint.mk to dist-check.mk
  stat: recognize "sockfs" file system type, ...
  tests: make the taint-distcheck rule easier to share with other projects
  nohup: if fd_repoen fails (redirecting stdin), report it
  maint: make dist-check.mk more easily shared
  tests: unpack xz-compressed tarballs when possible, not always *.gz
  maint: improve dist-check.mk rules
  build: correct coreutils-specific distcheck rules
  maint: tail: avoid in-function #if directives
  tail: shrink internal struct by 8 bytes
  build: update gnulib submodule to latest
  tail: avoid read-beyond-end-of-buffer error
  tail: rename an internal variable
  maint: quiet "make" in doc/
  tail: add a test to exercise abort-inducing flaw in tail -F
  tail: add another test to exercise abort-inducing flaw in tail -F
  tail: test for a bug in inotify-enabled tail -F
  doc: mention two tail -F bug fixes in NEWS
  build: update gnulib submodule to latest
  doc: update tail's documentation to allow for new -F semantics
  maint: newer gnulib; don't hard-code my GPG key ID
  maint: update all FSF copyright year lists to include 2010
  maint: add a few copyrights; remove obsolete README file
  build: update gnulib submodule to latest
  df: use fputs in place of printf in a few more places
  maint: record update-copyright options for this package
  maint: use more readable operator: "||" rather than "|"
  maint: always free a buffer, to avoid even semblance of a leak
  build: update gnulib submodule to latest

Pádraig Brady (8):
  rm: fix --one-file-system regression due to fts conversion
  doc: enhance and reference info about version comparison
  maint: don't include the strverscmp gnulib module
  stat: add support for more file system types
  stat: Recognize k-afs, gfs, ocfs2 file system types
  wc: line-buffer the printed counts
  tail: fix --follow to not use inotify on remote files
  maint: improve the info about $PATH in README-prereq

Stéphane Raimbault (3):
  df: add comments to help translators align column headers
  pr --help: improve a line-break

Re: new snapshot available: coreutils-8.2.52-4db2f

[Philip Rowlands]

On Tue, 5 Jan 2010, Jim Meyering wrote:


Here's the NEWS, then shortlogs for coreutils and gnulib:

** Bug fixes

[snip]


 tail -F (inotify-enabled) would abort when a tailed file is repeated
 renamed-aside and then recreated.
 [bug introduced in coreutils-7.5]


Should that be "repeatedly"?


Cheers,
Phil

Re: new snapshot available: coreutils-8.2.52-4db2f

[Ludovic Courtès]

Hello,

Surprisingly “make dist” has been failing on Hydra for some time[*]:

--8<---cut here---start->8---
gcc -std=gnu99  -I.  -g -O2 -c -o exclude.o exclude.c
In file included from mbuiter.h:106,
 from exclude.c:38:
mbchar.h: In function 'mb_width_aux':
mbchar.h:241: warning: implicit declaration of function 'wcwidth'
In file included from exclude.c:38:
mbuiter.h: At top level:
mbuiter.h:112: error: expected specifier-qualifier-list before 'mbstate_t'
mbuiter.h: In function 'mbuiter_multi_next':
--8<---cut here---end--->8---

Ideas?

Thanks,
Ludo’.

[*] http://hydra.nixos.org/job/gnu/coreutils-master/tarball/all

Re: new snapshot available: coreutils-8.2.52-4db2f

[Jim Meyering]

Philip Rowlands wrote:
>>  tail -F (inotify-enabled) would abort when a tailed file is repeated
>>  renamed-aside and then recreated.
>>  [bug introduced in coreutils-7.5]
>
> Should that be "repeatedly"?

Yes.  Thanks!

>From bbdc929602fb1a3886fced0459ba405151549739 Mon Sep 17 00:00:00 2001
From: Philip Rowlands 
Date: Tue, 5 Jan 2010 14:11:56 +0100
Subject: [PATCH] doc: fix typo in NEWS

* NEWS: Fix typo: s/repeated/repeatedly/
---
 NEWS |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/NEWS b/NEWS
index 7f012e4..42a8f47 100644
--- a/NEWS
+++ b/NEWS
@@ -22,7 +22,7 @@ GNU coreutils NEWS-*- 
outline -*-
   files that was not done from the local system would go unnoticed.
   [bug introduced in coreutils-7.5]

-  tail -F (inotify-enabled) would abort when a tailed file is repeated
+  tail -F (inotify-enabled) would abort when a tailed file is repeatedly
   renamed-aside and then recreated.
   [bug introduced in coreutils-7.5]

--
1.6.6.384.g14e6a

Re: new snapshot available: coreutils-8.2.52-4db2f

[Jim Meyering]

Ludovic Courtès wrote:
> Surprisingly “make dist” has been failing on Hydra for some time[*]:
>
> gcc -std=gnu99  -I.  -g -O2 -c -o exclude.o exclude.c
> In file included from mbuiter.h:106,
>  from exclude.c:38:
> mbchar.h: In function 'mb_width_aux':
> mbchar.h:241: warning: implicit declaration of function 'wcwidth'
> In file included from exclude.c:38:
> mbuiter.h: At top level:
> mbuiter.h:112: error: expected specifier-qualifier-list before 'mbstate_t'
> mbuiter.h: In function 'mbuiter_multi_next':
...
> [*] http://hydra.nixos.org/job/gnu/coreutils-master/tarball/all

Thanks for the report.
wcwidth is supposed to be declared in wchar.h,
but the above suggests something is not working.

Does your lib/wchar.h file look ok?

Here's the relevant part of mine from a Fedora 12 system:

/* Return the number of screen columns needed for WC.  */
#if 1
# if 0
#  undef wcwidth
#  define wcwidth rpl_wcwidth
extern int wcwidth (wchar_t);
# else
#  if !defined wcwidth && !1
/* wcwidth exists but is not declared.  */
extern int wcwidth (int /* actually wchar_t */);
#  endif
# endif
#elif defined GNULIB_POSIXCHECK
# undef wcwidth
# define wcwidth(w) \
(GL_LINK_WARNING ("wcwidth is unportable - " \
  "use gnulib module wcwidth for portability"), \
 wcwidth (w))
#endif

[PATCH] src/sort.c: assert on temp.text before calling memcpy()

[Kovarththanan Rajaratnam]

>From c65f5323d2c187e01e73c7a074382f77ff8ee708 Mon Sep 17 00:00:00 2001
From: Kovarththanan Rajaratnam 
Date: Tue, 5 Jan 2010 20:24:02 +0100
Subject: [PATCH] src/sort.c: assert on temp.text before calling memcpy()

clang detected the following false positive:

sort.c:2292:7: warning: Null pointer passed as an argument to a 'nonnull' parameter
  memcpy (temp.text, line->text, line->length);

When we reach this line temp.text is guaranteed to be non null.
---
 src/sort.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/sort.c b/src/sort.c
index 481fdb8..b50f6cd 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "system.h"
 #include "argmatch.h"
 #include "error.h"
@@ -2289,6 +2290,7 @@ check (char const *file_name, char checkonly)
 
   temp.text = xrealloc (temp.text, alloc);
 }
+  assert(temp.text);
   memcpy (temp.text, line->text, line->length);
   temp.length = line->length;
   if (key)
-- 
1.6.3.3

coreutils-7.2.5 - factor

[Jim Donovan]

Hi,

I run Fedora 11 on a AMD phenom 2
Linux phenom 2.6.30.10-105.fc11.i686.PAE #1 SMP Thu Dec 24 16:41:17 UTC 2009 
i686 athlon i386 GNU/Linux
 (yes, the 32-bit version on a 64-bit machine)

I have gmp-4.1.2-2 installed, too.

when I run
factor 4951760154835678088235319297
it returns:
factor: `4951760154835678088235319297' is too large

but 4951760154835678088235319297 is the example given in `info coreutils factor 
invocation`

Does that mean Fedora should have built it with GNU MP?

Jim Donovan

  
_
Looking for a great date? Meet singles at ninemsn dating
http://clk.atdmt.com/NMN/go/150855801/direct/01/

[bug #28492] pr header lacks spaces around long file names

[anonymous]

URL:
  

 Summary: pr header lacks spaces around long file names
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Wed 06 Jan 2010 12:53:34 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:


Printing a file whose path or name is longer than 48 chars
leaves the file name adjoining the  and/or 
elements of the header.

Names shorter than 48 chars are centered between spaces in
the available width.

Names longer than 48 chars lack padding spaces.

Names longer than 50 chars appear without spaces in a wider format header.

Repeat by:

base='123456789_123456789_123456789_123456789_1234567'
longs=$( echo ${base}{8,89,89_,89_1} )
for f in ${longs} ; do echo >> $f; done
pr ${longs} | cat -s

produces (modulo date formats and 'Page' translation):

2010-01-05 16:48 123456789_123456789_123456789_123456789_12345678 Page 1

2010-01-05 16:48123456789_123456789_123456789_123456789_123456789 Page 1

2010-01-05 16:48123456789_123456789_123456789_123456789_123456789_Page 1

2010-01-05 16:48123456789_123456789_123456789_123456789_123456789_1Page 1


POSIX appears to specify a printf format for pr headers equivalent to:

"\n\n%s %s Page %d\n\n\n",
, , 

which shows explicit spaces around the file name field.

I added statements to pr.c to coerce the spacing to be greater than 0,
but there may certainly be a more elegant approach that considers
the issues of headers for multiple columns.

--- pr.c2010-01-05 16:27:54.0 -0800
+++ pr.orig.c   2010-01-05 15:10:50.0 -0800
@@ -2403,9 +2403,6 @@
   lhs_spaces = available_width >> 1;
   rhs_spaces = available_width - lhs_spaces;

-  lhs_spaces = lhs_spaces > 0 ? lhs_spaces : 1;
-  rhs_spaces = rhs_spaces > 0 ? rhs_spaces : 1;
-
   printf ("\n\n%*.*s%s%*.*s%s%*.*s%s\n\n\n",
   chars_per_margin, chars_per_margin, " ",
   date_text, lhs_spaces, lhs_spaces, " ",
   file_text, rhs_spaces, rhs_spaces, " ", page_text);

-- 
I am entitled to copyright of this bug report and patch, but
disclaim any such interest, and place them in the public domain,
with the intent that GNU/FSF may use them as they please.

best wishes,
Denis McKeon






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #28492] pr header lacks spaces around long file names

[Eric Blake]

Follow-up Comment #1, bug #28492 (project coreutils):

Thanks for the report (although the mailing list tends to be the preferred
medium for potential patches).  You are indeed correct that this is a
violation of POSIX.

Your patch is reversed in sense (you want the original file to be listed
first, not second).  Also, your attempt at an electronic copyright disclaimer
does not hold enough weight to work with the FSF; fortunately, though, your
contribution is small enough to not need copyright assignment in the first
place.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/