Bernhard Voelker wrote:
> FAIL: misc/tty-eof (exit: 1)
>
>
> F: 1: YSBiCg==
> F: 1: a b
> F: 1: 780509149 4
> F: 1: a b
> F: 1: a b
> F: 1: a b
> F: 1: a b
> F: 1: a b
> F: 1: 7557d2f3a6ad1a3a8ebd23a94ab0c642 -
> F: 1: 1a b
> F: 1: 000 020141 005142
> F: 1
Pádraig Brady wrote:
...
>> df --printf="%U\0%s\0%m\0\n"
>>
>> As already said, this would be a greater change in df.c,
>> but some code could surely be shared with stat.c and maybe
>> in future with "ls --format=..." ;-)
>>
>> I'm not against --output, but the advantage of a more
>> flexible --p
Pádraig Brady wrote:
...
> Thanks for looking into that Alan, and thanks for reporting this Jean-Pierre.
> I've installed the attached to document the fix and add a test.
...
> Subject: [PATCH] tests: add a test for a previously fixed output format bug
> in join
>
> Add a test and NEWS entry for a
Kamil Dudka wrote:
> On Sunday, July 22, 2012 14:40:46 Jim Meyering wrote:
>> When already using --color, we do get each test result for free
>
> Not really. The check for file capabilities is optional even with --color.
> The 'ca' indicator in $LS_COLORS needs to be s
Luk Claes wrote:
...
> But it apparently does not show when capabilites are active, could that
> be added (or was that added in the meantime in a subsequent version)?
>
> $ setcap cap_chown+ep foo
>
> $ ls -l foo
> -rw-r--r-- 1 luk luk 5 Jul 22 00:37 foo
>
> $ sudo getcap foo
> foo = cap_chown+ep
Erik Auerswald wrote:
> On Fri, Jul 20, 2012 at 01:54:21AM +0800, jida...@jidanni.org wrote:
>> sort(1) doesn't say SEE ALSO uniq(1), and vice versa.
>
> The small attached patch adds that.
...
> Subject: [PATCH] doc: mention uniq(1) in sort(1) man-page and vice versa
>
> * man/sort.x: Add SEE ALSO
Joachim Schmitz wrote:
...
>> You can make it easier for us to process your coreutils patches by
> separating
>> them into conceptually-related sets, with commit log entries following
>> HACKING's guidelines.
>
> OK, will try in futur...
>
> Would you accept git pull requests?
Sure, but please als
Joachim Schmitz wrote:
>> However, note that you're using an old version of coreutils. In the
> latest, su.c
>> has been removed so you can drop the patches to that file.
>
> Huh? 8.17 is old? It's the latest I could get and still has src/su.c.
> Anyway, that patch isn't needed for NonStop anyway,
Joachim Schmitz wrote:
>> From: Jim Meyering [mailto:j...@meyering.net]
>> Sent: Friday, July 20, 2012 3:48 PM
>> To: Joachim Schmitz
>> Cc: 'Paul Eggert'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric
> Blake';
>> 'Schmitz, Joachim
Joachim Schmitz wrote:
...
> I just saw that my patch removed 2 functions more than your's, mine also
> removes cache_stat_ok() and is_nondir_lstat().
> Intention? Used where?
Here's the patch:
>From c1263bb95e8ff84e819753c9050b96d16441aa81 Mon Sep 17 00:00:00 2001
From: Joachim Schmitz
Date: Fr
Joachim Schmitz wrote:
...
> I just saw that my patch removed 2 functions more than your's, mine also
> removes cache_stat_ok() and is_nondir_lstat().
> Intention? Used where?
Hah! I should have temporarily defined-away "inline" to be sure I'd
removed all of them -- then gcc warns about each defi
Joachim Schmitz wrote:
>> From: Jim Meyering [mailto:j...@meyering.net]
>> Sent: Friday, July 20, 2012 2:35 PM
>> To: Joachim Schmitz
>> Cc: 'Paul Eggert'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric
> Blake';
>> 'Schmitz, Joachim
Joachim Schmitz wrote:
...
> I've disable a bit of apparently dead code in src/remove.c
...
> /usr/local/bin/diff -EBbu ./src/remove.c.orig ./src/remove.c
> --- ./src/remove.c.orig 2012-05-01 15:55:08 -0500
> +++ ./src/remove.c2012-06-18 10:06:04 -0500
> @@ -88,6 +88,7 @@
>return st;
tags 11950 moreinfo
thanks
Alan Curry wrote:
...
> It's called directory order. It used to be simply order of creation of
> files, with deletions creating gaps that could be filled by later
> creations with same-length or shorter names.
Thanks for the report Michael,
and thanks for replying, Alan
Paul Eggert wrote:
> On 07/12/2012 02:27 PM, Jim Meyering wrote:
>> I didn't really understand the cause
>
> That one is one of my least favorite warnings
> because sometimes it warns about real bugs but
> often, as in your case, the warning is either
> bogus or so har
Pádraig Brady wrote:
> On 07/12/2012 05:11 PM, Pádraig Brady wrote:
>> On 07/12/2012 04:35 PM, Paul Eggert wrote:
>>> On 07/12/2012 08:28 AM, Pádraig Brady wrote:
more problematically it would change the output from
the lib
>>>
>>> Ah, sorry, I was talking only about df's output,
>>> inde
[mostly for the record, and so I don't forget.
I'm not ready to push this just yet. ]
Building shred with fedora 17 and its stock gcc 4.7 on i686,
I see this warning/error:
CC shred.o
shred.c: In function 'dopass':
shred.c:501:14: error: assuming signed overflow does not occur when
Bernhard Voelker wrote:
> Subject: [PATCH] df: Warn if soon-to-be-removed --megabyte option is used
>
> * src/df.c: MEGABYTES_OPTION: Add new enum and mark it to be removed
> in August 2013.
> * src/df.c (long_options): Use MEGABYTES_OPTION for --megabytes option.
> * src/df.c (main): Add case for
Bernhard Voelker wrote:
> On 07/05/2012 02:35 PM, Jim Meyering wrote:
>> However, I'm tempted to remove it directly this time, since it's been
>> undocumented for a while:
>>
>> 5 years in df.1 and df --help: COREUTILS-6_9-151-g1e07a21
>> 11 years in
Bernhard Voelker wrote:
> On 07/04/2012 09:38 PM, Paul Eggert wrote:
>> On 07/04/2012 01:11 AM, Andreas Jaeger wrote:
>>> df -k and df -m both work but only df -k is mentioned as part of df --
>>> help. So, the omission to document -m is IMO a bug.
>>
>> I think the general idea is that -k was a mi
Bernhard Voelker wrote:
> After pulling to the lastest revision (v8.17-37-g74427c7) and
> a successful build (make -j), a subsequent "make syntax-check -j"
> failed:
>
> ...
> 8.47 vulnerable_makefile_CVE-2009-4029
> 8.78 copyright_check
> CC hostname.o
> CCLD arch
> CCLD
Jim Meyering wrote:
> Bruno Haible wrote:
>> Jim Meyering wrote:
>>> +static inline unsigned char to_uchar (char ch) { return ch; }
>>
>> For the use of 'inline', one needs this too:
>> +++ m4/parse-datetime.m4 Wed Jul 4 10:04:36 2012
>
Bruno Haible wrote:
> Jim Meyering wrote:
>> +static inline unsigned char to_uchar (char ch) { return ch; }
>
> For the use of 'inline', one needs this too:
> +++ m4/parse-datetime.m4 Wed Jul 4 10:04:36 2012
> + AC_REQUIRE([AC_C_INLINE])
Thanks, Bruno.
H
peter evans wrote:
> Thank you for closing this as "not a bug".
>
> So it is not a bug that date is unable to parse its own output in
> arbitrary locales.
> Indeed, it would "not be a bug" if it stopped and complained about
> it. That would be
> perfectly acceptable.
>
> "date" however, goes one be
Paul Eggert wrote:
> On 07/02/2012 10:04 AM, Jim Meyering wrote:
>> - read+stat all mount points at start-up
>
> This sounds like it might have problems on hosts that have
> lots of mount points, or where some mount points are remote.
> I've been on many syste
Paul Eggert wrote:
> Thanks for the improvement.
> How about the following patch to simplify this a bit?
> It removes a call to fdopen, among other things.
>
>>From 05cc1b416a47330ef296dbeadd2a4b6095fe5c7d Mon Sep 17 00:00:00 2001
> From: Paul Eggert
> Date: Mon, 2 Jul 2012 15:47:03 -0700
> Subjec
Bob Proulx wrote:
...
> I updated the 'date' FAQ section with an example of this type of usage.
>
>
> http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
Nice. Thanks, Bob!
Andreas Schwab wrote:
> Jim Meyering writes:
>
>> To get the behavior you want (a nominally no-op date-setting command),
>> you should use this instead:
>>
>> date -s "$(date '+%F %T.%N')"
>
> That fails to be a no-op during the ambigo
du and other fts-using tools like rm, chmod, chown, chgrp, etc.
must detect directory cycles. Such cycles can indicate disk corruption
or (when following symlinks) a merely-ignorable cycle.
There is also the issue of how these tools treat a bind-mount-induced
directory cycle. One might hope that
Pádraig Brady wrote:
>...
> diff --git a/tests/misc/sort-exit-early b/tests/misc/sort-exit-early
...
> +test $? == 124 && fail=1
> +
> +# Check all inputs are readable before starting to sort
> +# Also ensure the output isn't created in this case
> +touch output
> +chmod a-r output
> +timeout 10 so
peter evans wrote:
> Operating system is redhat 6.1
> Version of coreutils is 8.4 according to yum.
>
> System LANG is set to:
> LANG=ja_JP.UTF-8
>
> ---8<-
> [root@x]# ntpdate ntp.server
> 2 Jul 16:14:04 ntpdate[18848]: adjust time server 1.2.3.4 offset -0.002628
Pádraig Brady wrote:
...
> Subject: [PATCH] sort: avoid redundant processing with inaccessible inputs or
> output
>
> * src/sort.c (check_inputs): A new function to verify all inputs
> are accessible before further processing.
> (check_output): A new function to open or create a specified
> output
Jim Meyering wrote:
> Michael Mol wrote:
>> "tail: unrecognized file system type 0x61756673 for
>> ‘/var/log/messages’. please report this to bug-coreutils@gnu.org.
>> reverting to polling"
>>
>> At the time, mount indicated the filesystem in question w
hows a description of it: "aufs - advanced multi
> layered unification filesystem. version 3.3-20120326"
>
> This was on the Gentoo 12.1 liveDVD.
Thank you!
Here's the patch I expect to push soon:
>From b0d8d3242998852e1a8a58b3f1b48186ad1063ec Mon Sep 17 00:00:00 2001
From: J
Jim Meyering wrote:
> Bernhard Voelker wrote:
>> On 06/29/2012 10:48 AM, Jim Meyering wrote:
>>> Here's the doc patch I suggested, but I'll hold off for now.
>>> I'd like to hear if anyone thinks it's worth adding a new option,
>>> which wo
Bernhard Voelker wrote:
> On 06/29/2012 10:48 AM, Jim Meyering wrote:
>> Here's the doc patch I suggested, but I'll hold off for now.
>> I'd like to hear if anyone thinks it's worth adding a new option,
>> which would obviate such a script.
>
>
Jim Meyering wrote:
> jida...@jidanni.org wrote:
>> (info "(coreutils) Backup options") should add some examples, for
>> "So how do we make a backup file of m?"
>> $ ls
>> m
>> $ cp -b m m #no go
>
> Thanks for the suggestion.
> I u
jida...@jidanni.org wrote:
> OK but (info "(coreutils) Backup options") should also link back to the exact
> cp -b spot, else most folks will miss it.
>
> P.S., There _is_ an easier way of making backups of several files,
> But there is a bug, one has to do it one at a time despite -b. Bug bug bug.
jida...@jidanni.org wrote:
> (info "(coreutils) Backup options") should add some examples, for
> "So how do we make a backup file of m?"
> $ ls
> m
> $ cp -b m m #no go
Thanks for the suggestion.
I use this zsh/bash shell function:
backup ()
{
local i
for i in "$@"; do
command cp -bf "$i"
Pádraig Brady wrote:
...
> diff --git a/src/split.c b/src/split.c
> index 53ee271..3e3313a 100644
> --- a/src/split.c
> +++ b/src/split.c
> @@ -92,6 +92,9 @@ static char const *additional_suffix;
> /* Name of input file. May be "-". */
> static char *infile;
>
> +/* stat buf for input file. */
François Pinard wrote:
> Hi, Jim.
>
> I was looking for a problematic spot from a big file, and to isolate it,
> used "split" repeatedly as a way to zoom into the proper place. Just to
> try, I used "split -C 10 xad" at one place (after saving "xad"
> first, of course). "split" interrupted it
tags 11730 + notabug
close 11730
thanks
Ondrej Vasik wrote:
> This is really your misunderstanding of the shell behaviour. "*"
> character is special, it gets expanded by the shell. As this is quite
> common misunderstanding, it is part of GNU coreutils FAQ.
> http://www.gnu.org/software/coreutils
Paul Eggert wrote:
> On 06/12/2012 07:33 AM, Jim Meyering wrote:
>> Here's a way to solve the problem that doesn't require restoring
>> the memset calls. It feels slightly hackish
>
> But it's hackish in a good way! It's a bit faster
> and smaller and
tr (STDIN_FILENO, TCSADRAIN, &mode))
> error (EXIT_FAILURE, errno, "%s", device_name);
Hi Ed,
Thank you for the report and the patch.
That has prompted a nicely animated debate ;-)
Here's a way to solve the problem that doesn't require restoring
the memset ca
Anoop Sharma wrote:
> The thought behind the proposed change was that lseek should reflect
> the amount of data that head has actually been able to print.
>
> For example, how do we want head to behave in a situation like the
> following where files more than a particular size are not allowed
> (wi
Eric Blake wrote:
> On 06/06/2012 02:02 AM, Jim Meyering wrote:
>
>> +++ b/src/head.c
>> @@ -663,10 +663,9 @@ elide_tail_lines_seekable (const char *pretty_filename,
>> int fd,
>> }
>>
>>/* Output the initial portion of t
Jim Meyering wrote:
> Anoop Sharma wrote:
>> 1. The comment in code - "Don't bother testing for failure for such a
>> small amount. Any failure will be detected upon close." may be
>> re-looked too, since we are now lseeking after it.
>>
>> What i
Anoop Sharma wrote:
> 1. The comment in code - "Don't bother testing for failure for such a
> small amount. Any failure will be detected upon close." may be
> re-looked too, since we are now lseeking after it.
>
> What if we change plain fwrite to:
> if (fwrite (buffer, 1, n + 1, stdout) < (n
Jim Meyering wrote:
> Thanks, and thanks for the review. Pushed.
And with this message, I've closed the issue.
Pádraig Brady wrote:
> On 06/05/2012 07:12 PM, Jim Meyering wrote:
>> Jim Meyering wrote:
>>>>> Here's the start of a proper patch.
>>>>> To come: mention this in NEWS and add a test.
>>
>> Here's the complete patch.
>
> Nice tests.
> +1
Thanks, and thanks for the review. Pushed.
Jim Meyering wrote:
>>> Here's the start of a proper patch.
>>> To come: mention this in NEWS and add a test.
Here's the complete patch.
Figuring out how to trigger the bug in my patch
(s/start_pos/pos/) that Pádraig spotted was interesting.
No prior test case exerc
Pádraig Brady wrote:
> On 06/05/2012 11:29 AM, Jim Meyering wrote:
>> Anoop Sharma wrote:
>>> Head command does not position file pointer correctly for negative line
>>> count. Here is a demonstration of the problem.
>>>
>>> Step 1 - Create a file with
a test.
>From 0c156fb347dba3f499ed7b922af1ea357f5558c0 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 5 Jun 2012 12:24:49 +0200
Subject: [PATCH] head: with --lines=-N (-n-N) reset file pointer on seekable
input
* src/head.c (elide_tail_lines_seekable): Reset file pointer
after pr
Ludwig Nussel wrote:
> A pam aware su has now been merged into util-linux. This issue can
> therefore be closed.
Thanks for the follow-up.
I'll post a patch removing su from coreutils separately.
Mike Frysinger wrote:
> See http://st.suckless.org/
>
> * src/dircolors.hin: Add st and st-256color.
>
> Reported-by: Jeroen Roovers
> Signed-off-by: Mike Frysinger
> ---
> src/dircolors.hin |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/dircolors.hin b/src/di
e actual change ;-)
Note that Göran's name is already in the generated THANKS file,
so I didn't add it below.
If anyone listed prefers a different spelling of name or email,
just let us know.
>From 54be50197b47ba9200a1c3e48847fa959d4f5bfd Mon Sep 17 00:00:00 2001
From: Jim Meyering
Dat
Jim Meyering wrote:
> Rich Burridge wrote:
> ...
>> I've attached a patch that we are applying to the code to fix these problems.
>>
>> Here's the evaluation of why the changes have been made:
>>
>> There are three different types of Parfait errors
sp cannot be NULL when it is
dereferenced.
Are the following proposed changes enough to placate parfait?
I prefer to use assert, because that tends to work also for
static analysis tools like clang and coverity.
>From 94f417db5e093093ff9512869880e39975822be8 Mon Sep 17 00:00:00 2001
From: Jim Me
Jim Meyering wrote:
> Jim Meyering wrote:
>> Mike Frysinger wrote:
>>> coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug
>>> before, so looks like a regression with 8.17
>>>
>>> easy to show:
>>> $ sudo ln -s dev /
Jim Meyering wrote:
> Jim Meyering wrote:
>> Mike Frysinger wrote:
>>> coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug
>>> before, so looks like a regression with 8.17
>>>
>>> easy to show:
>>> $ sudo ln -s dev /
Jim Meyering wrote:
> Mike Frysinger wrote:
>> coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug
>> before, so looks like a regression with 8.17
>>
>> easy to show:
>> $ sudo ln -s dev /foo
>> $ ls --color=auto /
>> ... foo
Jim Meyering wrote:
> Mike Frysinger wrote:
>> coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug
>> before, so looks like a regression with 8.17
>>
>> easy to show:
>> $ sudo ln -s dev /foo
>> $ ls --color=auto /
>> ... foo
Mike Frysinger wrote:
> coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug
> before, so looks like a regression with 8.17
>
> easy to show:
> $ sudo ln -s dev /foo
> $ ls --color=auto /
> ... foo wrongly shows up in blinky text indicating it's a broken symlink ...
> $ ls --co
Andreas Schwab wrote:
> Paul Eggert writes:
>
>> On 05/10/2012 04:04 PM, Nikolaus Rath wrote:
>>> But why isn't
>>> it du using statvfs instead of statfs?
>>
>> m4/fsusage.m4 says why:
>>
>> Do not use statvfs on systems with GNU libc on Linux, because that function
>> stats all preceding entries
Pádraig Brady wrote:
> On 05/10/2012 07:55 AM, Paul Eggert wrote:
>> diff --git a/src/truncate.c b/src/truncate.c
>
>> @@ -348,15 +361,28 @@ main (int argc, char **argv)
>> {
>>/* FIXME: Maybe support getting size of block devices. */
>
> Can the above be removed, as I think SEEK_END
Jim Meyering wrote:
> Paul Eggert wrote:
>> On 05/09/2012 11:36 PM, Jim Meyering wrote:
>>> I see you pushed it.
>>> Thanks for adding that line to NEWS:
>>
>> You're welcome. I shook free some time to adjust the st_size patch,
>> and here
Paul Eggert wrote:
> On 05/09/2012 11:36 PM, Jim Meyering wrote:
>> I see you pushed it.
>> Thanks for adding that line to NEWS:
>
> You're welcome. I shook free some time to adjust the st_size patch,
> and here's a new version that I think incorporates a
Paul Eggert wrote:
> On 05/09/2012 03:14 AM, Jim Meyering wrote:
>> I think Pádraig's question about dd's skip seeking to EOF on an
>> actual tape device is the most important to address.
>
> Yes indeed, I think that part of my change should be backed out
> a
Stefano Lattarini wrote:
> Hi Jim, thanks for the feedback.
> On 05/08/2012 09:57 PM, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>>>
>>> So, OK to apply this patch to a new branch in the coreutils official
>>> repository? Or it's better if I clo
Pádraig Brady wrote:
...
>>>From 0b816e06d0b3d0cc9b7d2f92b095145bfe7c5476 Mon Sep 17 00:00:00 2001
>> From: Paul Eggert
>> Date: Wed, 9 May 2012 12:07:57 +0200
>> Subject: [PATCH] stat: don't report negative file size as huge positive
>> number
>>
>> * src/stat.c (print_stat): Use out_int, not ou
Paul Eggert wrote:
> On 05/08/2012 01:39 AM, Jim Meyering wrote:
>> I went ahead and pushed the less-invasive fix.
>
> Hmm, I don't see this on Savannah; is this part
> of the problem where usable_st_size got pushed?
>
>> Your behavior-changing one is more than we
Stefano Lattarini wrote:
> On 04/21/2012 11:48 AM, Stefano Lattarini wrote:
>> * configure.ac (AM_INIT_AUTOMAKE): Add the 'ng' option, to ensure that
>> mainstream Automake is not used by mistake when bootstrapping. Also,
>> bump the required Automake version from '1.11.1' to '1.11e', which is
>>
Jeff Janes wrote:
> Section 5 of the "INSTALL" file for coreutils says that "make
> installcheck" will repeat the self-checks, but using the binaries in
> their final installed locations.
>
> I cannot figure out what "make installcheck" is doing, but surely it
> is not doing that. It doesn't seem
Paul Eggert wrote:
> On 05/08/2012 01:39 AM, Jim Meyering wrote:
>> I went ahead and pushed the less-invasive fix.
>
> Hmm, I don't see this on Savannah; is this part
> of the problem where usable_st_size got pushed?
Ahh... I think I know what happened.
I had both the u
Jim Meyering wrote:
> A. Bram Neijt wrote:
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7813
...
> Thanks for the report.
> This was fixed for 8.6:
>
> commit 61b77891c2d9af299063850a0c4d1d721340cfff
> Author: Pádraig Brady
> Date: Tue Oct 12 01:39:58 2010 +0100
&g
Pádraig Brady wrote:
> On 05/08/2012 10:02 AM, Jim Meyering wrote:
>> diff --git a/tests/init.sh b/tests/init.sh
>> index ae86714..d5cd294 100644
>> --- a/tests/init.sh
>> +++ b/tests/init.sh
>> @@ -207,6 +207,9 @@ else
>>fi
>> fi
>>
>&
Jim Meyering wrote:
>> Paul Eggert wrote:
...
> I went ahead and pushed the less-invasive fix.
> Your behavior-changing one is more than welcome, too.
Samuel confirmed that the fix solved his problem, so
I've marked this as closed.
Philipp Thomas wrote:
> I copy a file from one NFS export to another NFS export and execute
> it in the new location, I get a "'Stale NFS file handle' error at the second
> line "cp submit.sh $submit_sh":
Thanks. I'm marking this as closed,
since the fix for http://bugs.gnu.org/11100
should addre
Jim Meyering wrote:
> Tim Mooney wrote:
...
> I think your suggestion below will solve your remaining
> "make check" failures.
>
>> If you have any interest in it, I would consider supply a patch against
>> the tests that checks to see if the invoking shell is b
e test.
Thanks for the suggestion.
The file that needed the change comes from gnulib
and is about to be synced from there to coreutils.
>From e1bf1f165f3ad45f2e706aa8d147e2ddf2252b8d Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 8 May 2012 10:55:21 +0200
Subject: [PATCH] init.sh: d
Jim Meyering wrote:
> Paul Eggert wrote:
>> On 05/07/2012 12:46 AM, Jim Meyering wrote:
>>> +
>>> + /* stat.st_size is valid only for regular files. For others, use 0. */
>>> + file_size = S_ISREG (stat_buf.st_mode) ? stat_buf.st_size : 0;
>>
>
Karl Berry wrote:
> Create dangling symlink:
> $ ln -s foo bar
>
> Attempt to write over it with cp:
> $ \cp -i /etc/issue bar
> cp: not writing through dangling symlink 'bar'
>
> In the past, it would ask me if I wanted to replace bar. (As desired.)
Hi Karl,
When I try that in an empty director
Philipp Thomas wrote:
> * Jim Meyering (j...@meyering.net) [20120504 17:30]:
>
>> If there's a bugzilla reference for this, let me know
>> and I'll add it to the commit log.
>
> There is, but as it's a SLES bug it's only open for SUSE employees and
Paul Eggert wrote:
> On 05/07/2012 12:46 AM, Jim Meyering wrote:
>> +
>> + /* stat.st_size is valid only for regular files. For others, use 0. */
>> + file_size = S_ISREG (stat_buf.st_mode) ? stat_buf.st_size : 0;
>
> Is it right to use 0 there, for non-regula
that split was using stat.st_size from non-regular
files: that is not defined.
Here is a patch:
>From 0a63df4b669faf0585beab09f4b177c39d557b21 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Mon, 7 May 2012 09:32:00 +0200
Subject: [PATCH] split: avoid apparent infloop when splitting /dev/zero w/
Pádraig Brady wrote:
> I can't think of any issue with this.
> Code looks good.
> Test triggers the new condition.
Thanks for the review.
I've squashed the test-adding commit onto the fix, added this sentence
to NEWS:
With NFS attribute caching, the condition
was particularly easy to tr
Jim Meyering wrote:
> Philipp Thomas wrote:
>> * Jim Meyering (j...@meyering.net) [20120328 18:09]:
>>
>>> At first glance, that might be reasonable: the additional open
>>> is incurred only after a failed stat.
>>> I'll look more closely in a week
Eric Blake wrote:
> On 05/04/2012 08:47 AM, Jim Meyering wrote:
>>
>> * src/copy.c (copy_reg): In a narrow race (stat sees dest, yet
>> open-without-O_CREAT fails with ENOENT), retry the open with O_CREAT.
>> Reported by Philipp Thomas and Neil F. Brown in
>
Eric Blake wrote:
> On 05/04/2012 08:47 AM, Jim Meyering wrote:
>>
>> * src/copy.c (copy_reg): In a narrow race (stat sees dest, yet
>> open-without-O_CREAT fails with ENOENT), retry the open with O_CREAT.
>> Reported by Philipp Thomas and Neil F. Brown in
>
Philipp Thomas wrote:
> * Jim Meyering (j...@meyering.net) [20120328 18:09]:
>
>> At first glance, that might be reasonable: the additional open
>> is incurred only after a failed stat.
>> I'll look more closely in a week or two if no one else investigates.
>
>
Jim Meyering wrote:
...
> I tried to use the su from coreutils (with or without your patch)
> and found that it does not work when it attempts to authenticate.
> E.g., it cannot su to any user on this Fedora 17 system.
I've just realized my (silly!) error.
For su to do its job, it m
Rocky Bernstein wrote:
> On Fri, May 4, 2012 at 4:49 AM, Jim Meyering wrote:
>
> Rocky Bernstein wrote:
> > Any word on this?
>
> Hi Rocky,
>
> Sorry about the extended delay.
> Changing su.c like this has really low priority.
>
> I
Rocky Bernstein wrote:
> Any word on this?
Hi Rocky,
Sorry about the extended delay.
Changing su.c like this has really low priority.
I've looked at your patch and see that it changes the semantics
of su for those who use -l with (-m or -p).
Before your patch, -l would lead to simulate_login be
Jim Meyering wrote:
> Jim Meyering wrote:
>
>> Marc W. Mengel wrote:
>>> The other test case is to make a copy of "id" and make it
>>> setuid to some user (i.e. mysql) and run it; it will show
>>> itself as having mysql's primary group,
Marc W. Mengel wrote:
> The other test case is to make a copy of "id" and make it
> setuid to some user (i.e. mysql) and run it; it will show
> itself as having mysql's primary group, even though it doesn't.
Oh! Yes, that will work. Thanks.
With that, I'll add a test like this:
New:
$ sudo
Pádraig Brady wrote:
> looks good
Thanks for the quick review.
Jim Meyering wrote:
> Marc W. Mengel wrote:
>> This is still broken in RedHat in coreutils-8.4-13
>>
>> All of "groups" and "id" and "id -G" report groups that you don't have
>> if you list a new/different primary group in /etc/pas
Marc W. Mengel wrote:
> This is still broken in RedHat in coreutils-8.4-13
>
> All of "groups" and "id" and "id -G" report groups that you don't have
> if you list a new/different primary group in /etc/passwd.
>
> This is just plain wrong. "id" and "groups" should list the groups you
> actually h
tags 11305 notabug
thanks
Vincent Ramos wrote:
> I use df on a daily basis under Ubuntu 11.10 (GNU/Linux
> 3.0.0-19-generic-pae i686). My df version is df (GNU coreutils) 8.5.
>
> When I use it in a French locale, the table header is badly aligned whereas
> with the English one, the alignment is c
g@free.fr wrote:
> - Mail original -
>> De: "Matt Burgess"
>> À: 11...@debbugs.gnu.org
>> Cc: bug-gnu...@gnu.org, matt...@linuxfromscratch.org
>> Envoyé: Lundi 2 Avril 2012 00:34:51
>> Objet: bug#11150: getlogin test failure
>>
>> Hi,
>>
>> The coreutils-8.16 release brought in the ge
301 - 400 of 5263 matches
Mail list logo
