On Wed, Nov 25, 2015 at 4:18 AM, Pádraig Brady wrote:
> On 25/11/15 11:17, Pádraig Brady wrote:
>> On 25/11/15 09:51, John Summerfield wrote:
>>> Here, and possibly other places, you say that the following command
>>> eliminates duplicate blank lines.
>>> tr -s '\n'
>>>
>>> This is in the --group
On Tue, Nov 24, 2015 at 4:03 PM, Pádraig Brady wrote:
> On 24/11/15 01:22, Pádraig Brady wrote:
>> On 22/11/15 20:16, Bob Proulx wrote:
>>> Pádraig Brady wrote:
Upon more careful consideration, I'm 50:50
about adding per line processing to tail.
...
Perhaps we could just add th
On Mon, Nov 23, 2015 at 6:24 PM, Pádraig Brady wrote:
> On 23/11/15 16:41, Jim Meyering wrote:
>> I think a common expected usage of --ignore-missing would be
>> the case of an SHA1SUM file listing all possibly-verified files for
>> which it is common to verify only the
On Mon, Nov 23, 2015 at 5:24 PM, Pádraig Brady wrote:
> On 23/11/15 16:05, Jim Meyering wrote:
>> On Mon, Nov 23, 2015 at 2:20 PM, Pádraig Brady wrote:
>>>> I'll push a bit later today.
>>>
>>> Pushed at
>>> http://git.sv.gnu.org/git
On Mon, Nov 23, 2015 at 2:20 PM, Pádraig Brady wrote:
>> I'll push a bit later today.
>
> Pushed at
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-91-g9fd0662
> Marking http://bugs.gnu.org/15604 done
Given how this warns/fails when using --check does nothing,
$ :|sha1sum
On Fri, Nov 20, 2015 at 1:08 PM, Pádraig Brady wrote:
> On 20/11/15 02:20, Pádraig Brady wrote:
>> I'm coming around to making a change here.
>>
>> Either be quiet about:
>> datagen | tee >(sha1sum --tag) >(md5sum --tag) >&- | sort | gpg --clearsign
>>
>> Or support:
>> datagen | tee --no-stdo
On Mon, Nov 16, 2015 at 11:33 PM, Jim Meyering wrote:
> Any comments on these?
No. So pushed.
Any comments on these?
From 1659ca5cdf7269ad40f174ddaf4a203013598c2d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 29 Jul 2015 17:40:08 -0700
Subject: [PATCH 1/2] maint: remove unmaintained file, c99-to-c89.diff
* src/c99-to-c89.diff: Remove file.
* src/local.mk (EXTRA_DIST): Remove it
On Mon, Nov 9, 2015 at 8:07 AM, Pádraig Brady wrote:
> On 09/11/15 16:02, Bernhard Voelker wrote:
>> On 11/09/2015 04:27 PM, Pádraig Brady wrote:
>>> I see on most GNU/Linux distros that kill(1) is
>>> provided by the shell or util-linux.
>>> Should we just remove it from coreutils?
>>
>> What abo
On Mon, Nov 9, 2015 at 7:27 AM, Pádraig Brady wrote:
> I see on most GNU/Linux distros that kill(1) is
> provided by the shell or util-linux.
> Should we just remove it from coreutils?
>
> We might move 'kill' to the disabled_by_default_progs
> list in build-aux/gen-lists-of-programs.sh,
> but I'm
On Tue, Nov 3, 2015 at 5:53 AM, Pádraig Brady wrote:
> I noticed in the info docs that ls may change to "shell" quoting by default.
>
> "You can specify the default value of the ‘--quoting-style’ option
>with the environment variable ‘QUOTING_STYLE’. If that environment
>variable is not
On Mon, Nov 2, 2015 at 6:33 AM, Pádraig Brady wrote:
> On 28/10/15 18:19, Jim Meyering wrote:
>> On Wed, Oct 28, 2015 at 10:30 AM, Pádraig Brady wrote:
>>> On 28/10/15 17:01, Jim Meyering wrote:
>>>> On Wed, Oct 28, 2015 at 6:18 AM, Pádraig Brady wrote:
>>>
On Wed, Oct 28, 2015 at 4:01 AM, Pádraig Brady wrote:
> To tag changes that are user visible
> and affect all (or many) commands.
> ---
> scripts/git-hooks/commit-msg | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/git-hooks/commit-msg b/scripts/git-hooks/commit-m
On Wed, Oct 28, 2015 at 10:30 AM, Pádraig Brady wrote:
> On 28/10/15 17:01, Jim Meyering wrote:
>> On Wed, Oct 28, 2015 at 6:18 AM, Pádraig Brady wrote:
>>> seq 10 | shuf --random-source="blah"$'\r'
>>
>> Thank you for pursuing this.
>>
On Wed, Oct 28, 2015 at 6:18 AM, Pádraig Brady wrote:
> seq 10 | shuf --random-source="blah"$'\r'
Thank you for pursuing this.
Properly quoting unusual names like those is definitely welcome,
however, in the remaining 99% of use cases, I find the added quotes
to be most unwelcome: at least two ex
On Thu, Oct 22, 2015 at 12:22 PM, Assaf Gordon wrote:
> Hello,
>
> In a long-running pipeline, we've encountered the following error message
> with 'csplit':
> csplit: write error for ‘[FILENAME]`
>
> It is very likely stemming from out-of-disk-space situation, but because
> there was no errno
On Thu, Oct 15, 2015 at 10:17 AM, Pádraig Brady wrote:
> On 15/10/15 17:58, Jim Meyering wrote:
>> On Thu, Oct 15, 2015 at 9:23 AM, Pádraig Brady wrote:
>>> On 15/10/15 17:14, Jim Meyering wrote:
>>>> I build gcc from git regularly, and my first test is to
On Thu, Oct 15, 2015 at 10:24 AM, Pádraig Brady wrote:
> On 15/10/15 18:12, Jim Meyering wrote:
>> On Thu, Oct 15, 2015 at 9:44 AM, Pádraig Brady wrote:
>>> On 15/10/15 17:18, Pádraig Brady wrote:
>>>> On 15/10/15 16:13, Jim Meyering wrote:
>>>>> He
On Thu, Oct 15, 2015 at 9:44 AM, Pádraig Brady wrote:
> On 15/10/15 17:18, Pádraig Brady wrote:
>> On 15/10/15 16:13, Jim Meyering wrote:
>>> Here's a small improvement:
>>
>>> # Strip that part off for the following comparison.
>>>
On Thu, Oct 15, 2015 at 9:23 AM, Pádraig Brady wrote:
> On 15/10/15 17:14, Jim Meyering wrote:
>> I build gcc from git regularly, and my first test is to use it to
>> build coreutils.
>> Today's gcc exposed this nit:
...
>> - int nfiles = 0;
>> + unsigne
I build gcc from git regularly, and my first test is to use it to
build coreutils.
Today's gcc exposed this nit:
From 74f62ef8b31993a7290cafb22c2384543afdad80 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Thu, 15 Oct 2015 09:09:18 -0700
Subject: [PATCH] maint: avoid uniq.c warning
variable CU_TEST_SKIP_EXIT at the very beginning. It's unlikely
>> that someone has such a variable set, but would you mind to squash
>> an 'unset CU_TEST_SKIP_EXIT' into the commit?
>
> Pushed with those adjustments.
Here's a small improvement:
From 819ece6e92
On Wed, Oct 14, 2015 at 6:44 PM, Pádraig Brady wrote:
> On 14/10/15 18:43, Jim Meyering wrote:
>> Running a massively parallel "make very-expensive-check"
>> (-j73 on a 48-core system), the rm/r-root.sh test would fail
>> about 1-in-2 or 1-in-3 trials due to expira
On Wed, Oct 14, 2015 at 10:43 AM, Jim Meyering wrote:
> Running a massively parallel "make very-expensive-check"
> (-j73 on a 48-core system), the rm/r-root.sh test would fail
> about 1-in-2 or 1-in-3 trials due to expiration of the 2-second
> timeout here:
>
> diff
Running a massively parallel "make very-expensive-check"
(-j73 on a 48-core system), the rm/r-root.sh test would fail
about 1-in-2 or 1-in-3 trials due to expiration of the 2-second
timeout here:
diff --git a/tests/rm/r-root.sh b/tests/rm/r-root.sh
index c06332a..4e645e6 100755
--- a/tests/rm/r-ro
On Fri, Oct 9, 2015 at 8:07 PM, Pádraig Brady wrote:
> * tests/misc/sort-compress-hang.sh: Use --foreground with the
> timeout(1) command (noting the caveats), to run the sort command
> in the foreground program group, and thus be responsive to Ctrl-C.
> This very_expensive_ test takes over a minu
On Sat, Sep 26, 2015 at 10:42 AM, Pádraig Brady wrote:
> On 26/09/15 15:43, Richard Russon wrote:
>> I'd like to add an option to both head and tail,
>> to allow them to work with NUL-terminated lines of text
>> -z, --zero-terminated
>>
>> Thus allowing:
>>
>> find dir -type f -print0 |
On Fri, Sep 18, 2015 at 8:43 AM, Bernhard Voelker
wrote:
> On 09/18/2015 10:39 AM, Pádraig Brady wrote:
>>
>> Fix looks good.
>> NEWS tweak
>>
>>du no longer stats all mount points at startup, only doing so
>>upon detection of a directory cycle.
>>[issue introduced in coreutils-8.2
On Fri, Sep 4, 2015 at 6:43 AM, Pádraig Brady wrote:
> On 09/09/14 10:50, Pádraig Brady wrote:
>> On 09/09/2014 04:55 AM, Paul Eggert wrote:
>>> I noticed other problems that are at least somewhat related to the
>>> recent coreutils multi-binary executable changes, and fixed some of
>>> these prob
On Thu, Sep 3, 2015 at 7:56 AM, Alex Henrie wrote:
> Hi,
>
> I have run into an annoying problem with GNU rm. When I try to remove
> a file to which I do not have write permission from a directory to
> which I do not have write permission, rm warns me about the file being
> read-only before tellin
On Tue, Sep 1, 2015 at 6:46 AM, Pádraig Brady wrote:
> A couple of related updates to base64 attached.
Nice work. The two base64 patches look fine; I note that
they'll be applied in the opposite order. It felt a little odd
that the log in the bug-fix patch makes a point of saying
it's preserving
On Sun, Aug 16, 2015 at 4:12 PM, Bernhard Voelker
wrote:
> Hi Assaf,
>
> On 08/16/2015 11:48 PM, Assaf Gordon wrote:
>> On 08/16/2015 05:27 PM, Bernhard Voelker wrote:
>>> Only 6 out of the 105 man/*.x files have a copyright notice:
>>>
>>>$ git ls-files -- man/*.x | wc -l
>>>105
>>>
>>>
On Thu, Jul 2, 2015 at 9:07 PM, Pádraig Brady wrote:
> On 03/07/15 01:26, Jim Meyering wrote:
>> On Thu, Jul 2, 2015 at 9:59 AM, Pádraig Brady wrote:
>>> On 02/07/15 17:46, Jim Meyering wrote:
>>>> On Thu, Jul 2, 2015 at 4:57 AM, Pádraig Brady wrote:
>>>&g
On Thu, Jul 2, 2015 at 9:59 AM, Pádraig Brady wrote:
> On 02/07/15 17:46, Jim Meyering wrote:
>> On Thu, Jul 2, 2015 at 4:57 AM, Pádraig Brady wrote:
>>> On 02/07/15 08:08, Pádraig Brady wrote:
>>>> On 02/07/15 06:19, Jim Meyering wrote:
>>>>> For me
On Thu, Jul 2, 2015 at 9:59 AM, Pádraig Brady wrote:
...
> BTW if changing gl_shell_test_script_, what do you think about
> the change to reject shells that don't support 'local'?
>
> diff --git a/tests/init.sh b/tests/init.sh
> index 9f403c5..c4dfadd 100755
> --- a/tests/init.sh
> +++ b/tests/ini
On Thu, Jul 2, 2015 at 4:57 AM, Pádraig Brady wrote:
> On 02/07/15 08:08, Pádraig Brady wrote:
>> On 02/07/15 06:19, Jim Meyering wrote:
>>> I was surprised to see that the factor-parallel test was failing.
>>> However, when I installed the very latest binaries ear
I was surprised to see that the factor-parallel test was failing.
However, when I installed the very latest binaries early in my
path, it would succeed once again.
Turns out that when SHELL=zsh is in my environment,
the split-run "$SHELL -c factor" command was using an
PATH environment that did no
On Wed, Jul 1, 2015 at 9:15 AM, Pádraig Brady wrote:
> On 01/07/15 16:58, sa wrote:
>> On 30.04.2015 22:27, sa wrote:
>>> On 30.04.2015 17:30, Pádraig Brady wrote:
On 30/04/15 13:02, sa wrote:
>
> it's still common today when you can copy files somewhere but subsequent
> chown() o
On Wed, Jul 1, 2015 at 10:36 AM, Benno Schulenberg
wrote:
>
> On 2015-07-01 17:35, Pádraig Brady wrote:
>> We plan to release coreutils-8.24 in the next couple of days so any
>> testing you can do on various different systems between now and then
>> would be most welcome.
>
> $ rm -r coreutils-8.2
Here's another change required to make --enable-gcc-warnings
work with systems that use gnulib's getopt replacement:
* src/numfmt.c (parse_field_arg): Rename parameter s/optarg/arg/,
to avoid shadowing getopt's global variable.
Otherwise, building on OS X, with --enable-gcc-warnings, I
On Sun, Jun 28, 2015 at 3:08 PM, Pádraig Brady wrote:
> On 28/06/15 21:01, Jim Meyering wrote:
>> From 8fc96e0a280211e7cdf0da5b685c1ec6b7668f78 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering
>> Date: Sun, 28 Jun 2015 10:17:57 -0700
>> Subject: [PATCH 1/2] maint: f
On Sat, Jun 27, 2015 at 10:04 PM, Pádraig Brady wrote:
> We plan to release coreutils-8.24 in about a week, so any testing
> you can do on various different systems between now and then
> would be most welcome.
Thanks for all that work.
I've attached two tiny patches:
0001-maint-factor.c-touch-
On Thu, Jun 25, 2015 at 8:31 AM, Pádraig Brady wrote:
...
> Yes I had discounted that as an issue, but you're right
> that it's better to be explicit with the tricky issue
> of integer conversion/overflow. How about this comment,
> and an explicit cast to placate any future warnings?
>
> cheers,
Hi Pádraig,
I noticed that a recent change accumulates the return value of printf
into a variable of type size_t:
+static size_t n_out; /* How much data we've written to stdout. */
+
...
-printf ("%"PRIuMAX, t0);
+n_out += printf ("%"PRIuMAX, t0);
The problem is that when printf fails,
On Wed, Jun 24, 2015 at 11:15 AM, Pádraig Brady wrote:
> GCC 5.1.1 -fsanitize=undefined with glibc 2.21 is returning:
> "runtime error: null pointer passed as argument 1,
> which is declared to never be null"
> * src/ptx.c (sort_found_occurs): Avoid the call with no entries.
Nice!
On Mon, May 18, 2015 at 4:34 AM, Pádraig Brady wrote:
> The commit message here doesn't explain why this was done:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=SH-UTILS-2_0_12-112-g13221a5
>
> Why not just include in system.h?
>
> Would this be better served these days with a sy
On Sun, May 17, 2015 at 7:48 AM, Pádraig Brady wrote:
> -sc_case_insensitive_file_names:
> - @git ls-files | sort -f | $(srcdir)/src/uniq -Di | grep . && \
> +sc_case_insensitive_file_names: src/uniq
> + @git ls-files | sort -f | src/uniq -Di | grep . && \
Looks good. Thanks!
Is there
I noticed that since the addition of the file,
tests/tail-2/F-vs-rename.sh, one can no longer
clone coreutils onto a case-challenged file system,
because there is also a file in that directory whose
name differs only in the case of the "f":
tests/tail-2/f-vs-rename.sh
What do you think about fi
On Sun, Feb 1, 2015 at 4:02 PM, Bernhard Voelker
wrote:
> On aarch64, we're experiencing a test failure in tests/misc/printenv.sh
> on the openSUSE Build Service: the output of 'env' is sorted exactly
> in reverse order compared to that of 'printenv'.
>
> https://build.opensuse.org/package/live_bu
On Fri, Jan 23, 2015 at 9:36 PM, Jim Meyering wrote:
> On Fri, Jan 23, 2015 at 2:02 PM, Pádraig Brady wrote:
>> On 23/01/15 15:56, Jim Meyering wrote:
>>> Here's an update to autotools-install, a turnkey
>>> "install the latest tools I need to build f
On Fri, Jan 23, 2015 at 2:02 PM, Pádraig Brady wrote:
> On 23/01/15 15:56, Jim Meyering wrote:
>> Here's an update to autotools-install, a turnkey
>> "install the latest tools I need to build from source" script:
>>
>> * scripts/autotools-install: Increas
Here's an update to autotools-install, a turnkey
"install the latest tools I need to build from source" script:
* scripts/autotools-install: Increase automake's version number
to 1.15 and add Stefano Lattarini's new GPG key ID.
Increase gettext's version to 0.19.4 and add Daiki Ueno's GPG key ID.
On Wed, Jan 14, 2015 at 1:24 AM, Bernhard Voelker
wrote:
> On 01/14/2015 02:51 AM, Pádraig Brady wrote:
>> On 13/01/15 08:13, Bernhard Voelker wrote:
>>> expectExit 1 program ... || fail=1
>>
>> Very good suggestions. I implemented the simplification wrapper
>> (I called it returns_), and that
On Tue, Jan 13, 2015 at 5:51 PM, Pádraig Brady wrote:
> On 13/01/15 08:13, Bernhard Voelker wrote:
>> On 01/13/2015 04:37 AM, Pádraig Brady wrote:
>>> Many tests use `program ... && fail=1` to ensure expected
>>> error situations are indicated. However that would mask
>>> an unexpected exit (like
On Thu, Jan 8, 2015 at 4:43 AM, Pádraig Brady wrote:
> On 08/01/15 06:25, Assaf Gordon wrote:
>> Hello,
>>
>> two rules in 'syntax-check' fail with non-gnu tools:
...
> pushed.
Looks good. Thanks to both of you.
On Thu, Dec 18, 2014 at 10:34 AM, Pádraig Brady wrote:
> On 16/12/14 17:05, Paul Eggert wrote:
>> On 12/16/2014 05:46 AM, Pádraig Brady wrote:
>>> if (xstrtoul (optarg, NULL, 10, &val, "") != LONGINT_OK
>>> -|| MIN (INT_MAX, SIZE_MAX) < val)
>>> - error (EXIT_FAILURE
On Wed, Dec 3, 2014 at 1:20 PM, Pádraig Brady wrote:
> On 03/12/14 18:18, Eric Blake wrote:
>> [adding the public list]
>>
>> On 12/03/2014 10:49 AM, Dingbao Xie wrote:
>>> Dear coreutils maintainer,
>>> I'm a visiting phd student at UC davis and currently works
>>> on a project aiming to detect u
On Fri, Sep 19, 2014 at 3:37 PM, Pádraig Brady wrote:
> On 09/19/2014 09:05 PM, Jim Meyering wrote:
>> Compiling with cutting edge gcc, I saw a new warning.
>> This fixes it:
>
> Slightly obtuse code to start with,
> but patch looks good.
Thanks for the review.
Pushed.
Compiling with cutting edge gcc, I saw a new warning.
This fixes it:
0001-maint-don-t-trigger-gcc-5-s-new-Wlogical-not-parenth.patch
Description: Binary data
On Mon, Aug 11, 2014 at 6:55 AM, Rasmus Borup Hansen wrote:
> Hi! I recently had to copy a lot of files and even though I've 20 years
> experience with various Unix variants I was still surprised by the behaviour
> of cp and I think my observations should be shared with the community.
...
> I ha
On Fri, Jul 18, 2014 at 5:03 PM, Assaf Gordon wrote:
> Hello,
>
> Few tests fail of version 8.22.157-1b243 (and I assume 8.23 now) fail on
> DilOS version 1.3.5.16 .
> (DilOS is Illumos kernel (formally OpenSolaris) with Debian-like packaging
> system: http://www.dilos.org/about-dilos ).
>
> The f
On Thu, May 29, 2014 at 7:45 AM, Pádraig Brady wrote:
> duplicities
Might as well correct the preexisting comment typo (twice), too:
s/duplicities/duplicates/
On Sun, Jul 13, 2014 at 10:42 AM, Pádraig Brady wrote:
> Good one. please push
Done.
ash and ksh-based
shells. Here's a fix:
From 4d82df724ef1ee0809aa294c68f7cc11c9c0f0f5 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 13 Jul 2014 10:24:33 -0700
Subject: [PATCH] build: adjust new rule not to depend on bash-4.x
* man/local.mk (man/dynamic-deps.mk): Use the same code to
derive FOO from man/FOO.1
On Fri, Jul 4, 2014 at 7:38 AM, Khaled Yakdan wrote:
> Hi,
>
> many thanks.
>
> the -save-temps flag did the trick
>
> best regards,
> Khaled
>
> Am 04.07.2014 12:43, schrieb Pádraig Brady:
>> On 07/04/2014 11:20 AM, Khaled Yakdan wrote:
>>> Hi all,
>>>
>>> is there an option to configure so that
On Wed, Jul 2, 2014 at 3:39 AM, Pádraig Brady wrote:
> On 07/02/2014 12:23 AM, Bob Proulx wrote:
>> It is also the exact opposite of very long standing traditional
>> behavior. And as Pádraig noted different from some other venerable
>> systems such as Solaris and I will also note HP-UX too. Is
On Tue, Jul 1, 2014 at 12:02 PM, Bob Proulx wrote:
> Jim Meyering wrote:
>> Pádraig Brady wrote:
>> > POSIX says that `pwd` without options should assume -L is specified.
>
> Hmm... It does? If so I think that is a bad thing in the standard
> since it does not standa
On Tue, Jul 1, 2014 at 9:58 AM, Pádraig Brady wrote:
> On 07/01/2014 05:49 PM, Jim Meyering wrote:
>> I wrote "$abs_top_builddir/src/kill" to ensure that we'd run the
>> just-build coreutils binary, and not a shell built-in function by
>> the same name -- b
I wrote "$abs_top_builddir/src/kill" to ensure that we'd run the
just-build coreutils binary, and not a shell built-in function by
the same name -- but that was back before I discovered
that "env builtin" is a much better way to do the job.
I changed some of these while fixing the pwd uses.
This f
On Tue, Jul 1, 2014 at 8:36 AM, Jim Meyering wrote:
> On Tue, Jul 1, 2014 at 8:02 AM, Jim Meyering wrote:
>> On Mon, Jun 30, 2014 at 2:29 AM, Pádraig Brady wrote:
>>> I'll push the attached for the pwd change later.
>>
>> That looks fine. Thanks.
>
> I
On Tue, Jul 1, 2014 at 8:02 AM, Jim Meyering wrote:
> On Mon, Jun 30, 2014 at 2:29 AM, Pádraig Brady wrote:
>> I'll push the attached for the pwd change later.
>
> That looks fine. Thanks.
I spoke too soon. Now that I test the patch, I see that the test
now fails for me, si
On Mon, Jun 30, 2014 at 2:29 AM, Pádraig Brady wrote:
> I'll push the attached for the pwd change later.
That looks fine. Thanks.
On Sun, Jun 29, 2014 at 9:42 AM, Pádraig Brady wrote:
> POSIX says that `pwd` without options should assume -L is specified.
> pwd is most often invoked as a shell builtin and bash, dash, zsh, ksh
> all follow POSIX and assume that -L is the default.
> However coreutils pwd assumes -P is the defau
On Thu, Jun 26, 2014 at 3:23 AM, Pádraig Brady wrote:
> -g=$(id -u $NON_ROOT_USERNAME) || framework_failure_
> +u=$(id -u $NON_ROOT_USERNAME) || framework_failure_
> +g=u
This will work better :-)
g=$u
On Wed, Jun 25, 2014 at 6:53 PM, Pádraig Brady wrote:
> On 06/25/2014 01:17 PM, Petr Stodůlka wrote:
>> Hi,
>>
>> command 'id' prints wrong groups for the session. This is similar to
>> reported bug #7320 [0],
>> which was patched earlier for 'groups' and 'id -G', however just 'id' still
>> prin
On Thu, Jun 19, 2014 at 4:23 AM, Pádraig Brady wrote:
> On 12/18/2013 05:39 PM, Eric Blake wrote:
>> On 12/18/2013 09:46 AM, Jeff Kirkpatrick wrote:
>>> However, I don't see explicit reasons for the non-zero exit code. If you
>>> want to ask for the reason, you may write an emailto coreutils@gnu.o
On Tue, Jun 10, 2014 at 5:05 PM, Pádraig Brady wrote:
> * configure.ac: Remove the -Wsuggest-attribute=pure
> enablement on GCC >= 4.7, as that was moot since
> gnulib was already enabling that warning in its default set.
> The false positive was seen with 4.6.2, but confirmed
> not present in 4.6
Looks fine. Thanks! One nit in the log message: s/apploed/applied/
On Tue, Jun 3, 2014 at 7:23 AM, Jim Meyering wrote:
> On Tue, Jun 3, 2014 at 5:16 AM, Pádraig Brady wrote:
>> On 06/03/2014 01:12 PM, Eric Blake wrote:
> ...
>>> Oh, good point. Maybe it's better to consistently have --help/--version
>>> return status 0 (we su
On Tue, Jun 3, 2014 at 5:16 AM, Pádraig Brady wrote:
> On 06/03/2014 01:12 PM, Eric Blake wrote:
...
>> Oh, good point. Maybe it's better to consistently have --help/--version
>> return status 0 (we successfully printed output) or 1 (we encountered
>> write failure) regardless of the program bein
Surprised to find any shadowing warnings in coreutils.
This was guarded by __APPLE__
0001-build-uname-avoid-shadowing-warning.patch
Description: Binary data
On Sun, May 25, 2014 at 4:51 AM, Pádraig Brady wrote:
> On 05/24/2014 05:21 PM, Jim Meyering wrote:
>> On Sat, May 24, 2014 at 1:59 AM, Pádraig Brady wrote:
>>> On 05/24/2014 06:32 AM, Jim Meyering wrote:
>>>> It looks like it makes sense to double IO_BUFSIZE once
On Sat, May 24, 2014 at 1:59 AM, Pádraig Brady wrote:
> On 05/24/2014 06:32 AM, Jim Meyering wrote:
>> It looks like it makes sense to double IO_BUFSIZE once again.
>> What do you think?
>
> +1
>
> Significant enough to bump up I think,
> and we never saw regressi
It looks like it makes sense to double IO_BUFSIZE once again.
What do you think?
0001-cat-cp-split-use-a-larger-buffer-for-copying.patch
Description: Binary data
On Thu, May 22, 2014 at 3:26 AM, Pádraig Brady wrote:
> On 05/22/2014 03:28 AM, Jim Meyering wrote:
> q> Nice. Thanks!
>> What do you think about using e.g.,
>>
>> grep -vE '^0x(|)$'
>>
>> instead of that latter sed invocation?
On Wed, May 21, 2014 at 6:46 PM, Pádraig Brady wrote:
> * src/stat.c (human_fstype): Adjust a couple of existing constants
> to be a consistent width so that the src/fs-magic-compare target
> works without reporting false positives.
> * cfg.mk (sc_fs-magic-compare): A new syntax check to enforce t
On Tue, May 13, 2014 at 1:59 AM, Pádraig Brady wrote:
> * tests/ls/stat-vs-dirent.sh: This test lists all parent directories,
> and would spuriously fail if any of those had a file name with a
> leading space as the first entry. There is only ever a single space
> between the right aligned inode
Thanks for the review. Pushed.
FYI:
0001-maint-autotools-install-update-tool-version-numbers-.patch
Description: Binary data
On Sat, Apr 19, 2014 at 8:08 AM, Jim Meyering wrote:
> On Sat, Apr 19, 2014 at 4:51 AM, Pádraig Brady wrote:
>> * Makefile.am (gen-ChangeLog): Sync changes from GNU hello to,
>> ensure exit status is propagated and to support an optional
>> git-log-fix file.
>
>
On Sat, Apr 19, 2014 at 4:51 AM, Pádraig Brady wrote:
> * Makefile.am (gen-ChangeLog): Sync changes from GNU hello to,
> ensure exit status is propagated and to support an optional
> git-log-fix file.
Hi Pádraig,
Thank you for repairing that. Your change looks fine.
On Wed, Mar 26, 2014 at 1:02 AM, Bernhard Voelker
wrote:
> The following fixes a 15-year-old issue in ptx(1).
>
> Was ptx(1) in TEXTUTILS?
> ... I assumed this in the NEWS entry.
Yes. Be glad you didn't have to endure the separate
CVS repositories before I merged them into one :-)
Interesting fa
On Tue, Mar 18, 2014 at 2:02 AM, Johannes Meixner wrote:
> On Mar 14 21:44 Jim Meyering wrote (excerpt):
>>
>> On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs
>> wrote:
>>>>
>>>> See the guidelines in coreutils' HACKING file.
>
> ...
>
>
On Tue, Mar 18, 2014 at 3:48 PM, Bernhard Voelker
wrote:
> * gl/lib/fadvise.c: s/the the/the/, indroduced in commit
> v8.22-40-g4f21182. Promted by sc_prohibit_doubled_word.
> While at it, also s/be candidate/be a candidate/.
Thanks! I(!) introduced that doubled-"the" violation.
Normally emacs
I like it.
Thanks a lot. I'm sure that will answer many questions that would
otherwise end up on the list.
On Thu, Dec 26, 2013 at 7:47 PM, Ken Irving wrote:
> I happened to run into a case were ln -s exited with a confusing message,
> and reduced it to the following:
>
> ln -s $(printf '%0.sx' {1..256}) len256
> ln -s x len256
>
> (where the printf is there just to create a value 256 bytes lon
Hi Pádraig,
This makes me think it will be useful to sync from the upstream copy
of that file regularly.
If there's not yet a make target that helps to automate that process
(and/or README-release words), it might be worth adding one.
Thanks,
Jim
On Wed, Nov 20, 2013 at 3:34 AM, Pádraig Brady wrote:
> On 11/20/2013 06:57 AM, Bernhard Voelker wrote:
>> On 11/20/2013 01:45 AM, Pádraig Brady wrote:
>>> Before I merge this I'd like to understand fully
>>> the reason why shred currently defaults to writing
>>> out progressively shorter names. F
On Thu, Nov 7, 2013 at 6:39 AM, Pádraig Brady wrote:
> I should have bumped up the buffer size for the periodic pattern case too.
> This should fix it up.
...
> commit 115c8e620dde3349cb8edef6edaba40dd82395d3
> Author: Pádraig Brady
> Date: Thu Nov 7 11:57:09 2013 +
>
> shred: increase
On Wed, Nov 6, 2013 at 11:07 PM, Bernhard Voelker
wrote:
> [I was hoping that someone with more coreutils history
> was jumping in here - adding Jim for that matter.]
Hi Berny,
I don't have enough context (12 years is a long time) yet, but would guess that
the current behavior was driven by an a
201 - 300 of 1572 matches
Mail list logo
