On Thu, Nov 18, 2021 at 8:38 AM Paul Eggert wrote:
> I spotted a SELinux security-context race introduced by the circa-2012
> fix for Bug#11100, and installed the attached patch into coreutils
> master. This also gets rid of a label and goto (which is what led me to
> find the issue).
Nice! Thank
Uname -v reports this:
Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021;
root:xnu-7195.141.6~3/RELEASE_X86_64
Sorry, I don't have time to delve into this, but here's the log from
the sole test failure:
pipe-f.log
Description: Binary data
Thanks for all your recent changes! I built+tested with ASAN on Fedora 34:
Configure and build as usual, then "make clean" and do this:
> san='-fsanitize-address-use-after-scope -fsanitize=address -static-libasan';
> ASAN_OPTIONS=detect_leaks=0 , CFLAGS='-O -ggdb3' AM_CFLAGS="$san"
> AM_LDFLAGS=
On Wed, Aug 25, 2021, 4:37 PM Bernhard Voelker
wrote:
> On 8/25/21 10:38 AM, Jim Meyering wrote:
> > * cfg.mk (exclude_file_name_regexp--sc_system_h_headers):
> > Add find-mount-point.h to the regexp.
>
> +1
> even better, thanks.
>
Thanks. Pushed.
>
On Tue, Aug 24, 2021 at 11:10 PM Paul Eggert wrote:
> On 8/24/21 12:42 PM, Bernhard Voelker wrote:
> > Was there a particular reason to include stdlib.h?
>
> It's needed to declare 'free', which is used by _GL_ATTRIBUTE_DEALLOC_FREE.
>
> I added "#include " so that find-mount-point.h would be an
On Tue, Aug 17, 2021 at 2:02 AM Pádraig Brady wrote:
> On 16/08/2021 22:17, Assaf Gordon wrote:
> > Hello Emil and all,
> >
> > Thanks for the clear and easily reproducible bug report.
> >
> > Attached a suggested fix.
> > Comments very welcomed,
>
> minor nit in NEWS:
> s/silently discard/silentl
tags 45093 notabug
close 45093
stop
On Mon, Dec 7, 2020 at 9:11 AM Paul Eggert wrote:
> On 12/6/20 8:23 PM, Robert S. Kissel wrote:
> > I'm pretty sure this is a bug in the Windoze port of head and tail,
>
> You should have better luck writing directly to the people who prepared that
> port, as t
On Mon, Oct 26, 2020 at 6:13 AM Pádraig Brady wrote:
> On 26/10/2020 10:44, Kamil Dudka wrote:
> > The workaround triggers warnings with new kernel versions in case
> > a user does not have sufficient privileges for the MTIOCGET ioctl.
> >
> > * src/dd.c (skip_via_lseek): Drop wrapper function no
On Mon, Feb 3, 2020 at 5:28 AM Pádraig Brady wrote:
...
> Actually I think the key issue is not errno handling,
> but a logic error fixed with:
>
> @@ -102,7 +102,7 @@ ignorable_failure (int error_number, char const *dir)
> return (ignore_fail_on_non_empty
> && (errno_rmdir_non_emp
On Sun, Feb 2, 2020 at 5:11 AM Bernhard Voelker
wrote:
> On 2020-02-02 07:32, Jim Meyering wrote:
> > FTR, here's a minimal test addition that exercises the bug. Succeeds
> > on 6.10, fails on 6.11:
>
> Minor tweak for the test ...
>
> -rmdir --ignore-fail-on-non-e
On Fri, Jan 31, 2020 at 9:55 AM Pádraig Brady wrote:
> ...
> This looks like a regression introduced in v6.10-21-ged5c4e7
> I.E. is_empty_dir() is globbering errno, and thus
> a non specific and non terminating warning is output,
> rather than a specific error, and exit.
FTR, here's a minimal tes
Nice find and thank you for the patch. That's a 12-year-old bug I introduced.
I confirm: with 6.10, running this:
mkdir -p a/b && chmod a-w a && rmdir --ignore a/b
prints this and exits nonzero:
rmdir: failed to remove `a/b': Permission denied
With 6.11 and newer, it silently succeeds.
On Fri
27;uniq' uses the equivalent of strcmp (byte comparison). Since the two
> lines compare equal in your locale, GNU 'uniq' says there's just one line.
>
> The GNU 'uniq' behavior appears to be a consequence of this commit:
>
> commit 545c2323d493c7ed9c
On Sun, Jul 28, 2019 at 11:29 PM Assaf Gordon wrote:
...
> What do others think? If this is a desired improvement, I'll finish the
> patch with news/tests/etc.
...
> [PATCH] mv: improve ENOTEMPTY/EEXIST error message
>
> Suggested by Alex Mantel in
> https://bugs.gnu.org/36831 .
>
> $ mkdir A
On Tue, Jan 29, 2019 at 9:01 PM Pádraig Brady wrote:
> On 28/01/19 19:19, Bruno Haible wrote:
> > Hi,
> >
> > Compiling coreutils on Android produces this error:
> >
> > CC src/tail.o
> > In file included from ../src/tail.c:63:
> > ../src/fs-is-local.h: In function 'is_local_fs_type':
> >
On Tue, Mar 27, 2018 at 3:06 PM, Paul Eggert wrote:
> On 03/27/2018 10:27 AM, Karl Berry wrote:
>>
>> ls -aA also shows . and ..; maybe it shouldn't?
>
> You're right, it shouldn't. This was a bug I introduced in 2004 and I think
> you're the first to report it (!). In my defense, it wasn't offici
On Wed, Jan 3, 2018 at 8:27 AM, Kamil Dudka wrote:
> On Wednesday, January 3, 2018 4:08:51 PM CET Pádraig Brady wrote:
>> Eep, Seems like we should use RENAME_NOREPLACE in this case,
>> rather than document the caveat?
Good catch/fix. Thanks to both of you.
On Thu, Nov 23, 2017 at 2:35 PM, Pádraig Brady wrote:
...
>> So I'm leaning towards supporting --verbose which would output something
>> like:
>>
>> timeout: aborting command 'blah' with signal SIGTERM
>> timeout: aborting command 'blah' with signal SIGKILL
+ error (0, 0, _("abortin
On Mon, Nov 13, 2017 at 12:03 AM, Pádraig Brady wrote:
> On 12/11/17 22:21, Pádraig Brady wrote:
>> On 12/11/17 21:52, Paul Eggert wrote:
>>> Why doesn't lseek work for this?
>>
>> Good call, it probably would.
>> Something like the following is more acceptable
>> since it adds very little complex
tags 29164 notabug
thanks
On Mon, Nov 6, 2017 at 12:21 AM, Thomas Deutschmann wrote:
> please ignore this bug report. This is caused by Gentoo's sandbox in
> portage and no problem in coreutils. Sorry for wasting your time :/
Closing and marking as notabug
On Sun, Oct 29, 2017 at 3:34 PM, Pádraig Brady wrote:
...
>> That was discovered by Martijn Dekker, CCed, when looking for a
>> portable way to identify the file system of an arbitrary file.
>
> Yes we shouldn't hang.
>
> RE side effects, open() is a fairly innocuous operation,
> and we expect sta
On Tue, Oct 17, 2017 at 12:37 AM, Pádraig Brady wrote:
> On 16/10/17 10:49, Jim Meyering wrote:
>> On Mon, Oct 16, 2017 at 2:30 AM, Pádraig Brady wrote:
>>> On 15/10/17 18:07, Jaeseung Choi wrote:
>>>> Dear GNU team,
>>>>
>>>> While
On Mon, Oct 16, 2017 at 2:30 AM, Pádraig Brady wrote:
> On 15/10/17 18:07, Jaeseung Choi wrote:
>> Dear GNU team,
>>
>> While testing coreutils for a research purpose, we found the following
>> crash in 'stty'. Running stty with the command-line "stty eol -F AA"
>> raises a crash as below. We did
On Sun, Sep 24, 2017 at 10:34 AM, Jack Howarth
wrote:
> On Sun, Sep 24, 2017 at 1:16 PM, Jack Howarth <
...
> Attached are the tests/touch/trailing-slash.log and
> tests/touch/trailing-slash.trs files generated from a build on an APFS
> volume running 10.13 in case you can identify why that t
On Wed, Sep 20, 2017 at 10:20 PM, Pádraig Brady wrote:
> On 18/09/17 18:07, Jack Howarth wrote:
>> On Mon, Sep 18, 2017 at 7:40 PM, Jim Meyering wrote:
>>
>>> On Mon, Sep 18, 2017 at 4:26 PM, Jack Howarth
>>> wrote:
>>>> On Mon, Sep 18, 2017 at 5
On Mon, Sep 18, 2017 at 4:26 PM, Jack Howarth
wrote:
> On Mon, Sep 18, 2017 at 5:08 PM, Jim Meyering wrote:
...
>> Is there any chance your failing test was via a python2 framework? I'm
>> asking (on Pádraig's behalf) because there is a known problem whereby
>> SIG
On Mon, Sep 18, 2017 at 1:18 PM, Jack Howarth
wrote:
> The coreutils 8.28 release, when built on macOS 10.13 under the new APFS
> filesystem, produces a hang during the test suite run. The hang appears to
> occur in the execution of coreutils-8.28/tests/split/filter.sh at..
>
> + yes
> + head -n20
On Sat, Sep 16, 2017 at 11:27 PM, Assaf Gordon wrote:
...
> Attached an updated patch with all instances of 'parameter'
> changed to 'argument'.
Looks fine. Thank you!
I marked the issue as "done".
On Fri, Sep 15, 2017 at 8:37 PM, Pádraig Brady wrote:
...
> That's a good improvement!
Indeed!
>
> I'd change:
>
> s/missing more parameters after/missing parameter after/
Or, perhaps use wording similar to what test does:
..._("missing argument after %s")
On Sun, Aug 13, 2017 at 1:07 AM, Pádraig Brady wrote:
> On 11/08/17 11:49, A. Wilcox wrote:
>
>> FAIL: tests/misc/csplit-io-err
>> ==
> This was due to an inconsistency in the errors output by seq.
> A fix for that buglet is attached.
>
>> FAIL: tests/misc/printf-surpri
On Sat, Jun 17, 2017 at 3:57 PM, Pádraig Brady wrote:
> On 17/06/17 14:30, Pádraig Brady wrote:
>> On 17/06/17 07:35, Jim Meyering wrote:
>>> In this new function, please move the declaration of "i" into the for-loop:
>>>
>>> +static bool
>>&
On Sat, Jun 17, 2017 at 1:32 AM, Pádraig Brady wrote:
...
> Two proposed patches for this are attached.
Nice fixes. Thank you!
In the NEWS addition:
tail -f will now exit immediately if the output is piped
and the reader of the pipe terminates.
+ tail -f will no longer erroneously warn
On Wed, Feb 15, 2017 at 11:46 AM, Paul Eggert wrote:
> I see some problems with this followup patch:
>
> http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=bd4bb42d65aac6591277066739ca42d1ddcc2d0e
>
> in that it will make force-link.c and force-link.h harder to move to gnulib.
> Is there so
On Mon, Jan 9, 2017 at 1:31 AM, Pádraig Brady wrote:
> On 08/01/17 20:08, Pádraig Brady wrote:
>> On 08/01/17 18:14, Dave B wrote:
>>> Would it be possible "one day" for stty to parse the command line args,
>>> and only open the port when all the specified parameters are actually in
>>> force?
>>
On Mon, Dec 12, 2016 at 11:04 AM, Christian González
wrote:
> I recently started id on my server
>
> id -z root
>
> And it told me in German
>
> "id: die Option --zero ist im Sandardformat nicht zulässig"
>
> But "Sandardformat" is no word. It should mean "Standardformat".
>
> If you had a bug tra
On Sun, Nov 27, 2016 at 7:40 AM, Pádraig Brady wrote:
> I'll push the attached later
Thanks to both of you.
That patch looks fine, modulo a formatting nit: the second line is
indented one space too far:
+ f->ignore = ! (reopen_inaccessible_files
+ && fo
On Wed, Nov 23, 2016 at 5:16 PM, Marcel Böhme wrote:
> Hi Pádraig,
>
>> On 24 Nov 2016, at 8:45 AM, Pádraig Brady wrote:
>>
>> I can't reproduce the issue here BTW with ASAN and running in a tight
>> loop for a few minutes. So perhaps it has been fixed in glibc already?
>> I have glibc-2.22-10.f
On Wed, Nov 23, 2016 at 4:21 PM, Pádraig Brady wrote:
> On 23/11/16 22:16, Pádraig Brady wrote:
>> On 23/11/16 17:30, Jim Meyering wrote:
>>> On Wed, Nov 23, 2016 at 5:22 AM, Marcel Böhme
>>> wrote:
>>>> Dear all,
>>>>
>>>> We ar
On Wed, Nov 23, 2016 at 5:22 AM, Marcel Böhme wrote:
> Dear all,
>
> We are running small 1h fuzzing sessions with AFLFast, a fork of AFL.
> We’ll be reporting each found bug separately.
>
> On Coreutils v8.25 and trunk, the following input crashes.
> Option -n was introduced with v8.8.
>
> $ ./sp
On Wed, Sep 14, 2016 at 7:13 AM, Antonio Ospite wrote:
> * src/dircolors.hin: Add .mjpg and .mjpeg multimedia files.
> ---
>
> Please CC me on reply, I am not subscribed.
>
> Thanks,
>Antonio
>
> src/dircolors.hin | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/dircolors.hin b/
On Fri, Nov 4, 2016 at 12:03 PM, Pádraig Brady wrote:
> On 04/11/16 16:20, Pádraig Brady wrote:
>> On 04/11/16 11:19, Stephan Bauroth wrote:
>>> Dear coreutils team :)
>>>
>>> I encountered a buglike behaviour of dd when handling skip and count
>>> parameters that are encoded in hex and thus prefi
On Tue, Oct 4, 2016 at 5:54 AM, Pádraig Brady wrote:
> On 04/10/16 12:38, Pádraig Brady wrote:
>> On 04/10/16 03:21, Mohammed Sadiq wrote:
>>> '--no-preserve-root' that can be used to ignore if the path is root when
>>> using
>>> the 'rm' command.
>>>
>>> But as the most of the GNU commands accep
On Tue, Sep 6, 2016 at 10:05 AM, Paul Eggert wrote:
> On 09/06/2016 08:59 AM, Pádraig Brady wrote:
>>
>> Will push later.
>
>
> Before pushing, can you please change the name of "sigs" back to "sig"? I
> prefer the old name, as "sig[i]" clearly means "signal i", whereas "sigs[i]"
> is more confusi
On Thu, Aug 18, 2016 at 5:57 AM, Pádraig Brady wrote:
> On 17/08/16 12:42, Mark Mitchell wrote:
>> Hi,
>>
>> I'm writing to report a potential bug with cp. I don't think the mode bits
>> always get properly set on directories created when using the --parents
>> option combined with --no-preserve=
On Thu, Jun 23, 2016 at 7:26 AM, Pádraig Brady wrote:
> On 23/06/16 08:13, Paul Eggert wrote:
>> Incidentally, 'yes' has a different bug: it mishandles the case where
>> 'write' succeeds but returns a value less than the buffer size. I'll try
>> to look into that too. Simplest would be to use stdi
src/md5sum.c:870:3: error: assuming signed overflow does not occur \
when simplifying conditional to constant [-Werror=strict-overflow]
* src/md5sum.c (main): Use an unsigned variable as the loop index,
rather than optind.
From 8912aa7c6dc7acb76d2de648e89098943bfe149a Mon Sep 17 00:
tags 23537 notabug
stop
On Sun, May 15, 2016 at 8:06 AM, Jim Meyering wrote:
> On Sun, May 15, 2016 at 4:21 AM, Pádraig Brady wrote:
>> Has up to date centos6 the bug?
>> I didn't see it with glibc-2.12-1.166.el6_7.7.x86_64
>
> Yes. I am surprised that you don't
On Sun, May 15, 2016 at 4:21 AM, Pádraig Brady wrote:
> Has up to date centos6 the bug?
> I didn't see it with glibc-2.12-1.166.el6_7.7.x86_64
Yes. I am surprised that you don't see it and I do:
$ rpm -q glibc
glibc-2.12-1.166.el6_7.7.x86_64
$ src/timeout 0.1 sleep 1.189731495357231765e+49
On systems with recent glibc, this abuse of timeout elicits the expected error:
$ src/timeout -- -1.189731495357231765e+4932 sleep 0
src/timeout: invalid time interval ‘-1.189731495357231765e+4932’
Try 'src/timeout --help' for more information.
But with glibc-2.12's strtod, that input maps
On Thu, May 5, 2016 at 1:54 AM, Bernhard Voelker
wrote:
> On 05/04/2016 05:08 PM, Jim Meyering wrote:
>> Subject: [PATCH] maint: avoid new warning from gcc (GCC) 7.0.0 20160503
>> (experimental)
>>
>> * src/id.c (main): When configured with --enable-gcc-warnings and u
On Wed, May 4, 2016 at 12:40 AM, Bernhard Voelker
wrote:
> On 05/04/2016 05:59 AM, Jim Meyering wrote:
>> - bool default_format = (just_user + just_group + just_group_list
>> + bool default_format = (0U + just_user + just_group + just_group_list
>>
On Tue, May 3, 2016 at 8:59 PM, Jim Meyering wrote:
> coreutils failed to build when configured with --enable-gcc-warnings
> and the latest gcc built from git.
>
> Here's a patch to fix that:
One nit in the commit log, fixed locally: s/U0/0U/
coreutils failed to build when configured with --enable-gcc-warnings
and the latest gcc built from git.
Here's a patch to fix that:
From e22ff987e4d3c29b445b3e94de65c633f8a05870 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 3 May 2016 20:56:20 -0700
Subject: [PATCH] maint: avoi
On Sun, Mar 20, 2016 at 5:59 PM, William R. Fraser wrote:
> When wc gets its list of files by reading from stdin, using the argument
> '--from-files0=-', it reuses the same fstatus struct for each file.
>
> The problem is that the 'wc' function checks the 'failed' member of this
> struct and if it
On Sun, Mar 6, 2016 at 7:36 PM, Jim Meyering wrote:
> The split/filter.sh test would fail like this:
>
> $ make check TESTS=tests/split/filter.sh VERBOSE=yes SUBDIRS=.
> + truncate -s9223372036854775807 zero.in
> + timeout 10 sh -c 'split --filter="head -c1
On Sun, Mar 6, 2016 at 7:36 PM, Jim Meyering wrote:
> The split/filter.sh test would fail like this:
>
> $ make check TESTS=tests/split/filter.sh VERBOSE=yes SUBDIRS=.
> + truncate -s9223372036854775807 zero.in
> + timeout 10 sh -c 'split --filter="head -c1
date the commit log with the issue URL as soon as it's assigned]
From 889415ab359c943ee4c358f8c5fb07bca95a4ead Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 6 Mar 2016 16:38:01 -0800
Subject: [PATCH] tests: avoid false-failure of split/filter.sh on XFS
* tests/split/filter.sh: Use OFF_T_M
On Fri, Mar 4, 2016 at 9:50 AM, Jim Meyering wrote:
> On Fri, Mar 4, 2016 at 9:12 AM, Pádraig Brady wrote:
>> On 04/03/16 08:55, Eric Blake wrote:
> ...
>>> +NOTE: Use of binary -a and -o create inherently ambiguous situations.
>
> I like that, too. Thanks. One nit: s/
On Fri, Mar 4, 2016 at 9:12 AM, Pádraig Brady wrote:
> On 04/03/16 08:55, Eric Blake wrote:
...
>> +NOTE: Use of binary -a and -o create inherently ambiguous situations.
I like that, too. Thanks. One nit: s/create/creates/
On Wed, Feb 17, 2016 at 8:46 AM, Mike Hodson wrote:
>>On Tue, Feb 16, 2016 at 6:45 AM, Bernhard Voelker
>>wrote:
>>> On 02/16/2016 11:50 AM, Jason A. Donenfeld wrote:
>>> [...] We don't want those single quotes.
>>
>>
>> Who exactly is "we"?
>>
>> I can only speak for myself: I'm don't really ca
On Fri, Feb 5, 2016 at 11:29 AM, Eric Blake wrote:
> On 02/05/2016 11:30 AM, SasQ wrote:
>
>>
>> OK, this convinces me this is not a bug. 4m30 on my machine.
>> But it's definitely a user-interface fail ;)
>> It should at least output some warning that the computations might
>> take longer, or dis
On Mon, Nov 30, 2015 at 6:52 AM, Pádraig Brady wrote:
> On 29/11/15 23:35, Bernhard Voelker wrote:
>> On 11/29/2015 12:16 AM, Pádraig Brady wrote:
>>> I remember having slight reservations about K too.
>>> http://lists.gnu.org/archive/html/bug-coreutils/2009-05/msg00279.html
>>> Nothing much bette
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 Wed, Oct 28, 2015 at 7:10 AM, Bernhard Voelker
wrote:
> On 10/28/2015 11:00 AM, Pádraig Brady wrote:
>>
>> Reopened until someone else votes.
>
> I'm 50:50 regarding the usefulness of --verbose.
> Writing "killed PRG after N seconds elapsed" sounds like a useful
> message, yet I'm afraid that t
On Mon, Aug 31, 2015 at 10:13 AM, Pádraig Brady wrote:
> I'll apply the attached later.
Nice. Thanks to both of you.
On Mon, Jul 6, 2015 at 5:45 PM, Pádraig Brady wrote:
> On 07/07/15 00:29, Hanno Böck wrote:
>> Hi,
>>
>> There is an out of bounds read error in the function genpattern() in
>> shred (coreutils 8.23). This issue only appears randomly.
>>
>> To test:
>> a) recompile coreutils 8.23 with address sani
On Tue, Jun 30, 2015 at 9:36 AM, Paul Eggert wrote:
> Jim Meyering wrote:
>
>> same result as before:
>
> OK, let's give up on this approach and try something more direct. I
> installed the attached patch; does it work on OS X?
Perfect.
I made latest coreutils use late
On Mon, Jun 29, 2015 at 7:19 PM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> Darn it. I see that I mistakenly pushed one of your patches
>> when I pushed the linkat.m4 fix, Paul. Sorry about that.
>> Happy to revert, if you'd like that. Let me know.
>
>
On Mon, Jun 29, 2015 at 2:01 PM, Jim Meyering wrote:
> On Mon, Jun 29, 2015 at 11:39 AM, Paul Eggert wrote:
>> Jim Meyering wrote:
>>>
>>> the first variant compiled
>>> just fine here (and probably everywhere),
>>> so HAVE_GETGROUPLIST_WITH_INT was
On Mon, Jun 29, 2015 at 11:39 AM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> the first variant compiled
>> just fine here (and probably everywhere),
>> so HAVE_GETGROUPLIST_WITH_INT was not defined.
>
>
> Yes, well, it did work on GNU/Linux, which is what
On Sun, Jun 28, 2015 at 11:48 PM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> I compiled the just-published snapshot on OS X configured with
>> --enable-gcc-warnings, and saw this:
>>
>> lib/mgetgroups.c: In function 'mgetgroups':
>> lib/mget
I compiled the just-published snapshot on OS X configured with
--enable-gcc-warnings, and saw this:
lib/mgetgroups.c: In function 'mgetgroups':
lib/mgetgroups.c:90:45: error: pointer targets in passing argument 3
of 'getgrouplist' differ in signedness [-Werror=pointer-sign]
ng = getgrou
On Sun, May 10, 2015 at 7:17 AM, Paul Eggert wrote:
> Jim Meyering wrote:
>>
>> + return err == EOPNOTSUPP
>> +#if ENOTSUP != EOPNOTSUPP
>> +|| err == ENOTSUP
>> +#endif
>> +;
>
> Would the following work instead? It's a bit cl
Building with very new gcc-from-git, I encountered 3 new warnings.
Here's a patch to address them:
Without this change, very recent gcc (e.g., version 6.0.0 20150509)
would print the following when configured with --enable-gcc-warnings:
src/copy.c:165:30: error: logical 'or' of equal expression
On Sun, Apr 19, 2015 at 8:27 AM, Ma Jiehong wrote:
> The translation in the help message is not wrong, and "TARGET" and
> "LINK_NAME" are used.
>
> The issue simply is with the mental model made when approaching the "ln"
> command. In French, the usual way to say when creating a link is: "Je vais
On Fri, Mar 27, 2015 at 7:14 PM, Jim Meyering wrote:
> On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert wrote:
>> Isaac Schwabacher wrote:
>>
>>> This is confusing at best
>>
>> Yes, at the very least the documentation should be improved. I installed
>
On Fri, Mar 27, 2015 at 3:11 PM, Paul Eggert wrote:
> Isaac Schwabacher wrote:
>
>> This is confusing at best
>
> Yes, at the very least the documentation should be improved. I installed
> the attached patch to try to do that.
>
>> Is it really better for a read on stdin to fail with EBADF rather
On Mon, Mar 16, 2015 at 5:15 AM, Pádraig Brady wrote:
...
> Yes you're right Bruno.
> Multi-byte support in coreutils in general has languished,
> but we hope to start improving support in the next major release (9?)
> after the current imminent 8.24 stable release.
>
> To that end I've put togeth
On Mon, Mar 2, 2015 at 1:29 PM, Linda Walsh wrote:
>
>
> Jim Meyering wrote:
>>>
>>> As root:
>>> # cd /proc
>>> # find -H [^0-9]* -name self -prune -o -name thread-self -prune -o -type
>>> f !
>>> -name kmsg ! -name kcore ! -name kp
On Sat, Feb 28, 2015 at 12:59 AM, Linda Walsh wrote:
> (coreutils-8.21-7.7.7)
>
> wc -c(bytes) doesn't seem to reliably read the number
> of bytes in a file.
>
> I was wanting to find out what the largest data-source
> files in '/proc' and '/sys' (didn't get around to trying
> /sys, since all the
On Sun, Jan 4, 2015 at 9:43 AM, Pádraig Brady wrote:
...
> BTW, it might have been nice to have the initial git commits
> for these tools attributed to the original author. Hindsight and all that :)
It would have been nice, indeed.
When I agreed to do the job of maintaining the fileutils, textut
On Sun, Jan 4, 2015 at 7:53 AM, Pádraig Brady wrote:
...
> Also there is the more general point about how correct
> it is to attribute a program to author(s) in any case,
> as that tracked to a much more accurate level of detail
> by git blame etc. Should we be removing output of
> author names a
On Sun, Dec 28, 2014 at 12:33 AM, Jari Aalto wrote:
> It would be nice to see progress of touched files. Please
> add option[1]:
Hi Jari,
My preference is to avoid adding the --verbose option
to programs like touch. Here is some explanation for
why I have seriously considered taking the relative
On Mon, Dec 15, 2014 at 9:11 PM, KO Myung-Hun wrote:
> Jim Meyering wrote:
>> On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun wrote:
>>> Paul Eggert wrote:
>>>> KO Myung-Hun wrote:
>>>>> /* Redirection and wildcarding when done by the utility its
On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun wrote:
> Paul Eggert wrote:
>> KO Myung-Hun wrote:
>>> /* Redirection and wildcarding when done by the utility itself.
>>> Generally a noop, but used in particular for native VMS. */
>>> #ifndef initialize_main
>>> -# define initialize_main(ac
On Mon, Dec 15, 2014 at 12:57 AM, Pádraig Brady wrote:
> On 15/12/14 01:15, KO Myung-Hun wrote:
>>
>>
>> Pádraig Brady wrote:
>>> forcemerge 19378 19377
>>> stop
>>>
>>> On 14/12/14 03:47, KO Myung-Hun wrote:
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
*
On Sun, Dec 14, 2014 at 5:25 AM, Pádraig Brady wrote:
> forcemerge 19376 19377
> stop
>
> On 14/12/14 03:47, KO Myung-Hun wrote:
>> This fixes the following error.
>>
>> -
>> Can't do inplace edit without backup.
>> -
>>
>> * Makefile.am (dist-hook): Use -pi.bak instead of -pi.
>> * bootst
On Tue, Oct 7, 2014 at 5:36 PM, Pádraig Brady wrote:
> On 10/08/2014 12:51 AM, Paul Eggert wrote:
>> Paul Eggert wrote:
>>
>>> The attached patch still needs a changelog entry and test cases.
>>
>> I wrote those up and pushed the attached patch; this should fix the bug so
>> I'm closing the bug r
On Fri, Oct 3, 2014 at 9:48 AM, Pádraig Brady wrote:
> On 10/03/2014 03:47 PM, George Shuklin wrote:
...
> I'm not sure where the above code comes from,
> by coreutils trunk has the same behavior with these files.
> We could avoid it with the following patch.
> Note in the case where "real" small
On Sat, Jul 19, 2014 at 8:45 AM, Bernhard Voelker
wrote:
> On 07/19/2014 04:57 PM, Paul Eggert wrote:
>> From: Paul Eggert
>> [...]
>> Problem reported by Sebastian Rasmussen in: http://bugs.gnu.org/18054
>
> This feels wrong.
> As Padraig often said, we should encourage people to contribute
> to
On Thu, Jul 10, 2014 at 4:28 PM, Pádraig Brady wrote:
> The attached should handle this by giving precedence
> to displaying real device nodes.
Thanks. That looks fine.
I'd add an "s" to that NEWS entry: s/give/gives/
+ df now give precedence to displaying real device nodes in the presence of
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
Looks fine. Two nits barely worth mentioning: one in the .texi file:
s/group in/group of/
one in the log:
s/\*man/* man/
Also, in the relative formality of documentation,
it's slightly better to write "It is" than "It's"
On Mon, May 26, 2014 at 1:25 AM, Pádraig Brady wrote:
> On 05/25/2014 11:19 PM, Jim Meyering wrote:
>> On Sun, May 25, 2014 at 1:31 PM, Pádraig Brady wrote:
>>> On 05/25/2014 08:48 PM, Jim Meyering wrote:
>>>> Without the attached patch, I'd get this new link f
On Sun, May 25, 2014 at 1:31 PM, Pádraig Brady wrote:
> On 05/25/2014 08:48 PM, Jim Meyering wrote:
>> Without the attached patch, I'd get this new link failure on OS X:
>>
>> Undefined symbols for architecture x86_64:
>> "_libintl_gettext"
Without the attached patch, I'd get this new link failure on OS X:
Undefined symbols for architecture x86_64:
"_libintl_gettext", referenced from:
_apply_mode in src_libstdbuf_so-libstdbuf.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]:
On Sat, May 10, 2014 at 11:42 AM, Paul Eggert wrote:
> * src/shred.c (main): Limit -n (number of passes) value to
> ULONG_MAX, not to UINT32_MAX, since the vars are unsigned long.
> Limit the -s (file size) value to OFF_T_MAX.
> ---
> src/shred.c | 9 +
> 1 file changed, 5 insertions(+),
On Mon, Apr 28, 2014 at 6:52 AM, Pádraig Brady wrote:
...
>> I see it here too (as the only failure in make check with -fsanitize=address
>
> The attached should address this.
Thanks for taking the time to address that.
The patch looks fine, modulo what looks like an accidentally-added
empty line
1 - 100 of 5263 matches
Mail list logo
