FYI, I've just pushed this. No semantic change:
From b83d2896854de3823665d32630fb68e2c887c17b Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 30 Apr 2011 07:48:08 +0200
Subject: [PATCH] maint: adjust split.c formatting to conform
* src/split.c (usage): Correct
Here's what I have so far.
One remaining task is to write the ChangeLog entry for
Karl's initial change.
[1/8] split: accept new output --filter option
[2/8] split: remove short-named -f option; improve diagnostics
[3/8] split: add tests
[4/8] split: update NEWS
[5/8] split: mark a string for
From: Jim Meyering meyer...@redhat.com
* tests/Makefile.am (TESTS): Add split/filter.
* tests/split/filter: New file.
---
tests/Makefile.am |1 +
tests/split/filter | 41 +
2 files changed, 42 insertions(+), 0 deletions(-)
create mode 100755 tests
From: Jim Meyering meyer...@redhat.com
* NEWS (New feature): Mention it.
---
NEWS | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index c90e02f..82ce53c 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,16 @@ GNU coreutils NEWS
Pádraig Brady wrote:
On 30/04/11 14:31, Jim Meyering wrote:
+for total_n_lines in 5 3000 2; do
+ for i in 2 51 598; do
+# Don't create too many files/processes.
+case $i:$total_n_lines in 2:5);; *) continue;; esac
So the other combos are only for developer debug?
A comment
From: Jim Meyering meyer...@redhat.com
* bootstrap.conf (gnulib_modules): Remove now-obsolete strtol.
Remove use of $obsolete_gnulib_modules: unused since commit edc69f91.
---
bootstrap.conf |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/bootstrap.conf b/bootstrap.conf
[PATCH 1/3] doc: remove a name from THANKS.in that is derived from
[PATCH 2/3] maint: remove unnecessary listing of update-copyright in
[PATCH 3/3] maint: remove use of gnulib's obsolete strtol module
From: Jim Meyering meyer...@redhat.com
* THANKS.in: Remove a now-duplicate name.
---
THANKS.in |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/THANKS.in b/THANKS.in
index d1ca380..3156834 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -23,7 +23,6 @@ Adrian Bunk
From: Jim Meyering meyer...@redhat.com
* Makefile.am (changelog_etc): Don't list update-copyright here.
It is automatically included via gnulib-tool-generated lib/gnulib.mk.
---
Makefile.am |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index
From: Jim Meyering meyer...@redhat.com
* doc/coreutils.texi (split invocation): Describe --filter=CMD.
* NEWS (New feature): Mention it.
---
NEWS | 10 ++
doc/coreutils.texi | 23 +--
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git
From: Jim Meyering meyer...@redhat.com
* tests/Makefile.am (TESTS): Add split/filter.
* tests/split/filter: New file.
---
tests/Makefile.am |1 +
tests/split/filter | 45 +
2 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755
I've fixed the problems spotted by Pádraig Brady in the first round,
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1138
and have merged all code-changing commits into Karl's initial one.
This is rebased against the current head, and does compile ;-)
and passes all tests.
[PATCH 1/3]
From: Karl Heuer k...@gnu.org
* src/split.c: Include signal.h, sys/wait.h and sig2str.h.
(FILTER_OPTION): New anonymous enum member.
(filter_command, filter_pid): New globals.
(open_pipes, open_pipes_alloc, n_open_pipes): Likewise.
(oldblocked, newblocked): Likewise.
(longopts): Add filter.
Philipp Thomas wrote:
I currently had the task to research the potential pitfalls in updating from
a rather old version (6.11) of coreutils to the current one. The fact that
you so precisely state when a fixed bug was introduced greatly helped in
coming to a compressed list we could then
Pádraig Brady wrote:
This is a theoretical issue really, as if we're
having issues allocating a few bytes, then the system
will likely be hosed anyway. But for correctness
and to aid static analysis...
commit 85c6205f4366edc0d2c50c7036d559acc457509d
Author: Pádraig Brady p...@draigbrady.com
Stefano Lattarini wrote:
On Thursday 05 May 2011, Jim Meyering wrote:
Green, Paul wrote:
Gentle Coreutils Developers,
[HUGE CUT]
To the automake folks, is there any reason not to do that?
Hi Jim. I'm in a middle of something else right now, so I'm
probably not going to look
Jim Meyering wrote:
I've fixed the problems spotted by Pádraig Brady in the first round,
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1138
and have merged all code-changing commits into Karl's initial one.
This is rebased against the current head, and does compile
Pádraig Brady wrote:
Now that this gnulib change is included
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2953da14
I'll apply the attached.
This will both enable the warning on GCC = 4.7 and
remove the warkarounds from the code.
...
Subject: [PATCH] maint: remove
Preparing to get this rule from gnulib:
From 65c0915b8e3d9fd0f7ab1a352c512db360663357 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 11 May 2011 17:17:42 +0200
Subject: [PATCH] maint: remove syntax-checking sc_tight_scope rule
* src/Makefile.am (sc_tight_scope
Also tight-scope related:
From 2141543a3703cdb29cda41b1562f53f79215959c Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 8 May 2011 15:50:52 +0200
Subject: [PATCH] maint: tail: mark a global variable as static
* src/tail.c [HAVE_INOTIFY] (inotify_wd_mask): Declare
b456a2e680b1969ddac61a770417493b52973dc0 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 11 May 2011 17:13:53 +0200
Subject: [PATCH] ls: allow stat-free use of --color
Even on a system with d_type support, the default use of --color
makes ls stat every file in order to be able to honor settings like
Pádraig Brady wrote:
On 11/05/11 16:52, Jim Meyering wrote:
diff --git a/src/ls.c b/src/ls.c
index 4262923..54876ce 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -2740,7 +2740,10 @@ gobble_file (char const *name, enum filetype type,
ino_t inode,
/* When coloring a directory (we may know
FYI,
From eec0e6d2e4f6bc62384f6474c0addc4489dee1ec Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 11 May 2011 17:55:02 +0200
Subject: [PATCH 1/2] build: update gnulib submodule to latest
---
gnulib |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
I'd like to skip my new strace-vs-ls --color test on any
system (OS and/or file system) that lacks dirent.d_type support.
Ideally, it'd be a tiny bourne shell, python or perl script
to tell me if calling readdir on a given directory (let's say .)
would provide struct dirent data including usable
Pádraig Brady wrote:
On 12/05/11 17:41, Jim Meyering wrote:
I'd like to skip my new strace-vs-ls --color test on any
system (OS and/or file system) that lacks dirent.d_type support.
Ideally, it'd be a tiny bourne shell, python or perl script
to tell me if calling readdir on a given directory
Pádraig Brady wrote:
On 13/05/11 13:06, Jim Meyering wrote:
Very nice. Thank you!
That appears to work fine on Linux/glibc,
but fails on a solaris 10 system which lacks ctypes:
and fails on solaris 5.11 and freebsd 8.x due to the absence of libc.so.6
(one of those has libc.so and libc.so.1
FYI,
(as with any global change like this,
I'll write a syntax checking rule, too)
From 89d542f3d8fc97b3f9c45ad5beee9afdb68da152 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 13 May 2011 18:36:29 +0200
Subject: [PATCH] tests: use skip_test_, not skip_
MIME-Version
Jim Meyering wrote:
(as with any global change like this,
I'll write a syntax checking rule, too)
Subject: [PATCH] tests: use skip_test_, not skip_
And here it is:
From 76f49e601eb630d9f3d7c34676f38a5083f318fc Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 13 May
Pádraig Brady wrote:
FYI, in ls.c::usage() (and consequently the man page)
I'm adding this non obvious info
- otherwise: sort by ctime\n\
+ otherwise: sort by ctime, newest first\n\
- -t sort by
A bunch of typos in comments:
From cb4a0e31e282924f86046557980a2b5e16111ddd Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 19 May 2011 21:36:33 +0200
Subject: [PATCH] maint: correct typos involving misuse of a and an
* NEWS: an misleading
* src/expr.c: a integer
* src
Ivan Sichmann Freitas wrote:
Hi, nothing big, I just found two typos in df.c, the word obtain is misspelled
optain in two comments.
Thanks. Applied:
From 485a454576b3dd8c60994532e45135466e75a870 Mon Sep 17 00:00:00 2001
From: Ivan Sichmann Freitas ivansichfrei...@gmail.com
Date: Sat, 21 May
Pádraig Brady wrote:
I notice that split --filter spuriously returned with
status 141 just because the filter finished early.
This is a fairly good way to reproduce:
yes | head -n200K | split -b1G --filter='head -c1 /dev/null'
I avoided this by not unblocking SIGPIPEs before
calling
Pádraig Brady wrote:
Subject: [PATCH] maint: split: remove --filter specific code from other paths
(lines_chunk_split): Don't use ignore_error() which
is redundant and confusing when not running with --filter.
(lines_rr): Likewise.
(ofile_open): Likewise. Add a comment to clarify that
As spotted in
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/784758
fr.po makes od --help print invalid advice in French locales.
Unfortunately, it's not just the short-name for the --strings option
and it's not just the French locale that are affected.
This shows 12 locales that are
FYI,
From d61f5a1c1604543af68c934190a2c0d45fec6713 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 22 May 2011 17:09:04 +0200
Subject: [PATCH] tests: fix typo in tac-continue
* tests/misc/tac-continue: Fix typo in usually-skipped test:
s/mkfifo_or_skip/mkfifo_or_skip_
FYI, Karl sent me this nice patch:
Thanks again, Karl.
From ac9c5330dff20a505a0b38fa635b3b9646b0e70e Mon Sep 17 00:00:00 2001
From: Karl Berry k...@gnu.org
Date: Mon, 23 May 2011 09:45:39 -0700
Subject: [PATCH] maint: README-hacking clarifications
* README-hacking: Small getting-started
While inotify is specific to the linux kernel, it is
widespread enough that it's worth mentioning some of the effect
it has on tail -f:
From acbfebeb8d22a87b76fae32d8d9bf0473e178fdf Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 23 May 2011 16:09:42 +0200
Subject
Pádraig Brady wrote:
Subject: [PATCH 1/2] doc: describe how kernel inotify support affects tail -f
* doc/coreutils.texi (tail invocation) [-f]: Mention how inotify
kernel support makes a difference.
Prompted by http://bugzilla.redhat.com/662900
---
doc/coreutils.texi |5 +
1 files
Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 24 May 2011 20:33:27 +0200
Subject: [PATCH] touch: placate static analyzers: no NULL-deref is possible
* src/touch.c (main): Avoid even the hint of possibility that
we'd dereference NULL upon localtime failure. Coverity
Pádraig Brady wrote:
Subject: [PATCH] split: fix cases where -n l/... creates extraneous files
* src/split.c (lines_chunk_split): Ensure that data is only
written to stdout when k specified. Also ensure that
extra files are not created when there is more data available
than reported in the
I
have patches.
From 53e35f67a09b197430d7a70a7a7639d05cb1b80a Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 25 May 2011 12:29:18 +0200
Subject: [PATCH 1/2] maint: accommodate gcc's -Wstrict-overflow option
* src/factor.c (factor_using_pollard_rho): Change type of i
coverity complained that there was a risk of NULL dereference.
That turned out to be a false positive, but did highlight
the opportunity for improvement:
From 998f34e8de9f9498d4897e763cbfc06e92b008bc Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 25 May 2011 22:27:53
This started as another false positive from coverity.
Adding the assertion placates the tool.
I could have added an always-false conjunct:
if (p p[1])
but the assertion seems cleaner.
From c8adbe8cf03a044f3e23fada862700e20bcc5d54 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer
Pádraig Brady wrote:
On 26/05/11 17:06, Jim Meyering wrote:
There's a nasty bug in gcc, mentioned in log and comments below:
(It converts a loop that would obviously terminate into one
that never does, just because a signed accumulator may overflow.
The crazy part is that the offending
31bbcc7abfdc476bf23da4a1911bda35910c9fe8 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 28 May 2011 22:10:00 +0200
Subject: [PATCH] ls: placate gcc-4.7.0's -Wstrict-overflow
* src/ls.c (enum parse_state): Define.
(parse_ls_color): Use enum names in place of constants,
thus avoiding
As promised, this moves the tests/misc/split* files into tests/split
with some tweaks to make the names a little more evocative.
From 963d809ae9d2ff4bc4844d2ebaf64a74deb1ae7e Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 27 May 2011 00:54:53 +0200
Subject: [PATCH
)
src/truncate.c: if (ssize OFF_T_MAX - (off_t)fsize)
So I'll probably remove them, too.
From d0a9750e08a4cf0329f99a9956ab85f196a81263 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 28 May 2011 13:52:13 +0200
Subject: [PATCH] maint: remove useless (off_t) cast
Jim Meyering wrote:
These (off_t) casts are anachronistic.
They were useful in pre-ANSI-C days, i.e., before prototypes.
There are two remaining off_t casts, and neither appears useful:
(one is even inconsistently formatted, with no space after the ) ;-)
src/shred.c: if (offset
Pádraig Brady wrote:
On 28/05/11 22:47, Jim Meyering wrote:
Jim Meyering wrote:
These (off_t) casts are anachronistic.
They were useful in pre-ANSI-C days, i.e., before prototypes.
There are two remaining off_t casts, and neither appears useful:
(one is even inconsistently formatted
Pádraig Brady wrote:
On 28/05/11 22:34, Jim Meyering wrote:
I built the latest gcc from git/svn (4.7.0 20110528)
and got a new -Wstrict-overflow warning:
ls.c: In function 'main':
ls.c:2291:9: error: assuming signed overflow does not occur when\
simplifying conditional
FYI,
From 5c557690d8f10d1adc6d64478ab1ac0667282460 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 29 May 2011 14:29:13 +0200
Subject: [PATCH] maint: remove unnecessary gnulib .diff file
* gl/modules/getloadavg.diff: Remove file. It stopped being
useful back
) f
I tested both with and without ---disable-inotify.
From e7b4bf4b57efb699c87f03c1173d812ea34cb618 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 1 Jun 2011 13:48:12 +0200
Subject: [PATCH] tail: fix an inconsequential bug spotted by coverity
* src/tail.c (start_bytes
, st_size=0, ...}) = 0
Here's the fix:
From ccf2d9a482d19c949befde807184b0f5bbf72397 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 1 Jun 2011 16:08:21 +0200
Subject: [PATCH] tests: stat-free-color: accommodate stat of /selinux on
rawhide
* tests/ls/stat-free-color
Pádraig Brady wrote:
Remove unneeded includes as reported by:
http://code.google.com/p/include-what-you-use/
...
Subject: [PATCH] maint: remove unneeded includes
Remove unneeded includes as reported by:
http://code.google.com/p/include-what-you-use/
* src/cp-hash.c: Remove unused include.
Eric Blake wrote:
On 06/03/2011 09:06 AM, Pádraig Brady wrote:
On 03/06/11 15:52, Jim Meyering wrote:
Nice. Thanks!
I haven't tried it yet. How long does it take to run?
Sounds like a good candidate to be run as a syntax-check rule.
It's awkward (relies on a llvm/clang source tree
These address a couple of overdue FIXME comments:
From b7332b889e083370293b143687df3e01bbca7539 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 3 Jun 2011 13:29:15 +0200
Subject: [PATCH 1/2] maint: remove now-spurious curly braces
* src/chown-core.c (restricted_chown
James Youngman wrote:
* gnulib: Update to latest.
* src/system.h: Definitions of ST_* macros have moved into the
gnulib module stat-size (specifically, the header file
stat-size.h), so remove them from here.
* src/truncate.c: Include stat-size.h.
* src/stat.c: Likewise.
* src/shred.c:
c1aff7b4429ec916f47ce115ab11e06938599e99 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 14 Jun 2011 15:37:48 +0200
Subject: [PATCH] tests: use printf, not echo in init.sh's warn_ function
* tests/init.sh (warn_): Use printf, not echo. The latter
would misbehave when given strings
Eric Blake wrote:
On 06/14/2011 08:14 AM, Jim Meyering wrote:
I have been using warn/die-style functions like these for a few years,
and they are all based on printf (not echo) for precisely the reasons
listed in the log below. I'm surprised that I put an echo-based
implementation
James Youngman wrote:
I'd doubt that there are gnulib tests for which this will really make
a difference, but
There is none in coreutils, but there *are* tests there that set IFS.
Just none that use these relatively new functions in an affected scope.
( IFS=' '; printf '%s\n' $*; )
is
Voelker, Bernhard wrote:
Jim Meyering wrote:
James Youngman wrote:
( IFS=' '; printf '%s\n' $*; )
is perhaps slightly more reproducible.
Good suggestion. Setting IFS does seem prudent.
However, I'm inclined to use a subshell only if necessary:
warn_ ()
{
case $IFS
From: Jim Meyering meyer...@redhat.com
Date: Fri, 17 Jun 2011 12:01:10 +0200
Subject: [PATCH] tests: avoid sort-spinlock-abuse false positive under heavy
load
* tests/misc/sort-spinlock-abuse: Classify as very expensive to
avoid unwarranted failure once and for all.
---
tests/misc/sort-spinlock
James Youngman wrote:
On Fri, Jun 17, 2011 at 11:04 AM, Jim Meyering j...@meyering.net wrote:
+# This isn't terribly expensive, but it must not be run under heavy load.
+# Since the very expensive are already run only with -j1, adding this
very expensive tests
+# test to the list ensures
I normally use automake built from the head of master,
but not long ago, it started failing like this:
src/Makefile.am:141: error: `pkglibdir' is not a legitimate directory \
for `PROGRAMS'
That variable determines where we install libstdbuf.so.
One possibility is to change
Pádraig Brady wrote:
On 19/06/11 11:52, Jim Meyering wrote:
I normally use automake built from the head of master,
but not long ago, it started failing like this:
src/Makefile.am:141: error: `pkglibdir' is not a legitimate directory \
for `PROGRAMS'
That variable determines
Thank you!
That patch looks fine modulo two typos.
I'm folding in these corrections and have adjusted the
grammar in the commit log (included below).
diff --git a/tests/shell-or-perl b/tests/shell-or-perl
index ff92009..08604eb 100644
--- a/tests/shell-or-perl
+++ b/tests/shell-or-perl
@@ -1,7
Eric Blake wrote:
[adding coreutils]
On 06/20/2011 10:51 PM, Jim Meyering wrote:
2011-06-20 Bruno Haible br...@clisp.org
pathmax: Never define PATH_MAX to a non-constant expression.
* lib/pathmax.h (PATH_MAX): Don't define in terms of pathconf.
* m4/pathmax.m4 (gl_PATHMAX
Bruno Haible wrote:
Bruno's comment (in the text you elided) suggests intent to have
pathmax.h leave PATH_MAX undefined on the Hurd:
I find it reasonable to use #ifdef PATH_MAX in front of every use of
PATH_MAX, like POSIX requires.
With such a change, each of the above uses would
Prompted by recent discussion on bug-gnulib,
From 0bcfe87631993b3bd60bbc37ba26f2e267ebb8c6 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 24 Jun 2011 09:12:59 +0200
Subject: [PATCH] maint: don't use gnulib's pathmax module; define PATH_MAX if
needed
* bootstrap.conf
Pádraig Brady wrote:
I noticed the mqueue file system on my Fedora 15 install,
which is used to interact with POSIX message queues.
cheers,
Pádraig.
diff --git a/src/stat.c b/src/stat.c
index c479726..54c4e97 100644
--- a/src/stat.c
+++ b/src/stat.c
@@ -323,6 +323,8 @@ human_fstype
Jim Meyering wrote:
Peng Yu wrote:
When there are a few thousands of files/directories in a directory
that I want to ls, I experience long wait time (a few seconds on mac).
I'm wondering if some kind of cache can be built for ls to speed it
up? Note my ls is installed from macport
Peng Yu wrote:
On Sat, Jun 25, 2011 at 12:54 AM, Jim Meyering j...@meyering.net wrote:
Peng Yu wrote:
When there are a few thousands of files/directories in a directory
that I want to ls, I experience long wait time (a few seconds on mac).
I'm wondering if some kind of cache can be built
10ec91d84a53b3acae630864c2e82f2a74fa9c38 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 25 Jun 2011 14:54:45 +0200
Subject: [PATCH] doc: improve ls --help grammar
* src/ls.c (usage): Improve grammar.
Reported by Peng Yu.
---
THANKS.in |1 +
src/ls.c |2 +-
2 files changed, 2
Bob Proulx wrote:
Jim Meyering wrote:
For minimal overhead ls, use only the -1U options.
I.e., type exactly this:
env ls -1U
What benefit is provided by invoking through 'env' in that example
without any environment modifications specified? I am sure I am
missing something and would
86d19b44a5357158359e06e5db99cf7608470956 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 5 Jul 2011 22:49:56 +0200
Subject: [PATCH] stat: recognize GPFS as a file system type
* src/stat.c (human_fstype) [S_MAGIC_GPFS]: Add a case,
to handle GPFS_SUPER_MAGIC/0x47504653. Prompted
Benoît Knecht wrote:
The help output and man page mention that by default, date pads numeric
fields with zeroes, yet the description of %k and %l didn't specify
that these values were space padded, whereas the description of %e did.
Fixes http://bugs.debian.org/115833.
---
Hi,
If anyone
Jim Meyering wrote:
schoenfeld / in-medias-res wrote:
From 156d7e829da3ab9d895a275c2cd02e52388bcd0d Mon Sep 17 00:00:00 2001
From: Patrick Schoenfeld schoenf...@debian.org
Date: Mon, 17 Nov 2008 20:54:08 +0100
Subject: [PATCH] md5sum: Implemented --pedantic option to be more strict
you'd prefer to use.
Jim Meyering wrote:
Benoît Knecht wrote:
The help output and man page mention that by default, date pads numeric
fields with zeroes, yet the description of %k and %l didn't specify
that these values were space padded, whereas the description of %e did.
Fixes http
Benoît Knecht wrote:
This fact was already noted in the Texinfo manual, but not in the output
of --help.
* src/cp.c (usage): As above, for --help.
Reported by Jari Aalto in http://bugs.debian.org/294327.
Thank you.
Applied with the one-line summary edited to start with doc:
rather than
description here
[SEE ALSO]
-\fBtac\fP(1).
+\fBtac\fP(1)
...
Thanks!
However, I'll never remember that, so here's a crutch
to ensure that I don't have to:
From 145b871482590ba79fd7bd143c4aaa3a00d11e20 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 8 Jul 2011 17:10:17
Eric Blake wrote:
On 07/08/2011 12:03 PM, Paul Eggert wrote:
On 07/08/11 10:27, Eric Blake wrote:
if O_NOATIME is 0, --noatime should be rejected as an outright
impossibility.
if O_NOATIME is non-zero, --noatime should enable FTS_NOATIME, but only
as a best-effort (that is, the option is
Pádraig Brady wrote:
$ gcc --version
gcc (GCC) 4.6.0 20110509 (Red Hat 4.6.0-7)
$ make
test.c:95:1: error: function might be candidate for attribute 'pure'
if it is known to return normally [-Werror=suggest-attribute=pure]
As far as I can see the advance() function is not pure
as it
FYI,
From 7700751c5feff007a1b5054769d0e8d90638a62f Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 12 Jul 2011 15:40:53 +0200
Subject: [PATCH] build: update gnulib submodule to latest
---
gnulib |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
to makes it so
fclose would no longer be required, we do want to use that module
to ensure we get a working replacement for the buggy fclose on at
least two relatively common systems:
From e2bd7a288f4b4b0ac99350f3c6ac10cd97abf9a6 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed
+1937minor)pagefaults 0swaps
Comparing the two, I see where the extra memory is being allocated,
and will probably remove this pre-optimization to fix it:
[I'll adjust the log, but I doubt I'll be able to add a test]
From fe20dc12a0bacb81e0474c12dbb29a1afa8b28d1 Mon Sep 17 00:00:00 2001
From: Jim Meyering
FYI,
From 0be1ae66206bf109c0e6870c94c61d4dc6c8e2a7 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 27 Jul 2011 22:19:11 +0200
Subject: [PATCH] build: update gnulib, for make syntax-check fix
Without the recent maint.mk fix, make syntax-check
would fail like
Pádraig Brady wrote:
On 07/28/2011 01:16 PM, Jim Meyering wrote:
For some reason, sort is now very slow here (Fedora 15, x86_64, with
little free RAM), even for tiny inputs, but only some of the time,
and not when I set OMP_NUM_THREADS=1.
(I noticed because ./bootstrap was taking *forever
Pádraig Brady wrote:
I'm still not sure about this new partial mirroring behaviour of
cp -au, but I don't know how to avoid it. The attached patch at least
documents the change.
Thanks. I should have done that.
Subject: [PATCH] doc: mention the new mirroring behavior of cp -au
* NEWS:
Pádraig Brady wrote:
...
+ cp -au (where --preserve=links is implicit) now replaces possibly newer
s/now replaces/may now replace/ ?
...since whether it replaces them depends on the order
in which readdir processes entries in the containing directory.
I considered that but thought it
idv1...@gmail.com wrote:
Have you considered using rsync?
Is there some reason you require this functionality in cp?
Rsync is not in coreutils and is not always installed.
If rsync is not installed, perhaps you can install it.
At worst, you can build it yourself.
Yes you can use rsync, use
Bernhard Voelker wrote:
As discussed in
https://lists.gnu.org/archive/html/bug-coreutils/2011-07/msg00195.html
empty statements must follow a jump label if the next statement
is a declaration. Therefore, the other way round: the empty statement
can be omitted when no declaration follows.
Roman Rybalko wrote:
Jim Meyering wrote:
Dmitry Sivachenko wrote:
I am using coreutils-8.12 on FreeBSD-7.2 (compiled from FreeBSD
ports).
When I use --parallel option, I frequently (not always, but often) get
the following error:
Fatal error 'mutex
tests TESTS=rm/4-million-entry-dir VERBOSE=yes \
RUN_VERY_EXPENSIVE_TESTS=yes
I'll wait at least a couple hours before pushing this.
From 0ba576979a10a11e5652fd155266464b1e784892 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 19 Aug 2011 17:51:45 +0200
Subject
Once we have the parse-datetime dateTtime patch,
I'll be ready to release coreutils-8.13.
It's been almost 4 months and over 170 commits since 8.12,
so we're overdue.
If anyone can point out reported problems that they'd like to see
addressed first, please let us know.
Eric Blake wrote:
On 08/19/2011 01:33 PM, Jim Meyering wrote:
Once we have the parse-datetimedateTtime patch,
I'll be ready to release coreutils-8.13.
It's been almost 4 months and over 170 commits since 8.12,
so we're overdue.
If anyone can point out reported problems that they'd like
Eric Blake wrote:
On 08/19/2011 01:33 PM, Jim Meyering wrote:
Once we have the parse-datetimedateTtime patch,
I'll be ready to release coreutils-8.13.
It's been almost 4 months and over 170 commits since 8.12,
so we're overdue.
If anyone can point out reported problems that they'd like
Pádraig Brady wrote:
On 08/19/2011 08:33 PM, Jim Meyering wrote:
Once we have the parse-datetime dateTtime patch,
I'll be ready to release coreutils-8.13.
It's been almost 4 months and over 170 commits since 8.12,
so we're overdue.
If anyone can point out reported problems that they'd like
Voelker, Bernhard wrote:
Jim Meyering wrote:
+++ b/tests/rm/4-million-entry-dir
...
+# Put 4M files in a directory.
+mkdir d cd d || framework_failure_
+seq 400|xargs touch || framework_failure_
+
+cd ..
+
+# Restricted to 50MB, rm from coreutils-8.12 would fail
Voelker, Bernhard wrote:
Jim Meyering wrote:
Voelker, Bernhard wrote:
Jim Meyering wrote:
+++ b/tests/rm/4-million-entry-dir
...
+# Put 4M files in a directory.
+mkdir d cd d || framework_failure_
+seq 400|xargs touch || framework_failure_
+
+cd ..
+
+# Restricted
Bernhard Voelker wrote:
On 08/24/2011 10:49 AM, Jim Meyering wrote:
Voelker, Bernhard wrote:
BTW: Wouldn't this test deserve a proper make target, e.g.
make check-expensive?
Yes, good idea.
That would make it easier to run just those test.
However, hard-coding the list of expensive
201 - 300 of 5559 matches
Mail list logo
