bug#48355: Reporting bugs

[Pádraig Brady]

tag 48355 notabug
close 48355
stop

On 11/05/2021 16:46, tom wrote:

Hello,

I have found some bugs within the coreutil-tools: md5sum, sha1sum,
sha256, sha512 and b2sum. Have a look at the attached script and
messages.txt files.


I think you're passing a malformed checksum file.
We don't currently support mixed checksum algorithms per check file cleanly.
I had a look at https://gparted.org/gparted-live/stable/CHECKSUMS.TXT
which correlates with your output and is expected.
Specifically the FAILs are coming from sha512sum as
it recognizes the b2sum entry also as it has the same digest length.
The 4 FAILs coming from b2sum arise as that algorithm supports various lengths,
and thus tries to match against all entries in the file.

cheers,
Pádraig

bug#48355: Reporting bugs

[tom]

Hello,

I have found some bugs within the coreutil-tools: md5sum, sha1sum,
sha256, sha512 and b2sum. Have a look at the attached script and
messages.txt files.

With regards

Thomas




chksum-iso.sh
Description: application/shellscript
GNU bash, Version 5.0.3(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder jünger <http://gnu.org/licenses/gpl.html>

Dies ist freie Software.  Sie darf verändert und verteilt werden.
Es wird keine Garantie gewährt, soweit das Gesetz es zulässt.
10.9

gparted-live-1.3.0-1-amd64.iso: OK
md5sum: WARNUNG: 29 Zeilen sind nicht korrekt formatiert
gparted-live-1.3.0-1-amd64.iso: OK
sha1sum: WARNUNG: 29 Zeilen sind nicht korrekt formatiert
gparted-live-1.3.0-1-amd64.iso: OK
sha256sum: WARNUNG: 29 Zeilen sind nicht korrekt formatiert
gparted-live-1.3.0-1-amd64.iso: OK
gparted-live-1.3.0-1-amd64.iso: FEHLSCHLAG
sha512sum: WARNUNG: 23 Zeilen sind nicht korrekt formatiert
sha512sum: WARNUNG: die 1 berechnete Prüfsumme passte NICHT
gparted-live-1.3.0-1-amd64.iso: FEHLSCHLAG
gparted-live-1.3.0-1-amd64.iso: FEHLSCHLAG
gparted-live-1.3.0-1-amd64.iso: FEHLSCHLAG
gparted-live-1.3.0-1-amd64.iso: FEHLSCHLAG
gparted-live-1.3.0-1-amd64.iso: OK
b2sum: WARNUNG: 5 Zeilen sind nicht korrekt formatiert
b2sum: WARNUNG: 4 berechnete Prüfsummen passten NICHT

bug#44635: bugs in watch

[Bernhard Voelker]

tag 44635 notabug
close 44635
stop

On 11/14/20 2:07 PM, John Lawrence Aspden wrote:
> Hi Guys,
> 
> I noticed a couple of things that look like bugs in 'watch' [...]

You have reached the GNU coreutils mailing list, and 'watch' is not part
of the coreutils [1].

[1] https://www.gnu.org/software/coreutils/

Instead, 'watch' is part of the 'procps' package (at least least on my system),
so you're better off asking on their mailing list, bug tracker, or whatever
they are using [2][3].

[2] https://gitlab.com/procps-ng/procps
[3] https://gitlab.com/procps-ng/procps/blob/master/Documentation/bugs.md

I'm therefore marking this as "not a bug" + "closed" in our bug tracker.

Have a nice day,
Berny

bug#44635: bugs in watch

[John Lawrence Aspden]

Hi Guys,

I noticed a couple of things that look like bugs in 'watch' in
questions on unix.stackexchange.com (one of them is my own question).

https://unix.stackexchange.com/questions/101041/does-watch-only-monitor-the-visible-output

https://unix.stackexchange.com/questions/619461/why-does-watch-handle-programs-differently-depending-on-their-output

Both bugs are easy to provoke on my current stable debian.

john@dell-3537$ watch --version
watch from procps-ng 3.3.15

I john@dell-3537$ cat /etc/debian_version
10.6

I wondered if you guys already knew about them? If not, and if the
stackexchange questions aren't clear enough, can you point me to where
and how I should make formal bug reports?

John.

bug#10900: Clarification re: Regarding the observed bugs in cp

[Assaf Gordon]

tags 10900 moreinfo
close 10900
stop

(triaging old bugs)


On 30/08/12 10:39 PM, era eriksson wrote:


From: subratkumar 
To: era eriksson 
Date: Thu, 30 Aug 2012 17:04

On Thursday 30 August 2012 01:38 PM, era eriksson wrote:

I stumbled across your recent bug report for cp
[1]http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10900
and I was wondering if you could follow up with a bit of additional
information.  What did you expect to happen, and what should be fixed in
order for cp to behave like you expect?


With no further follow-ups in 6 years, I'm closing this bug.
Discussion can continue by replying to this thread.

regards,
 - assaf

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

[Declercq Laurent]

Le 25/02/2018 à 03:24, Pádraig Brady a écrit :

On 20/02/18 00:04, Declercq Laurent wrote:

Le 20/02/2018 à 04:26, Pádraig Brady a écrit :

2. Non-permission bits are preserved, even when the --no-preserve=mode
option is involved.

Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile
spfile_copy

Current result:

prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy

I'm not seeing this. I get 'x' rather than 's' here (and '-' with the fix)


Expected result (considering UMASK 0022 and without the first bug above):

prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy

thanks!
Pádraig


I'll make a new try, providing you relevant STRACE(1) output if necessary.

Thank you for your fast reaction.


I've pushed this fix.

Whether setuid is cleared may be file system dependent.
set_acl() corresponds to a setxattr() here,
and that was enough to clear the setuid perm on various
file systems here at least.

We can expand on this in future if needed,
which would be better as a separate patch anyway.

cheers,
Pádraig.
That is exactly what a strace showed me: setxattr() doesn't remove 
non-permission bits while with the explicit no-preserve=mode option, we 
could expect them to goes away.


From my point of view, there should be a new option, allowing us to 
explicitely discard ACL too, eg: no-preserve=mode,acl and then, enforce 
usage of chmod in such a case instead of relying on setxattr(). That is 
just an idea through, that  would make us able to not break old behavior 
for those relying on it.


Yes, that is system dependent. Should I create another issue for that issue?

Anyway, thank for your involvement here. That is much appreciated.

--

Laurent Declercq
iHMS/i-MSCP CEO & Lead Developer



This message and any attachment are intended solely for the addressees 
and are
confidential. iHMS/i-MSCP, including any part representing these 
entities may
not be held responsible for their contents whose accuracy and 
completeness cannot
be guaranteed over the Internet. Unauthorized use, disclosure, 
distribution, copying,
or any part thereof is strictly prohibited. If you are not the intended 
recipient of

this message, please notify the sender immediately and delete it.


<>

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

[Pádraig Brady]

On 20/02/18 00:04, Declercq Laurent wrote:
> Le 20/02/2018 à 04:26, Pádraig Brady a écrit :
>>> 2. Non-permission bits are preserved, even when the --no-preserve=mode
>>> option is involved.
>>>
>>> Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
>>> cp(1) command (run as root user): cp -r --no-preserve=mode spfile
>>> spfile_copy
>>>
>>> Current result:
>>>
>>> prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy
>> I'm not seeing this. I get 'x' rather than 's' here (and '-' with the fix)
>>
>>> Expected result (considering UMASK 0022 and without the first bug above):
>>>
>>> prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy
>> thanks!
>> Pádraig
>>
> 
> I'll make a new try, providing you relevant STRACE(1) output if necessary.
> 
> Thank you for your fast reaction.
> 

I've pushed this fix.

Whether setuid is cleared may be file system dependent.
set_acl() corresponds to a setxattr() here,
and that was enough to clear the setuid perm on various
file systems here at least.

We can expand on this in future if needed,
which would be better as a separate patch anyway.

cheers,
Pádraig.

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

[Declercq Laurent]

Le 20/02/2018 à 04:26, Pádraig Brady a écrit :

2. Non-permission bits are preserved, even when the --no-preserve=mode
option is involved.

Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile
spfile_copy

Current result:

prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy

I'm not seeing this. I get 'x' rather than 's' here (and '-' with the fix)


Expected result (considering UMASK 0022 and without the first bug above):

prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy

thanks!
Pádraig



I'll make a new try, providing you relevant STRACE(1) output if necessary.

Thank you for your fast reaction.

<>

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

[Pádraig Brady]

On 19/02/18 02:22, Declercq Laurent wrote:
> I think that I did found at least two bugs in cp(1) command when the 
> --no-preserve=mode option is involved and when copying special file. I 
> describe each of them below.
> 
> 1. Mode set on special files seem to be wrong:
> 
> Original file to copy: prw-rw-rw- 1 root staff 0 févr. 18 18:59 spfile
> cp(1) command (run as root user): cp -r --no-preserve=mode spfile 
> spfile_copy
> 
> Current result:
> 
> prwxr-xr-x 1 root staff 0 févr. 18 22:01 spfile_copy
> 
> Expected result (considering UMASK 0022):
> 
> prw-r--r-- 1 root staff 0 févr. 18 22:01 spfile_copy
> 
> The current behavior is due to the fact that mode used is 0777 while 
> 0666 should be used for files.
> 
> Possible fix: Differentiate directories from files in the copy_internal 
> function.

Thanks for the clear details.
The attached should fix this up.

> 2. Non-permission bits are preserved, even when the --no-preserve=mode 
> option is involved.
> 
> Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
> cp(1) command (run as root user): cp -r --no-preserve=mode spfile 
> spfile_copy
> 
> Current result:
> 
> prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy

I'm not seeing this. I get 'x' rather than 's' here (and '-' with the fix)

> Expected result (considering UMASK 0022 and without the first bug above):
> 
> prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy

thanks!
Pádraig

From 71e05111fa9dd6a4ad29630752d95289cb6d0274 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <p...@draigbrady.com>
Date: Mon, 19 Feb 2018 19:10:14 -0800
Subject: [PATCH] cp: set appropriate default permissions for special files

This issue was introduced in commit v8.19-145-g24ebca6

* src/copy.c (copy_internal): When setting default permissions
to use with --no-preserve=mode, only set executable bits for
directories or sockets.
* NEWS: Mention the fix.
* tests/cp/preserve-mode.sh: Add a test case.
Fixes https://bugs.gnu.org/30534
---
 NEWS  |  5 +
 src/copy.c|  6 --
 tests/cp/preserve-mode.sh | 10 +-
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index 8a9e09e..5fa6928 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,11 @@ GNU coreutils NEWS-*- outline -*-
   that caused -u to sometimes override -n.
   [bug introduced with coreutils-7.1]
 
+  'cp -a --no-preserve=mode' now sets appropriate default permissions
+  for non regular files like fifos and character device nodes etc.
+  Previously it would have set executable bits on created special files.
+  [bug introduced with coreutils-8.20]
+
 
 * Noteworthy changes in release 8.29 (2017-12-27) [stable]
 
diff --git a/src/copy.c b/src/copy.c
index e050d41..233b498 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1378,7 +1378,7 @@ preserve_metadata:
 }
   else if (x->explicit_no_preserve_mode)
 {
-  if (set_acl (dst_name, dest_desc, 0666 & ~cached_umask ()) != 0)
+  if (set_acl (dst_name, dest_desc, MODE_RW_UGO & ~cached_umask ()) != 0)
 return_val = false;
 }
   else if (omitted_permissions)
@@ -2860,7 +2860,9 @@ copy_internal (char const *src_name, char const *dst_name,
 }
   else if (x->explicit_no_preserve_mode)
 {
-  if (set_acl (dst_name, -1, 0777 & ~cached_umask ()) != 0)
+  int default_permissions = S_ISDIR (src_mode) || S_ISSOCK (src_mode)
+? S_IRWXUGO : MODE_RW_UGO;
+  if (set_acl (dst_name, -1, default_permissions & ~cached_umask ()) != 0)
 return false;
 }
   else
diff --git a/tests/cp/preserve-mode.sh b/tests/cp/preserve-mode.sh
index 1cd173a..3b0aca8 100755
--- a/tests/cp/preserve-mode.sh
+++ b/tests/cp/preserve-mode.sh
@@ -19,7 +19,7 @@
 . "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
 print_ver_ cp
 
-get_mode() { ls -ld "$1" | cut -b-10; }
+get_mode() { stat -c%f "$1"; }
 
 rm -f a b c
 umask 0022
@@ -47,4 +47,12 @@ chmod 600 a
 cp --no-preserve=mode --preserve=all a b || fail=1
 test "$(get_mode a)" = "$(get_mode b)" || fail=1
 
+#fifo test
+if mkfifo fifo; then
+  cp -a --no-preserve=mode fifo fifo_copy || fail=1
+  #ensure default perms set appropriate for non regular files
+  #which wasn't done between v8.20 and 8.29 inclusive
+  test "$(get_mode fifo)" = "$(get_mode fifo_copy)" || fail=1
+fi
+
 Exit $fail
-- 
2.9.3

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

[Declercq Laurent]

I think that I did found at least two bugs in cp(1) command when the 
--no-preserve=mode option is involved and when copying special file. I 
describe each of them below.


1. Mode set on special files seem to be wrong:

Original file to copy: prw-rw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile 
spfile_copy


Current result:

prwxr-xr-x 1 root staff 0 févr. 18 22:01 spfile_copy

Expected result (considering UMASK 0022):

prw-r--r-- 1 root staff 0 févr. 18 22:01 spfile_copy

The current behavior is due to the fact that mode used is 0777 while 
0666 should be used for files.


Possible fix: Differentiate directories from files in the copy_internal 
function.


2. Non-permission bits are preserved, even when the --no-preserve=mode 
option is involved.


Original file to copy: prwSrw-rw- 1 root staff 0 févr. 18 18:59 spfile
cp(1) command (run as root user): cp -r --no-preserve=mode spfile 
spfile_copy


Current result:

prwsr-xr-x 1 root staff 0 févr. 18 22:05 spfile_copy

Expected result (considering UMASK 0022 and without the first bug above):

prw-r--r-- 1 root staff 0 févr. 18 22:05 spfile_copy

Possible solution: Clear-out non-permission bits before calling mknod() 
and similar


Environment:
Linux jessie64 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 
(2018-01-08) x86_64 GNU/Linux

Checked against latest coreutils version.

bug#25041: Bugs in TAC and TAIL for closed stdin

[Pádraig Brady]

On 27/11/16 15:51, Jim Meyering wrote:
> 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
> +  && follow_mode == Follow_name);
> 

Done.
Also we should probably clear any errors such as ENOSPC
from the stream before reuse for the next input:

diff --git a/src/tac.c b/src/tac.c
index 2e820fa..c1b6003 100644
--- a/src/tac.c
+++ b/src/tac.c
@@ -477,6 +477,7 @@ temp_stream (FILE **fp, char **file_name)
 }
   else
 {
+  clearerr (tmp_fp);
   if (fseeko (tmp_fp, 0, SEEK_SET) < 0
   || ftruncate (fileno (tmp_fp), 0) < 0)
 {

cheers,
Pádraig

bug#25041: Bugs in TAC and TAIL for closed stdin

[Jim Meyering]

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
+  && follow_mode == Follow_name);

bug#25041: Bugs in TAC and TAIL for closed stdin

[Pádraig Brady]

I'll push the attached later

thanks again,
Pádraiag
>From a31edf2aab384bfd33a6f0ab123d688939c4ddf6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Sun, 27 Nov 2016 13:00:35 +
Subject: [PATCH 1/2] tail: fix uninitialized memory read when failing to read
 file
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Reproduced under UBSAN with `tail -f <&-` giving:
  tail.c:2220:18: runtime error: load of value 190,
  which is not a valid value for type ‘_Bool'

* src/tail.c (tail_file): Ensure f->ignore is initialized
in all cases where we can't tail the specified file.
* tests/tail-2/follow-stdin.sh: Add a test case which
checks stderr has no UBSAN warnings.
Fixes http://bugs.gnu.org/25041
---
 src/tail.c   |  4 ++--
 tests/tail-2/follow-stdin.sh | 12 
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/tail.c b/src/tail.c
index 5c75be0..3d83550 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1940,8 +1940,6 @@ tail_file (struct File_spec *f, uintmax_t n_units)
   ok = false;
   f->errnum = -1;
   f->tailable = false;
-  f->ignore = ! (reopen_inaccessible_files
- && follow_mode == Follow_name);
   error (0, 0, _("%s: cannot follow end of this type of file%s"),
  quotef (pretty_name (f)),
  f->ignore ? _("; giving up on this name") : "");
@@ -1949,6 +1947,8 @@ tail_file (struct File_spec *f, uintmax_t n_units)
 
   if (!ok)
 {
+  f->ignore = ! (reopen_inaccessible_files
+  && follow_mode == Follow_name);
   close_fd (fd, pretty_name (f));
   f->fd = -1;
 }
diff --git a/tests/tail-2/follow-stdin.sh b/tests/tail-2/follow-stdin.sh
index a2f1804..3d51f60 100755
--- a/tests/tail-2/follow-stdin.sh
+++ b/tests/tail-2/follow-stdin.sh
@@ -50,4 +50,16 @@ for mode in '' '---disable-inotify'; do
   cleanup_
 done
 
+
+# Before coreutils-8.26 this would induce an UMR under UBSAN
+returns_ 1 timeout 10 tail -f - <&- 2>err || fail=1
+cat <<\EOF >exp || framework_failure_
+tail: cannot fstat 'standard input': Bad file descriptor
+tail: error reading 'standard input': Bad file descriptor
+tail: no files remaining
+tail: -: Bad file descriptor
+EOF
+compare exp err || fail=1
+
+
 Exit $fail
-- 
2.5.5


>From 8fc0d1d68b37f67adad8ecc08b3875425130fcb5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Sun, 27 Nov 2016 15:09:53 +
Subject: [PATCH 2/2] tac: fix mem corruption when failing to read non seekable
 inputs

This was detected with ASAN, but can also be seen without ASAN with:
  $ tac - - <&-
  tac: standard input: read error: Bad file descriptor
  *** Error in `tac': malloc(): memory corruption: 0x...

* src/tac.c (copy_to_temp): Don't close our output stream on error;
including input errors.
* tests/misc/tac-2-nonseekable.sh: Add a test case.
Fixes http://bugs.gnu.org/25041
---
 src/tac.c   | 10 +++---
 tests/misc/tac-2-nonseekable.sh |  3 +++
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/tac.c b/src/tac.c
index 2e820fa..e9363b1 100644
--- a/src/tac.c
+++ b/src/tac.c
@@ -512,13 +512,13 @@ copy_to_temp (FILE **g_tmp, char **g_tempfile, int input_fd, char const *file)
   if (bytes_read == SAFE_READ_ERROR)
 {
   error (0, errno, _("%s: read error"), quotef (file));
-  goto Fail;
+  return -1;
 }
 
   if (fwrite (G_buffer, 1, bytes_read, fp) != bytes_read)
 {
   error (0, errno, _("%s: write error"), quotef (file_name));
-  goto Fail;
+  return -1;
 }
 
   /* Implicitly <= OFF_T_MAX due to preceding fwrite(),
@@ -530,16 +530,12 @@ copy_to_temp (FILE **g_tmp, char **g_tempfile, int input_fd, char const *file)
   if (fflush (fp) != 0)
 {
   error (0, errno, _("%s: write error"), quotef (file_name));
-  goto Fail;
+  return -1;
 }
 
   *g_tmp = fp;
   *g_tempfile = file_name;
   return bytes_copied;
-
- Fail:
-  fclose (fp);
-  return -1;
 }
 
 /* Copy INPUT_FD to a temporary, then tac that file.
diff --git a/tests/misc/tac-2-nonseekable.sh b/tests/misc/tac-2-nonseekable.sh
index 47e7849..08b35b3 100755
--- a/tests/misc/tac-2-nonseekable.sh
+++ b/tests/misc/tac-2-nonseekable.sh
@@ -36,4 +36,7 @@ for file in /proc/version /sys/kernel/profiling; do
   fi
 done
 
+# This failed due to heap corruption before coreutils 8.26
+returns_ 1 tac - - <&- 2>err || fail=1
+
 Exit $fail
-- 
2.5.5

bug#25041: Bugs in TAC and TAIL for closed stdin

[Pádraig Brady]

On 27/11/16 09:15, Marcel Böhme wrote:
> Dear all,
> 
> During fuzzing, we found one use-after-free in tac and one 
> invalid-loading-of-value in tail.
> Interestingly, these errors can be observed only when stdin is externally 
> closed but internally expected to be open.
> 
> The bugs were found by AFLFast, a fork of AFL. 
> The bug in tac was also found by Klee.
> Thanks again also to Van-Thuan Pham.
> 
> The following execution crashes TAC in trunk. For the same execution of 
> preinstalled version 8.21 on Ubuntu x86_64, valgrind flags a few invalid 
> reads of size 8. There is no problem in version 6.10:
> 
> $ ./tac - - <&-
> ./tac: 'standard input': read error: Bad file descriptor
> =
> ==53813==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6160f990 at pc 0x0040e127 bp 0x7ffefd0f76e0 sp 0x7ffefd0f76d8
> READ of size 8 at 0x6160f990 thread T0
> #0 0x40e126 in rpl_fseeko ../lib/fseeko.c:51
> #1 0x4032ac in temp_stream ../src/tac.c:480
> #2 0x4032ac in copy_to_temp ../src/tac.c:504
> #3 0x4032ac in tac_nonseekable ../src/tac.c:553
> #4 0x4032ac in tac_file ../src/tac.c:595
> #5 0x4032ac in main ../src/tac.c:701
> #6 0x7f135e464f44 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
> #7 0x404779  (/home/ubuntu/subjects/coreutils/obj-gcov/src/tac+0x404779)
> 
> 0x6160f990 is located 16 bytes inside of 568-byte region 
> [0x6160f980,0x6160fbb8)
> freed by thread T0 here:
> #0 0x7f135f5e1090 in __interceptor_free 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2090)
> #1 0x7f135e4b0a24 in _IO_fclose (/lib/x86_64-linux-gnu/libc.so.6+0x6da24)
> 
> previously allocated by thread T0 here:
> #0 0x7f135f5e13a8 in __interceptor_malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
> #1 0x7f135e4b0c81 in fdopen (/lib/x86_64-linux-gnu/libc.so.6+0x6dc81)
> 
> SUMMARY: AddressSanitizer: heap-use-after-free ../lib/fseeko.c:51 in 
> rpl_fseeko
> =

Oh right, we're operating on a closed stream here.
I'll fix that up.

> The following execution of TAIL in trunk is flagged by UBSAN.
> $ tail -f <&-
> tail.c:2220:18: runtime error: load of value 190, which is not a valid value 
> for type ‘_Bool'

Right we need to init f->ignore in more cases.
I confirmed this no longer triggers the issue:

diff --git a/src/tail.c b/src/tail.c
index 5c75be0..3d83550 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1940,8 +1940,6 @@ tail_file (struct File_spec *f, uintmax_t n_units)
   ok = false;
   f->errnum = -1;
   f->tailable = false;
-  f->ignore = ! (reopen_inaccessible_files
- && follow_mode == Follow_name);
   error (0, 0, _("%s: cannot follow end of this type of file%s"),
  quotef (pretty_name (f)),
  f->ignore ? _("; giving up on this name") : "");
@@ -1949,6 +1947,8 @@ tail_file (struct File_spec *f, uintmax_t n_units)

   if (!ok)
 {
+  f->ignore = ! (reopen_inaccessible_files
+  && follow_mode == Follow_name);
   close_fd (fd, pretty_name (f));
   f->fd = -1;
 }

thanks!
Pádraig

bug#25041: Bugs in TAC and TAIL for closed stdin

[Marcel Böhme]

Dear all,

During fuzzing, we found one use-after-free in tac and one 
invalid-loading-of-value in tail.
Interestingly, these errors can be observed only when stdin is externally 
closed but internally expected to be open.

The bugs were found by AFLFast, a fork of AFL. 
The bug in tac was also found by Klee.
Thanks again also to Van-Thuan Pham.

The following execution crashes TAC in trunk. For the same execution of 
preinstalled version 8.21 on Ubuntu x86_64, valgrind flags a few invalid reads 
of size 8. There is no problem in version 6.10:

$ ./tac - - <&-
./tac: 'standard input': read error: Bad file descriptor
=
==53813==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160f990 
at pc 0x0040e127 bp 0x7ffefd0f76e0 sp 0x7ffefd0f76d8
READ of size 8 at 0x6160f990 thread T0
#0 0x40e126 in rpl_fseeko ../lib/fseeko.c:51
#1 0x4032ac in temp_stream ../src/tac.c:480
#2 0x4032ac in copy_to_temp ../src/tac.c:504
#3 0x4032ac in tac_nonseekable ../src/tac.c:553
#4 0x4032ac in tac_file ../src/tac.c:595
#5 0x4032ac in main ../src/tac.c:701
#6 0x7f135e464f44 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#7 0x404779  (/home/ubuntu/subjects/coreutils/obj-gcov/src/tac+0x404779)

0x6160f990 is located 16 bytes inside of 568-byte region 
[0x6160f980,0x6160fbb8)
freed by thread T0 here:
#0 0x7f135f5e1090 in __interceptor_free 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2090)
#1 0x7f135e4b0a24 in _IO_fclose (/lib/x86_64-linux-gnu/libc.so.6+0x6da24)

previously allocated by thread T0 here:
#0 0x7f135f5e13a8 in __interceptor_malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
#1 0x7f135e4b0c81 in fdopen (/lib/x86_64-linux-gnu/libc.so.6+0x6dc81)

SUMMARY: AddressSanitizer: heap-use-after-free ../lib/fseeko.c:51 in rpl_fseeko
=


The following execution of TAIL in trunk is flagged by UBSAN.
$ tail -f <&-
tail.c:2220:18: runtime error: load of value 190, which is not a valid value 
for type ‘_Bool'

For trunk version, version 8.21, and version 6.10 on Ubuntu x86_64, valgrind 
reports:
==28236== Conditional jump or move depends on uninitialised value(s)
==28236==at 0x405941: ignore_fifo_and_pipe (tail.c:2220)
==28236==by 0x405941: main (tail.c:2334)

Best regards,
- Marcel

bug#25011: Bugs in PTX Utility

[Pádraig Brady]

On 24/11/16 08:57, Marcel Böhme wrote:
> Dear all,
> 
> The following produces a crash for the version in trunk and preinstalled 
> version 8.21 on Ubuntu 14.04 x86_64.
> Below is also heap-buffer-overflow that doesn’t actually crash but is flagged 
> by ASAN as an invalid read of size 1.
> 
> Both bugs were found by AFLFast, a fork of AFL. Thanks goes out to Van-Thuan 
> Pham.
> 
> 
> $ ptx ptx ptx > /dev/null
> Segmentation fault
> 
> ASAN says:
> ==47034==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x7f2b49433093 at pc 0x00407b8b bp 0x7ffcfc738bb0 sp 0x7ffcfc738ba8
> READ of size 1 at 0x7f2b49433093 thread T0
> #0 0x407b8a in define_all_fields ../src/ptx.c:1432
> #1 0x407b8a in generate_all_output ../src/ptx.c:1778
> #2 0x407b8a in main ../src/ptx.c:2153
> #3 0x7f2b4db9af44 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
> #4 0x409379  (/home/ubuntu/subjects/coreutils/obj-asan/src/ptx+0x409379)
> 
> 0x7f2b49433093 is located 10387 bytes inside of 8388576-byte region 
> [0x7f2b49430800,0x7f2b49c307e0)
> freed by thread T0 here:
> #0 0x7f2b4ed17710 in __interceptor_realloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2710)
> #1 0x414a75 in xrealloc ../lib/xmalloc.c:61
> 
> previously allocated by thread T0 here:
> #0 0x7f2b4ed17710 in __interceptor_realloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2710)
> #1 0x414a75 in xrealloc ../lib/xmalloc.c:61
> 
> SUMMARY: AddressSanitizer: heap-use-after-free ../src/ptx.c:1432 in 
> define_all_fields
> 
> 
> This is the other one:
> $ echo a > ~/a
> $ ptx -w1 -A ~/a
> =
> ==44013==ERROR: AddressSanitizer: heap-buffer-overflow on address 
> 0x6020e818 at pc 0x004085cd bp 0x7ffc327adb70 sp 0x7ffc327adb68
> READ of size 1 at 0x6020e818 thread T0
> #0 0x4085cc in define_all_fields ../src/ptx.c:1411
> #1 0x4085cc in generate_all_output ../src/ptx.c:1778
> #2 0x4085cc in main ../src/ptx.c:2153
> #3 0x7f9ef7044f44 in __libc_start_main 
> (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
> #4 0x409379  (/home/ubuntu/subjects/coreutils/obj-asan/src/ptx+0x409379)
> 
> 0x6020e818 is located 5 bytes to the right of 3-byte region 
> [0x6020e810,0x6020e813)
> allocated by thread T0 here:
> #0 0x7f9ef81c13a8 in __interceptor_malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
> #1 0x4121ed in fread_file ../lib/read-file.c:73
> 
> SUMMARY: AddressSanitizer: heap-buffer-overflow ../src/ptx.c:1411 in 
> define_all_fields

Right, line_width can go negative.
I'll clean up something like this and push.

thanks!

diff --git a/src/ptx.c b/src/ptx.c
index c3b60df..d189678 100644
--- a/src/ptx.c
+++ b/src/ptx.c
@@ -1235,6 +1235,8 @@ fix_output_parameters (void)

   if ((auto_reference || input_reference) && !right_reference)
 line_width -= reference_max_width + gap_size;
+  if (line_width < 0)
+line_width = 0;

   /* The output lines, minimally, will contain from left to right a left
  context, a gap, and a keyword followed by the right context with no

bug#25011: Bugs in PTX Utility

[Marcel Böhme]

Dear all,

The following produces a crash for the version in trunk and preinstalled 
version 8.21 on Ubuntu 14.04 x86_64.
Below is also heap-buffer-overflow that doesn’t actually crash but is flagged 
by ASAN as an invalid read of size 1.

Both bugs were found by AFLFast, a fork of AFL. Thanks goes out to Van-Thuan 
Pham.


$ ptx ptx ptx > /dev/null
Segmentation fault

ASAN says:
==47034==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f2b49433093 
at pc 0x00407b8b bp 0x7ffcfc738bb0 sp 0x7ffcfc738ba8
READ of size 1 at 0x7f2b49433093 thread T0
#0 0x407b8a in define_all_fields ../src/ptx.c:1432
#1 0x407b8a in generate_all_output ../src/ptx.c:1778
#2 0x407b8a in main ../src/ptx.c:2153
#3 0x7f2b4db9af44 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#4 0x409379  (/home/ubuntu/subjects/coreutils/obj-asan/src/ptx+0x409379)

0x7f2b49433093 is located 10387 bytes inside of 8388576-byte region 
[0x7f2b49430800,0x7f2b49c307e0)
freed by thread T0 here:
#0 0x7f2b4ed17710 in __interceptor_realloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2710)
#1 0x414a75 in xrealloc ../lib/xmalloc.c:61

previously allocated by thread T0 here:
#0 0x7f2b4ed17710 in __interceptor_realloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2710)
#1 0x414a75 in xrealloc ../lib/xmalloc.c:61

SUMMARY: AddressSanitizer: heap-use-after-free ../src/ptx.c:1432 in 
define_all_fields


This is the other one:
$ echo a > ~/a
$ ptx -w1 -A ~/a
=
==44013==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x6020e818 at pc 0x004085cd bp 0x7ffc327adb70 sp 0x7ffc327adb68
READ of size 1 at 0x6020e818 thread T0
#0 0x4085cc in define_all_fields ../src/ptx.c:1411
#1 0x4085cc in generate_all_output ../src/ptx.c:1778
#2 0x4085cc in main ../src/ptx.c:2153
#3 0x7f9ef7044f44 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#4 0x409379  (/home/ubuntu/subjects/coreutils/obj-asan/src/ptx+0x409379)

0x6020e818 is located 5 bytes to the right of 3-byte region 
[0x6020e810,0x6020e813)
allocated by thread T0 here:
#0 0x7f9ef81c13a8 in __interceptor_malloc 
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc23a8)
#1 0x4121ed in fread_file ../lib/read-file.c:73

SUMMARY: AddressSanitizer: heap-buffer-overflow ../src/ptx.c:1411 in 
define_all_fields

Best regards,
- Marcel

bug#24007: Report cat bugs to bug-coreutils@gnu.org

[Eric Blake]

tag 24007 notabug
thanks

On 07/16/2016 12:11 AM, NAVEEN KUMAR wrote:
> Hi Team,
> 
> Greetings!
> 
> I was sitting next my system looking for some basic code brush up and was
> playing with CAT command, and though of some kind of additional features to
> our existing CAT command, such as...
> 
> 
> 
> *"Write a CAT command program, which will allow appending text or lines of
> code at user specified line" not only at the end of file.*
> 
> *Ex: cat >> filename.c line_number *

That won't work.  The >> operator in the shell opens a file in
append-only mode, and the operating system enforces that in append mode,
data can only be added at the end, not the middle.

Furthermore, what you suggested can already be done with sed, so there
is no real reason to bloat cat to add non-standard functionality that
can already be done with a standard tool.

sed "$line r $file_to_insert" $file_to_expand

inserts the contents of $file_to_insert starting at line $line of the
file $file_to_expand, and pipes the resulting concatenation to stdout.

These days, it's a very high bar to justify adding new features, and we
prefer to save additions for things that either match other
implementations or that accomplish things more efficiently than what is
possible using only standard tools.  Therefore, I'm closing this feature
suggestion in the bug database as it is unlikely to be implemented, but
do feel free to add further comments on the thread.

Feature suggestions can be sent to coreut...@gnu.org, rather than the
bug list, if you are not sure whether it is worth pursuing, so that we
don't clog up the bug database.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#24007: Report cat bugs to bug-coreutils@gnu.org

[NAVEEN KUMAR]

Hi Team,

Greetings!

I was sitting next my system looking for some basic code brush up and was
playing with CAT command, and though of some kind of additional features to
our existing CAT command, such as...



*"Write a CAT command program, which will allow appending text or lines of
code at user specified line" not only at the end of file.*

*Ex: cat >> filename.c line_number *

Please suggest.

Thanks,
LoveToCode(DreamWalker)

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

[Assaf Gordon]

tag 23951 notabug
close 23951
stop

Hello,

quoting an off-list email from David:
> When I use "sort -k1.4n -u", system output miss [c3m1.ecld.com].
> then "sort -k1.4n aa |sort -u" the [c3m1.ecld.com] appear again.

This is not a bug but correct behavior.

The parameter "-k1.4n" means that the compared keys start at the digit (e.g. 
"1", "2") -
thus the compared key of both "c3a1" and "c3m1" is "1", and "-u" outputs only 
one of them.
using "sort -u" separately treats the entire line as the key, thus "c3a1" and 
"c3m1" are different.

The following will demonstrate:

  $ printf "aaa1\nbbb2\nccc1\n" | sort -k1.4n
  aaa1
  ccc1
  bbb2

  $ printf "aaa1\nbbb2\nccc1\n" | sort -k1.4n -u
  aaa1
  bbb2

  $ printf "aaa1\nbbb2\nccc1\n" | sort -k1.4n | sort -u
  aaa1
  bbb2
  ccc1

In the first two examples, the letters do not matter at all. Because the key is 
"-k1.4",
the first three characters are ignored, and the compared values are the digits 
1,2,1.
In the second example, asking for unique values refer to unique keys, meaning 
lines with key "1"
will be printed once (aaa1).

In the third example, the additional 'sort' negates the first 'sort', because 
it first sorts all lines alphabetically, then prints unique lines, while using 
the entire line as a key.

Recent versions of 'sort' support the '--debug' option, which helps 
troubleshooting such cases:
===
$ printf "aaa1\nbbb2\nccc1\n" | sort --debug -k1.4n 
sort: using ‘en_US.UTF-8’ sorting rules
sort: leading blanks are significant in key 1; consider also specifying 'b'
sort: key 1 is numeric and spans multiple fields
aaa1
   _

ccc1
   _

bbb2
   _


===

As such, I'm closing this bug, but discussion can continue by replying to this 
thread.

regards,
 - assaf

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

[Assaf Gordon]

Hello,

> On Jul 11, 2016, at 21:38, David Pan  wrote:
> 
> It seems that I find a bug when using the command:
> 
> sort -k1.4n -u
> please refer to the attachment for detail .

You have not indicated exactly what is the suspected incorrect output.
May I ask you to detail what is the output you expected vs the output you got? 
(i.e. in which command you think the bug is?) Also, in the subject line you've 
listed "-k1.4,1.6n", but I do not see such invocation in the attached file.

To help troubleshoot sort-related issues, recent versions of gnu sort support a 
new option "--debug" which prints additional information about the keys being 
compared.
It would be useful to attach the output of such command, for example:

==
$ sort --debug -k1.4n -u aa 
sort: using ‘en_US.UTF-8’ sorting rules
sort: leading blanks are significant in key 1; consider also specifying 'b'
sort: key 1 is numeric and spans multiple fields
c3a1.ecld.com
   __
c3m2.ecld.com
   __
c3s15.ecld.com
   ___
c3s16.ecld.com
   ___
c3s17.ecld.com
   ___
c3s18.ecld.com
   ___
c3s19.ecld.com
   ___
c3s20.ecld.com
   ___
c3s21.ecld.com
   ___
c3s25.ecld.com
   ___

==


regards,
 -assaf


P.S.
If you do test a newer version of coreutils, please be sure to use version 8.19 
or newer, as it contains a fix for a "sort -u" bug which was introduced in 8.6 
( 
http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=eb3f5b3b3de8c6ca005a701f09bff43d778aece7
 ).

bug#23951: sort -k1.4,1.6n -u HAVE BUGS!!!

[David Pan]

Hello Dear:




It seems that I find a bug when using the command:




sort -k1.4n -u




please refer to the attachment for detail .









sort-u.bug
Description: Binary data

bug#20729: true bugs

[Dan Burton]

According to `man true', the --help and --version flags should have output.
However, when I run `true --help' or `true --version', I get no output.
These are true bugs (pun intended), so as instructed by the man page, I
am reporting true bugs to bug-coreutils@gnu.org.

-- Dan Burton

bug#20729: true bugs

[Eric Blake]

tag 20729 notabug
thanks

On 06/03/2015 10:00 PM, Dan Burton wrote:
 According to `man true', the --help and --version flags should have output.
 However, when I run `true --help' or `true --version', I get no output.
 These are true bugs (pun intended), so as instructed by the man page, I
 am reporting true bugs to bug-coreutils@gnu.org.

Thanks for the report.  However, you did not read enough of 'man true';
a bit further down, you would see:

   NOTE: your shell may have its own version of true, which usually
super‐
   sedes the version described here.  Please refer to your  shell's
 docu‐
   mentation for details about the options it supports.

And sure enough, compare the difference:

$ type true
true is a shell builtin

or use 'env' to force the standalone version rather than the builtin:

$ env true --help
Usage: true [ignored command line arguments]
  or:  true OPTION
Exit with a status code indicating success.

  --help display this help and exit
  --version  output version information and exit

NOTE: your shell may have its own version of true, which usually supersedes
the version described here.  Please refer to your shell's documentation
for details about the options it supports.

GNU coreutils online help: http://www.gnu.org/software/coreutils/
For complete documentation, run: info coreutils 'true invocation'


As such, I'm closing this as not a bug, but feel free to add further
comments.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#18681: The Linux cp command has bugs

[Bob Proulx]

close 18681
thanks

Eric Blake wrote:
 Polehn, Mike A wrote:
  This still left the incorrect operation of the interactive
  operation when both -i and -f is used.
 
 The behavior of -i vs. -f interaction is required by POSIX; in
 particular, POSIX is explicit that -i and -f are NOT a toggle switch of
 one another, but each turns on slightly different, somewhat overlapping,
 changes in behavior (so specifying both is different from specifying one
 in isolation).  We can't change what either one of those flags means.

This bug log included some serious topic drift of which I contributed
to myself.  In order to atone for that I am going to triage this as
saying that the behavior is intended and standardized and therefore
won't be changed.  Now that we understand this the bug ticket can be
closed.  Further discussion can be continued and it will all be logged
and read by the subscribed.

 If there is another mode of operation that is also useful, then it needs
 yet another flag.  At one point in the past, we had
 --reply={yes,no,query} to try and offer a third mode, but it had
 confusing semantics and we ended up pulling it because of the confusion
 it could cause.  At the time we pulled it, we admitted that 'rsync' has
 some modes of operations that might be better suited for the particular
 modes that people people seemed to be requesting when they thought that
 --reply would do the trick (and usually, what they thought --reply would
 do and what it actually did were different, which is why we removed it
 to avoid confusion).  We have also added a --no-clobber option, which is
 somewhat of a compromise (what some people thought --reply=no would do,
 --no-clobber actually does better).

Good summary!

 So adding a new option is not out of the question, but you'd have to
 have well-defined semantics of what it should do, and how it differs
 from either normal mode, '-i' mode, '-f' mode, '-i -f' mode, or
 '--no-clobber' mode.

If the readers of this ticket think there is an enhancement request to
be filed for cp then please file a wishlist bug with the proposal.  A
reference to this log can be made if desired.  Let me suggest that the
proposal first be made on the coreutils discussion list where it can
be discussed and shaped and then after that has been done file a
wishlist bug of the result in order to track its progress through the
code and release.

Bob

bug#18681: The Linux cp command has bugs

[Polehn, Mike A]

cp --version:   8.21

running on Fedora 20, version 3.16.3-200.fc20.x86_64 with latest updates 

The Linux copy command (cp) has problems 

Problem need to copy a tree of 1000s of files to another directory that is a 
git directory that has a whole bunch of additional build files, so diff between 
the directories will not do any good.

If the files are copied over the git directory I can do what I need to do, 
since I need to see if there are in differences in any of the files.

Using: cp -f -r dir a dir b

For each file being copied it asked:

cp: overwrite X?

So the force command does not work, since it should skip the asking about doing 
an overwrite. If the force command is supposed act differently, then there 
should be an additional argument because answering yes 1000s of times is not 
very smart... 

Also since there are a lot of files, if I accidently hit return before y, cp 
moves on to the next file, which implies to me that the file was not copied, 
which gets to be a problem when 1000s of files are copied. I also assumed that 
'y' implies the data was copied.

bug#18681: The Linux cp command has bugs

[Paul Eggert]

Polehn, Mike A wrote:

Using: cp -f -r dir a dir b

For each file being copied it asked:

cp: overwrite X?


That's not what I observe here (see below).  Perhaps there's something else 
going on, maybe an alias.  For example, I couldn't get the cp to work without 
also using -T.  Can you please give an exact recipe for reproducing the problem 
on your platform?


$ mkdir a b
$ echo a a/f
$ echo b b/f
$ cp -f -r -T a b
$ cat b/f
a

bug#18681: The Linux cp command has bugs

[Assaf Gordon]

Hello Mike,

On 10/10/2014 01:25 PM, Polehn, Mike A wrote:

Problem need to copy a tree of 1000s of files to another directory
that is a git directory that has a whole bunch of additional build
files, so diff between the directories will not do any good.



This is slightly off-topic, but if you want to compare only files managed by 
git (ignoring other files in current directory), perhaps the following would 
help:

# Download and extract the tarball
wget -q http://dpdk.org/browse/dpdk/snapshot/dpdk-1.7.1.tar.gz
tar -xf dpdk-1.7.1.tar.gz

# Clone the git repo with specific branch, checkout the relevant branch
# (or go to an existing checked-out repository directory)
git clone git://dpdk.org/dpdk
cd dpdk
git checkout -b map_v1.7.1 v1.7.1

# For each file managed by git (with 'git ls'),
# compare it to the corresponding file in the other directory:
git ls -0 | xargs -0 -I% diff -q % ../dpdk-1.7.1/%


Regards,
 -gordon

bug#18681: The Linux cp command has bugs

[Assaf Gordon]

Sorry, had a typo:

On 10/10/2014 03:13 PM, Assaf Gordon wrote:

 # For each file managed by git (with 'git ls'),
 # compare it to the corresponding file in the other directory:
 git ls -0 | xargs -0 -I% diff -q % ../dpdk-1.7.1/%



Should be:
 git ls -z | xargs -0 -I% diff -q % ../dpdk-1.7.1/%

bug#18681: The Linux cp command has bugs

[Polehn, Mike A]

Hi Assaf!

Thank you for your quick response!

There is always multiple ways to do things. The git tool has a diff tool built 
in that makes file comparison easy.

I have run across multiple times that copying one tree over another is 
desirable.

In another bug message thread, we found that the cause was cp alias to 'cp -i' 
for root user was the actual cause.

This still left the incorrect operation of the interactive operation when both 
-i and -f is used.

I think that in some cases the need of override the '-i' with '-f' maybe very 
desirable. So maybe having the '-f' cancel or override the '-i' operation might 
be a good change.

Thanks!
Mike

-Original Message-
From: Assaf Gordon [mailto:assafgor...@gmail.com] 
Sent: Friday, October 10, 2014 12:14 PM
To: Polehn, Mike A; 18...@debbugs.gnu.org
Subject: Re: bug#18681: The Linux cp command has bugs

Hello Mike,

On 10/10/2014 01:25 PM, Polehn, Mike A wrote:
 Problem need to copy a tree of 1000s of files to another directory 
 that is a git directory that has a whole bunch of additional build 
 files, so diff between the directories will not do any good.


This is slightly off-topic, but if you want to compare only files managed by 
git (ignoring other files in current directory), perhaps the following would 
help:

 # Download and extract the tarball
 wget -q http://dpdk.org/browse/dpdk/snapshot/dpdk-1.7.1.tar.gz
 tar -xf dpdk-1.7.1.tar.gz

 # Clone the git repo with specific branch, checkout the relevant branch
 # (or go to an existing checked-out repository directory)
 git clone git://dpdk.org/dpdk
 cd dpdk
 git checkout -b map_v1.7.1 v1.7.1

 # For each file managed by git (with 'git ls'),
 # compare it to the corresponding file in the other directory:
 git ls -0 | xargs -0 -I% diff -q % ../dpdk-1.7.1/%


Regards,
  -gordon

bug#18681: The Linux cp command has bugs

[Eric Blake]

On 10/10/2014 02:00 PM, Polehn, Mike A wrote:

 This still left the incorrect operation of the interactive operation when 
 both -i and -f is used.

The behavior of -i vs. -f interaction is required by POSIX; in
particular, POSIX is explicit that -i and -f are NOT a toggle switch of
one another, but each turns on slightly different, somewhat overlapping,
changes in behavior (so specifying both is different from specifying one
in isolation).  We can't change what either one of those flags means.
If there is another mode of operation that is also useful, then it needs
yet another flag.  At one point in the past, we had
--reply={yes,no,query} to try and offer a third mode, but it had
confusing semantics and we ended up pulling it because of the confusion
it could cause.  At the time we pulled it, we admitted that 'rsync' has
some modes of operations that might be better suited for the particular
modes that people people seemed to be requesting when they thought that
--reply would do the trick (and usually, what they thought --reply would
do and what it actually did were different, which is why we removed it
to avoid confusion).  We have also added a --no-clobber option, which is
somewhat of a compromise (what some people thought --reply=no would do,
--no-clobber actually does better).

So adding a new option is not out of the question, but you'd have to
have well-defined semantics of what it should do, and how it differs
from either normal mode, '-i' mode, '-f' mode, '-i -f' mode, or
'--no-clobber' mode.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#18681: The Linux cp command has bugs

[Norihiro Tanaka]

Hi Polehn,

The -f option isn't `suppress interactive' in cp.  It attempts to unlink
a destination not to be able to override.  It's different from the option
in mv.

As the behavior is clearly defined in POSIX as Eric says, we won't be
able to change it.

BTW, I don't like the alias `cp -i'.  So I remove it from .bashrc always
immediately after an installation of a distribution. (^_^)

If you temporarily want to cancel the the alias, you can define an another
alias as `cpf', and/or can use below instead of `cp'

  - command cp -f
  - /bin/cp -f
  - ( unalias cp; cp -f ... )

Even if add new option `-F' to supress interactive to cp, we need to use
-F for cp and -f for mv to do it.

bug#18681: The Linux cp command has bugs

[Jon Stanley]

On Fri, Oct 10, 2014 at 7:48 PM, Norihiro Tanaka nori...@kcn.ne.jp wrote:
 If you temporarily want to cancel the the alias, you can define an another
 alias as `cpf', and/or can use below instead of `cp'

Note that (in bash at least) you can prefix the command with a
backslash (\) to override an alias for that invocation, and is what I
typically do:

$ \cp blah

bug#17188: Sort bugs

[Eric Blake]

On 04/05/2014 02:44 PM, Nikos Balkanas wrote:

 What about sorting input based on the input's locale, instead of the
 system's?

And how do you propose to detect the input's locale?  The canonical way
to tell a program what locale the input is in is by setting the
environment variable LC_COLLATE and/or LC_ALL.

 Sort
 can distinguish ASCII (iso) from UTF-8 and collate accordingly.

ASCII is a subset of UTF-8.  There is no way to tell if input was
intended as one or the other without setting an environment variable to
make your intentions clear - but this is precisely what you already do
to get sort to do what you want.  And since this behavior is mandated by
POSIX (the behavior of LC_ALL and friend controlling how 'sort' and all
other utilities will collate, based on the definition of the chosen
locale), it is better to point people to a consistent standard that will
work across ALL implementations of 'sort', than it is to invent yet
another non-standard knob for just GNU sort.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#17188: Sort bugs

[Nikos Balkanas]

Hi,

Sort is seriously bugged. This is the output from:

sort -d -t \t -k1 input  out

0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr

Shouldn't 00/0 be first according to Ascii code?

Plz fix.

TIA,
Nikos

bug#17188: Sort bugs

[Eric Blake]

tag 17188 notabug
thanks

On 04/04/2014 08:07 PM, Nikos Balkanas wrote:
 Hi,
 
 Sort is seriously bugged. This is the output from:
 
 sort -d -t \t -k1 input  out

-d says to do a dictionary sort that ignores non-alphanumeric
characters.  But it still leaves it up to your current locale on whether
those non-alpha characters are collated case-insensitively.

Also, '-k1' is almost always wrong - you generally want '-k1,1' if you
want to sort by JUST the first field, rather than by the whole line.

See the FAQ:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021

 
 0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
 000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
 000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
 00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
 000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr
 
 Shouldn't 00/0 be first according to Ascii code?

Only if you are asking for a full ASCII sort.  Here, I'm adding -s for
fewer lines, but using --debug can sometimes help show you where you are
asking sort to do something different than you expected, but where sort
is behaving correctly given what you asked it to do.

I'm guessing your default locale is en_US.UTF-8 - because I get the same
results as you in that mode:

$ sort --debug -s -d -t \t -k1 input
sort: using ‘en_US.UTF-8’ sorting rules
0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
___
000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
__
000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
__
00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
__
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr
___

In this mode, '000p' collates case-insensitively before '000Q', so the
sort is correct (the collation was on '000Q' and not '00/0Q' because you
used -d).  Furthermore, if you omit -d:

$ sort --debug -s -t \t -k1 input
sort: using ‘en_US.UTF-8’ sorting rules
0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
___
000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
__
000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
__
00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
__
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr
___

No change, because the en_US.UTF-8 locale implicitly does a dictionary
collation even without you requesting -d.

Now, compare to the C locale, which forces sorting by byte value for
more traditional ASCII sorting:


$ LC_ALL=C sort --debug -s -d -t \t -k1 input
sort: using simple byte comparison
0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
___
000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
__
00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
__
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr
___
000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
__


'000Q' now sorts before '000R' which sorts before '000p' as expected.
And toss out the -d, and you get:

$ LC_ALL=C sort --debug -s -t \t -k1 input
sort: using simple byte comparison
00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
__
0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
___
000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
__
000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr
___
000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
__


Now '00/' sorts before '000'.

It might be a nice 

bug#17188: Sort bugs

[Nikos Balkanas]

On Sat, Apr 5, 2014 at 3:21 PM, Eric Blake ebl...@redhat.com wrote:

 tag 17188 notabug
 thanks

 On 04/04/2014 08:07 PM, Nikos Balkanas wrote:
  Hi,
 
  Sort is seriously bugged. This is the output from:
 
  sort -d -t \t -k1 input  out

 -d says to do a dictionary sort that ignores non-alphanumeric
 characters.  But it still leaves it up to your current locale on whether
 those non-alpha characters are collated case-insensitively.

 Also, '-k1' is almost always wrong - you generally want '-k1,1' if you
 want to sort by JUST the first field, rather than by the whole line.


​Sorting by the first line? What is that? Sort should work on each line by
given columns

Unix man:

KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F
is a field number and C a character position in the field; both are ori‐
  gin 1, and the stop position defaults to the line's end...

In retrospect this confirms your saying. However, on first look, it doesn't
make sense. An example
like the one you gave me, in the man page would save a lot of explaining.


 See the FAQ:

 https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021


​From that link:​
​So far there is still no fully satisfactory solution to this problem. If
you find one then please contact me so that this information can be listed.

If you are me, then I would like to suggest that you make default the
legacy sort behaviour, and add with -c the locale support
that standards and non-English users ask for.


  0009rN2S3cohd2DGH6yuTWBoeuq6DwWZhCBDEnFzYqpw984FfALy7NUhEZH1.YEbiq/
  000EMQeKUjtyXIOaUkT.XE6SaBIdOqTA0nffF394V6tkcVdup2c3ihi7yhbuRof2Y5agTG
  000p8kXIz5Tc1GaxYYXjAfgm7YJOZvyBJxVXMi0lhaJXT22IdDbE6vVhWXW9FkRBxQ
  00/0QwzaXrqGHXW7mE9Le8IIVgHoZvccgGydKdzJgh8.SZenbULmIWMtrGShz24W7T
  000R2cnZ8.khe1eXDERclkbXASRQeKvcNBaCJRLX617Xvmff0KaoZSSFBNhNG1OiIyr
 
  Shouldn't 00/0 be first according to Ascii code?


​I have to sort billions of these hashes in TB sizes of files. These are
followed by a TAB and a key (therefore the -t \t).
I was considering downloading legacy sort sources and compiling for my
system. Or taking recent sources and fixing the source.
Both dreadful aspects, because it would make my system incompatible and
inconsistent. You don't know how happy you make me,
that i can still get legacy behaviour out of the modern releases.

 There's nothing to fix but your usage pattern.  So I'm closing this as
 not a bug.  But feel free to reply further if you still have questions.


​UI is still a bug, though not a code bug. And legacy UI compatibility is
broken. However, I am perfectly satisfied with your fast and long
explanation of what the status is.
You will, however, go crazy if you respond like that to every user with a
locale sorting issue.  Can't you make default LOCALE=C for sorting and
allow users to change that
to the system settings using -c when they need it? Nowadays users use other
graphical tools to do sorting, sort is used mostly by scripts.

Thank you,
Nikos



 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org

bug#17188: Sort bugs

[Bob Proulx]

Nikos Balkanas wrote:
 Eric Blake wrote:
  See the FAQ:
 
  https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021
 
 ​From that link:​
 ​So far there is still no fully satisfactory solution to this problem. If
 you find one then please contact me so that this information can be listed.
 
 If you are me, then I would like to suggest that you make default
 the legacy sort behaviour, and add with -c the locale support that
 standards and non-English users ask for.

When I wrote that I did mean within the confines of continuing to
conform to the standards.  :-)

 ​UI is still a bug, though not a code bug. And legacy UI compatibility is
 broken.

Actually no.  If you were really using the legacy UI then you would be
using the legacy locale setting LC_ALL=C too.  If you aren't then you
aren't using the legacy UI.

 However, I am perfectly satisfied with your fast and long
 explanation of what the status is.
 You will, however, go crazy if you respond like that to every user with a
 locale sorting issue.

I usually rant:

You don't like it and I don't like it but the-powers-that-be have
confused working with data on a computer with talking about working
with data on a computer.  They have decided that the collation
ordering (sort ordering) for data should be dictionary ordering.  In
dictionary ordering case is folded together and punctuation is
ignored.  By having LANG set to any of the en locales the system is
instructed to use dictionary sort ordering.  This affects almost
everything on the system that sorts.  This includes commands such as
'ls' and also your shell (e.g. 'echo *') too.

 Can't you make default LOCALE=C for sorting and allow users to
 change that to the system settings using -c when they need it?

Actually no we can't.  That would break the opposite side of things
where people rely upon dictionary sorting based upon their chosen
locale setting.  After all of these years that would be equally bad in
the opposite way.

I am going to say you here but please don't take this as hostility.
It is a bad word in text email.  But I am really just trying to put
down the facts of the case.

Originally the locale was C.  If you go back to the C locale things
will be working for you as you wish it to work.  It will work as it
worked before.  Agreed?

Then you changed something.  You changed the locale.  You in your
environment set LANG=en_US.UTF-8 (or similar equivalent).  That is
when you notice that sort doesn't work as you want it to work.

Now you might say that you personally didn't make that choice but your
system vendor did.  It happened when you switched to a new machine
running a newer system or something.  Okay.  But you chose that system
vendor.  You could choose a different system vendor.  Or choose to go
back to the previous system with the previous LANG=C locale.  Or
choose to configure the new system as you wish it.  You are in control
of it.

As a pilot we have a saying, Fly the airplane.  Don't let the
airplane fly you. :-)

You could file bugs with your system vendor that they defaulted you to
LANG=en_US.UTF-8 and ask them to allow users to choose LANG=C at
install time instead.  I have done this and unfortunately the response
from one vendor was That was intentional. with the bug closed and
locked against further comment.  The door slammed in my face.  I am
now using a different software distribution.

 Nowadays users use other graphical tools to do sorting, sort is used
 mostly by scripts.

For you perhaps.  Not for me.  Not for many people.  I have no idea
what the survey count would be either way but it doesn't matter.
Can't make the mistake of assuming that any one environment is more
important to the exclusion of all others.

But you see the problem isn't a change in sort.  The problem is a
change in locale.  Sort is behaving as it has for years and years.
What changed was the locale that most people get by default.  It used
to be that users would get LANG=C.  But these days most users get
LANG=en_US.UTF-8.  But with a dictionary collating sort order locale
it behaves undesirably to many of us.  But to others that is exactly
what they want.  And so they wrote it into the locale.  Two opposing
viewpoints that being in opposition cannot be converged.

Note that this is bigger than just sort.  This affects everything on
your system.  It affects the shell.  Try echo * and look at the sort
ordering.  Same thing there.  The shell will sort by locale sort order.

The only way to fix it is to fix it at the source of the problem.  The
source is the locale collation sequence.  Which is why I always set
this in my environment.

  export LANG=en_US.UTF-8
  export LC_COLLATE=C

But while that works for most western locales I have no idea how that
would interact with chinese big5 for example.  Probably badly.  So it
can't really be offered as a general solution to the problem.  But if
you are using one of the set of western locales that it works

bug#17188: Sort bugs

[Nikos Balkanas]

On Sat, Apr 5, 2014 at 11:23 PM, Bob Proulx b...@proulx.com wrote:

[...snip...]


 Originally the locale was C.  If you go back to the C locale things
 will be working for you as you wish it to work.  It will work as it
 worked before.  Agreed?

 Then you changed something.  You changed the locale.  You in your
 environment set LANG=en_US.UTF-8 (or similar equivalent).  That is
 when you notice that sort doesn't work as you want it to work.


What about sorting input based on the input's locale, instead of the
system's? Sort
can distinguish ASCII (iso) from UTF-8 and collate accordingly. Even users
in UTF-8
systems (like me) get ASCII files smts and need to collate them correctly.
For sanity
purposes users could override the locale with a command line option.

[...snip...]


   The only way to fix it is to fix it at the source of the problem.  The
 source is the locale collation sequence.  Which is why I always set
 this in my environment.

   export LANG=en_US.UTF-8
   export LC_COLLATE=C

 But while that works for most western locales I have no idea how that
 would interact with chinese big5 for example.  Probably badly.  So it
 can't really be offered as a general solution to the problem.  But if
 you are using one of the set of western locales that it works for then
 it does solve the problem for you.


That is dangerous. I don't know how much software will stop working
correctly because of that.
Of course, one can always return locale back to its original value, but
problems might not be that obvious at all :-(

[...snip...]


 Bob

bug#15206: Report od bugs

[Kaitao Lai]

Dear Sir/Madam,

I am writing this email to report a bug from od command. I am working in 
bioinformatics research filed, and currently I am trying to convert phred 
scores from fastq format file to Ascii values, and met weird things. For 
example, when I try to convert 100 characters into ASCII values, if the last 30 
characters are the same, it only return part of values, NOT the complete values.
The example is listed below:
If there is very long poly-# string, then below 100 characters only return 84 
ASCII values.

$ echo 
'=:?D+AABB?DCAFEBAF?GHIBGFGCDGBGAFG8CF?F?D=DG?BFHG=@77C#'
 | od -An -t dC
   61   58   63   68   43   65   65   66   60   66   63   68   67   65   70   69
   66   65   70   63   71   72   73   66   71   70   71   67   68   71   66   71
   65   70   71   56   67   70   63   70   63   68   61   68   71   63   66   70
   72   71   61   64   55   55   67   35   35   35   35   35   35   35   35   35
   35   35   35   35   35   35   35   35   35   35   35   35   35   35   35   35
*
   35   35   35   35   10

If I changed the last poly-# with one different character, it can return the 
full 100 ASCII values. Please see below:

$ echo 
'=:?D+AABB?DCAFEBAF?GHIBGFGCDGBGAFG8CF?F?D=DG?BFHG=@77C##A##'
 | od -An -t dC
   61   58   63   68   43   65   65   66   60   66   63   68   67   65   70   69
   66   65   70   63   71   72   73   66   71   70   71   67   68   71   66   71
   65   70   71   56   67   70   63   70   63   68   61   68   71   63   66   70
   72   71   61   64   55   55   67   35   35   35   35   35   35   35   35   35
   35   35   35   35   35   35   35   35   35   35   35   35   35   65   35   35
   35   35   35   35   35   35   35   35   35   35   35   35   35   35   35   35
   35   35   35   35   10

Above command is running in Ubuntu environment. I am looking forward to your 
reply.


Cheers,
Kaitao Lai

bug#15206: Report od bugs

[Eric Blake]

tag 15206 notabug
thanks

On 08/29/2013 12:01 AM, Kaitao Lai wrote:
 Dear Sir/Madam,
 
 I am writing this email to report a bug from od command. I am working in 
 bioinformatics research filed, and currently I am trying to convert phred 
 scores from fastq format file to Ascii values, and met weird things. For 
 example, when I try to convert 100 characters into ASCII values, if the last 
 30 characters are the same, it only return part of values, NOT the complete 
 values.
 The example is listed below:
 If there is very long poly-# string, then below 100 characters only return 84 
 ASCII values.
 
 $ echo 
 '=:?D+AABB?DCAFEBAF?GHIBGFGCDGBGAFG8CF?F?D=DG?BFHG=@77C#'
  | od -An -t dC
61   58   63   68   43   65   65   66   60   66   63   68   67   65   70   
 69
66   65   70   63   71   72   73   66   71   70   71   67   68   71   66   
 71
65   70   71   56   67   70   63   70   63   68   61   68   71   63   66   
 70
72   71   61   64   55   55   67   35   35   35   35   35   35   35   35   
 35
35   35   35   35   35   35   35   35   35   35   35   35   35   35   35   
 35
 *
35   35   35   35   10

This behavior is documented, and required by POSIX.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html

If you don't want elision of identical lines, then you must use the -v
option.

As this is working as intended, and is just usage error on your part,
I'm marking this as not a bug.  Feel free to add further comments or
questions to this report, though.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#15206: Report od bugs

[Pádraig Brady]

On 08/29/2013 12:51 PM, Eric Blake wrote:
 tag 15206 notabug
 thanks
 
 On 08/29/2013 12:01 AM, Kaitao Lai wrote:
 Dear Sir/Madam,

 I am writing this email to report a bug from od command. I am working in 
 bioinformatics research filed, and currently I am trying to convert phred 
 scores from fastq format file to Ascii values, and met weird things. For 
 example, when I try to convert 100 characters into ASCII values, if the last 
 30 characters are the same, it only return part of values, NOT the complete 
 values.
 The example is listed below:
 If there is very long poly-# string, then below 100 characters only return 
 84 ASCII values.

 $ echo 
 '=:?D+AABB?DCAFEBAF?GHIBGFGCDGBGAFG8CF?F?D=DG?BFHG=@77C#'
  | od -An -t dC
61   58   63   68   43   65   65   66   60   66   63   68   67   65   70  
  69
66   65   70   63   71   72   73   66   71   70   71   67   68   71   66  
  71
65   70   71   56   67   70   63   70   63   68   61   68   71   63   66  
  70
72   71   61   64   55   55   67   35   35   35   35   35   35   35   35  
  35
35   35   35   35   35   35   35   35   35   35   35   35   35   35   35  
  35
 *
35   35   35   35   10
 
 This behavior is documented, and required by POSIX.
 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html
 
 If you don't want elision of identical lines, then you must use the -v
 option.
 
 As this is working as intended, and is just usage error on your part,
 I'm marking this as not a bug.  Feel free to add further comments or
 questions to this report, though.
 

Also in case it's of any use, there was mention of fastq processing in:
http://bugs.gnu.org/13089#15

cheers,
Pádraig.

bug#13899: Bugs in echo and printf

[Sérgio Coutinho]

Hello!

I discovered a few bugs in echo and printf.

echo --help
echo --version
printf --help
printf --version

They all don't work...

Sergio

bug#13899: Bugs in echo and printf

[Ruediger Meier]

On Thursday 07 March 2013, Sérgio Coutinho wrote:
 Hello!

 I discovered a few bugs in echo and printf.

 echo --help
 echo --version
 printf --help
 printf --version

 They all don't work...

 Sergio

Probably you are using the shell builtins. Have you tried with full path
/usr/bin/echo --version
/usr/bin/printf --version

cu,
Rudi

bug#13899: Bugs in echo and printf

[Eric Blake]

tag 13899 notabug
thanks

On 03/07/2013 02:57 PM, Sérgio Coutinho wrote:
 Hello!
 
 I discovered a few bugs in echo and printf.
 
 echo --help
 echo --version
 printf --help
 printf --version
 
 They all don't work...

Thanks for the report.  However, without telling us what you saw vs.
what you were expecting, it's hard to guess what you saw, or why you
think that what you saw is wrong.  Furthermore, I suspect this is
misunderstanding on your part, rather than an actual bug in coreutils.

First, are you sure you were even testing coreutils' binaries, or were
you testing the builtins that ship as part of your shell?  For these two
binaries, you are best off running 'env echo' or 'env printf' if you
want to ensure that you are running the executable that coreutils
installed into your PATH rather than your shell's version.

Second, the behavior we have is intentional:

By default, coreutils' echo produces useful messages, even though this
violates POSIX:

$ env -u POSIXLY_CORRECT echo --help | tail -n1
For complete documentation, run: info coreutils 'echo invocation'
$ env -u POSIXLY_CORRECT echo --version | head -n1
echo (GNU coreutils) 8.17

You can bypass these messages by asking for POSIX compliance, so that
our hands are tied and we output a literal string:

$ env POSIXLY_CORRECT=1 echo --help
--help
$ env POSIXLY_CORRECT=1 echo --version
--version

Meanwhile, for printf, our behavior of useful messages is an extension
permitted by POSIX, so POSIXLY_CORRECT has no impact on operation:

$ env printf --help | tail -n1
For complete documentation, run: info coreutils 'printf invocation'
$ env printf --version | head -n1
printf (GNU coreutils) 8.17

And again, you can bypass these messages with the POSIX-mandated syntax:

$ env printf -- --help
--help
$ env printf -- --version
--version

As such, I'm closing this bug report, although you can feel free to add
further comments or questions.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#11164: reporting of bugs in lfs

[Bob Proulx]

tags 11164 - moreinfo
close 11164
thanks

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11164

It has been five months since more information was requested on this
bug.  Without further information nothing can be resolved.  Therefore
I am closing this ticket.  If you do have more information please feel
free to continue the discussion.

Also, if you do send a test log please compress the log file.
Compressed log files are a fraction of the size of the raw file.  It
is much easier on the mailing lists that way.  Thanks.

Bob

bug#10900: Clarification re: Regarding the observed bugs in cp

[era eriksson]

I stumbled across your recent bug report for cp
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10900
and I was wondering if you could follow up with a bit of additional
information.  What did you expect to happen, and what should be fixed in
order for cp to behave like you expect?

Thanks for your bug report!  I am but a mere bystander, but I appreciate
your effort.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

bug#10900: Clarification re: Regarding the observed bugs in cp

[era eriksson]

Forwarding a replyI only received in private.  Please keep the Cc: on
any followups.

From: subratkumar subratkuma...@globaledgesoft.com
To: era eriksson e...@iki.fi
Date: Thu, 30 Aug 2012 17:04

On Thursday 30 August 2012 01:38 PM, era eriksson wrote:

I stumbled across your recent bug report for cp
[1]http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10900
and I was wondering if you could follow up with a bit of additional
information.  What did you expect to happen, and what should be fixed in
order for cp to behave like you expect?

Thanks for your bug report!  I am but a mere bystander, but I appreciate
your effort.

/* era */


I expected :
1.cp -r dir1 dir1 (should not copy dir1 inside dir1) ,it was coming with an erro
r message but it was copying inside dir1 ,please check it inside dir1.
2.cp -s file1 ../dir1/ (symlinking out side the current directory should be allo
wed) but it came with error symlink restricted to  current directory.
Please have a look. Let me know about these.

--

Thanks  regards
Subrat Kumar Ojha
PMG, Global Edge Software Ltd.
Mob - +91 - 9620262307

References

1. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10900
attachment: subratkumar_o.vcf

bug#11217: Bugs in coreutils 8.13-8.16 (German localization)

[Philipp Thomas]

* cbr...@arcor.de (cbr...@arcor.de) [20120411 10:13]:

 ln: Symbolischen Verknüpfung „./bar“ konnte angelgt werden: Die Datei 
 existiert bereits.
 
 Corrected error message reads like this:
 ln: Symbolische Verknüpfung „./bar“ konnte nicht angelegt werden: Die Datei 
 existiert bereits.

When you do 'ln --help' the german message will tell you in the second to
last line:

Melden Sie Übersetzungsfehler für ln an 
translation-team...@lists.sourceforge.net

meaning

Report ln translation bugs to http://translationproject.org/team/

Why didn't you do so?  Please send your bug report to the stated mailing list
address. As I am the current translator for german I'll fix this when time
permits, but please do report the bug to help me keep track.

Philipp

bug#11217: Bugs in coreutils 8.13-8.16 (German localization)

[Pádraig Brady]

tags 11217 notabug

On 04/11/2012 02:12 AM, cbr...@arcor.de wrote:
 Package: coreutils
 Version:  8.13 - 8.16
 
 Faults:
 (only applicable to german localization):
 When trying to re-create an already created symbolic link, ln's error message 
 contains three faults,
 one grammatical, one [important] logical one orthographical.
 
 Reproduction:
 
 touch ./foo
 ln -s ./foo ./bar
 then again:
 ln -s ./foo ./bar
 ln: Symbolischen Verknüpfung „./bar“ konnte angelgt werden: Die Datei 
 existiert bereits.
 
 Corrected error message reads like this:
 ln: Symbolische Verknüpfung „./bar“ konnte nicht angelegt werden: Die Datei 
 existiert bereits.
 
 Corrections:
 - 1) Symbolische Verknüpfung [...] - minor important grammatical mistake.
 - 2) [...] konnte nicht angelgt werden: [...] - this one is important, the 
 negotiation is missing.
 - 3) [...] angelegt werden: [...] - minor important ortographical mistake 
 (typo).
 
 whereas original english errStr is correct:
 LC_ALL=C ln -s ./foo ./bar
 ln: failed to create symbolic link `bar': File exists
 
 File /usr/share/locale/de/LC_MESSAGES/coreutils.mo  (binary) - (tested using 
 Debian coreutils 8.13-3.1)
 resp. ./po/de.po  ./po/de.gmo source (8.13, 8.14, 8.15, 8.16) belong to 
 'coreutils', not 'locales', so this is a coreutils problem.
 
 I've reported the problem at bugs.debian.org, too - since it may be in the 
 interest of Debian to correct this in distribution packages before 8.17 or so 
 migrates to sid/testing.
 
 Yfyi: German localization files contain several other typos/mistakes.
 
 Best regards,
 C. Brill  Frankfurt /Germany

Thanks.
You may want to join http://translationproject.org/team/de.html
and fix the translations directly. We get our translations from there.

cheers,
Pádraig.

bug#11217: Bugs in coreutils 8.13-8.16 (German localization)

[cbrill]

Package: coreutils
Version:  8.13 - 8.16

Faults:
(only applicable to german localization):
When trying to re-create an already created symbolic link, ln's error message 
contains three faults,
one grammatical, one [important] logical one orthographical.

Reproduction:

touch ./foo
ln -s ./foo ./bar
then again:
ln -s ./foo ./bar
ln: Symbolischen Verknüpfung „./bar“ konnte angelgt werden: Die Datei existiert 
bereits.

Corrected error message reads like this:
ln: Symbolische Verknüpfung „./bar“ konnte nicht angelegt werden: Die Datei 
existiert bereits.

Corrections:
- 1) Symbolische Verknüpfung [...] - minor important grammatical mistake.
- 2) [...] konnte nicht angelgt werden: [...] - this one is important, the 
negotiation is missing.
- 3) [...] angelegt werden: [...] - minor important ortographical mistake 
(typo).

whereas original english errStr is correct:
LC_ALL=C ln -s ./foo ./bar
ln: failed to create symbolic link `bar': File exists

File /usr/share/locale/de/LC_MESSAGES/coreutils.mo  (binary) - (tested using 
Debian coreutils 8.13-3.1)
resp. ./po/de.po  ./po/de.gmo source (8.13, 8.14, 8.15, 8.16) belong to 
'coreutils', not 'locales', so this is a coreutils problem.

I've reported the problem at bugs.debian.org, too - since it may be in the 
interest of Debian to correct this in distribution packages before 8.17 or so 
migrates to sid/testing.

Yfyi: German localization files contain several other typos/mistakes.

Best regards,
C. Brill  Frankfurt /Germany

bug#11164: reporting of bugs in lfs

[vr tech labs]

i am getting the bug while running   the following command
make RUN_EXPENSIVE_TESTS=yes check
the error is
See tests/test-suite.log
Please report to bug-coreutils@gnu.org

make[4]: *** [test-suite.log] Error 1
make[4]: Leaving directory `/mnt/lfs/sources/coreutils-8.15/tests'
make[3]: *** [check-TESTS] Error 2
make[3]: Leaving directory `/mnt/lfs/sources/coreutils-8.15/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/mnt/lfs/sources/coreutils-8.15/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/mnt/lfs/sources/coreutils-8.15'
make: *** [check] Error 2

bug#11164: reporting of bugs in lfs

[Eric Blake]

tag 11164 needinfo
thanks

On 04/03/2012 09:52 AM, vr tech labs wrote:
 i am getting the bug while running   the following command
 make RUN_EXPENSIVE_TESTS=yes check
 the error is
 See tests/test-suite.log
 Please report to bug-coreutils@gnu.org

Thanks for the report.  However, you didn't follow the instructions of
actually mailing tests/test-suite.log here, so we don't know what your
failure is, or how to help you without more information from you.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#10900: Regarding the observed bugs in cp

[subratkumar]

1. cp -r a a
cp: cannot copy a directory, `a', into itself, `a/a'
as per this the it is not allowable to copy a into a.But its doing
2. cp -s b ../
cp: `../b': can make relative symbolic links only in current directory
its a symbolic link and should not restrict to current directory.
i have checked it in kernel 2.6.21.5 and 3.04 .Please check it and let 
me know if its corrected or not.

Thanks and Regards
Subrat Kumar Ojha

bug#9718: bugs in `date` command?

[Voelker, Bernhard]

Jim Meyering wrote:

 Eric Blake wrote:
 ...
  As currently coded in the grammar, this is correct.  But if someone
  were willing to put forth the effort to update parsedate.y, as well as
  enhance the testsuite to cover things, it might be possible to improve
  the grammar to accept both common meanings of second depending on
  the context where it appears compared to the rest of the date.
 
 Just in case, I've marked this as wishlist.
 If you're interested, please add it to TODO.
 If not, please close this.

I don't know if it violates some standards, but I'd vote for
abbreviations like 1st, 2nd, 3rd, 4th, etc. which do not
interfere with the double meaning of second.
What do you think?

Have a nice day,
Berny

bug#9718: bugs in `date` command?

[Jim Meyering]

severity 9718 wishlist
tags 9718 + notabug
thanks

Eric Blake wrote:
...
 As currently coded in the grammar, this is correct.  But if someone
 were willing to put forth the effort to update parsedate.y, as well as
 enhance the testsuite to cover things, it might be possible to improve
 the grammar to accept both common meanings of second depending on
 the context where it appears compared to the rest of the date.

Just in case, I've marked this as wishlist.
If you're interested, please add it to TODO.
If not, please close this.

bug#9718: bugs in `date` command?

[Voelker, Bernhard]

Bryan Lee wrote:

 The term third wednesday seems to be evaluating incorrectly.
 
 glaive 12:24:56 [~]% date
 Mon Oct 10 12:24:59 EDT 2011
 
 glaive 12:24:59 [~]% date -d first wednesday
 Wed Oct 12 00:00:00 EDT 2011
 
 glaive 12:25:09 [~]% date -d second  wednesday
 Wed Oct 12 00:00:01 EDT 2011
 
 glaive 12:25:16 [~]% date -d third  wednesday
 Wed Oct 26 00:00:00 EDT 2011
 
 glaive 12:25:21 [~]% date -d fourth  wednesday
 Wed Nov  2 00:00:00 EDT 2011

Thank you for the report, however I don't see what's wrong.
I guess you meant second wednesday - which you probably expected
to display Oct 19th?

As 'second' is already used for the time unit 'second', it cannot
be used as an ordinal number for 2nd. The info text clarifies this
(info coreutils 'date invocation'):

 A few ordinal numbers may be written out in words in some contexts.
  This is most useful for specifying day of the week items or relative
  items (see below).  Among the most commonly used ordinal numbers, the
  word `last' stands for -1, `this' stands for 0, and `first' and `next'
  both stand for 1.  Because the word `second' stands for the unit of
  time there is no way to write the ordinal number 2, but for convenience
  `third' stands for 3, `fourth' for 4, `fifth' for 5, `sixth' for 6,
  `seventh' for 7, `eighth' for 8, `ninth' for 9, `tenth' for 10,
  `eleventh' for 11 and `twelfth' for 12.

Did you mean this?

Have a nice day,
Berny

bug#9718: bugs in `date` command?

[Eric Blake]

On 10/11/2011 01:31 AM, Voelker, Bernhard wrote:

Bryan Lee wrote:


The term third wednesday seems to be evaluating incorrectly.

glaive 12:24:56 [~]% date
Mon Oct 10 12:24:59 EDT 2011

glaive 12:24:59 [~]% date -d first wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:25:09 [~]% date -d second  wednesday
Wed Oct 12 00:00:01 EDT 2011


Indeed, this was parsed as first wednesday + 1 second


Thank you for the report, however I don't see what's wrong.
I guess you meant second wednesday - which you probably expected
to display Oct 19th?

As 'second' is already used for the time unit 'second', it cannot
be used as an ordinal number for 2nd.


As currently coded in the grammar, this is correct.  But if someone were 
willing to put forth the effort to update parsedate.y, as well as 
enhance the testsuite to cover things, it might be possible to improve 
the grammar to accept both common meanings of second depending on the 
context where it appears compared to the rest of the date.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

bug#9718: bugs in `date` command?

[Bryan Lee]

The term third wednesday seems to be evaluating incorrectly.


glaive 12:24:56 [~]% date
Mon Oct 10 12:24:59 EDT 2011

glaive 12:24:59 [~]% date -d first wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:25:09 [~]% date -d second  wednesday
Wed Oct 12 00:00:01 EDT 2011

glaive 12:25:16 [~]% date -d third  wednesday
Wed Oct 26 00:00:00 EDT 2011

glaive 12:25:21 [~]% date -d fourth  wednesday
Wed Nov  2 00:00:00 EDT 2011

glaive 12:25:27 [~]% date -d fifth  wednesday
Wed Nov  9 00:00:00 EST 2011

glaive 12:25:34 [~]% date -d next  wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:25:41 [~]% date -d last  wednesday
Wed Oct  5 00:00:00 EDT 2011

glaive 12:25:46 [~]% date -d this  wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:33:39 [~]% date -d third  wednesday this month
Wed Oct 26 00:00:00 EDT 2011

glaive 12:34:11 [~]% date -d 3  wednesday
Wed Oct 26 00:00:00 EDT 2011

glaive 12:34:13 [~]% date -d 2  wednesday
Wed Oct 19 00:00:00 EDT 2011

glaive 12:34:28 [~]% date -d 1  wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:34:39 [~]% date -d 4  wednesday
Wed Nov  2 00:00:00 EDT 2011

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

[Jim Meyering]

Paul Eggert wrote:
 That probably deserves a NEWS entry
 Thanks, I pushed this:

Thanks.  Closing.

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

[Paul Eggert]

On 07/24/10 18:13, Pádraig Brady wrote:

 That probably deserves a NEWS entry

Thanks, I pushed this:

From 01ca128807be89f7a2709e7a12e2cd1498f3d96b Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Sun, 25 Jul 2010 10:53:42 -0700
Subject: [PATCH] du: add NEWS entry for recent du -L fixes

---
 NEWS |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index 124ca5a..b19294b 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,9 @@ GNU coreutils NEWS-*- 
outline -*-
   link count is 1, even if the file is reached multiple times by
   following symlinks or via multiple arguments.

+  du -H and -L now consistently count pointed-to files instead of
+  symbolic links, and correctly diagnose dangling symlinks.
+
 ** New features

   cp now accepts the --attributes-only option to not copy file data,
--
1.7.1

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

[Paul Eggert]

No further comment, and that patch does fix some real bugs
and seems to be pretty safe, so I took the liberty of pushing it.

bug#6586: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

[Paul Eggert]

I noticed some performance problems in du in some weird cases: when
running commands like du X X it descended through X twice, even
though it output the information only once (and obviously needs to
descend only once).  While looking into the matter I found some weird
code in du.  For example:

  if (ent-fts_info == FTS_D || skip)
return ok;

  /* If the file is being excluded or if it has already been counted
 via a hard link, then don't let it contribute to the sums.  */
  if (skip
  || (!opt_count_all
   (hash_all || (! S_ISDIR (sb-st_mode)  1  sb-st_nlink))
   ! hash_ins (sb-st_ino, sb-st_dev)))
 ...

Obviously the second use of skip is entirely redundant, since when
skip is true the first if always returns.  And the skip isn't
done quite right, as errors can be reported even for skipped files.

And while fixing _this_, I discovered that du -L sometimes screws
up, in that it doesn't report dangling symlinks, or it mistakenly
counts the disk space for a symlink instead of for the pointed-to
file, or it omits a directory entirely.  Most of these bugs with du
-L have been present for some time, but one (the omission) is
something I introduced with my previous patch.

Fixing all this required rethinking how du's process_file function
works.  I can't easily untangle the bug fixes from the performance
improvements, so I'm taking the liberty of shipping out one patch for
both.

I must say that the code in fts.c is surely the worst in coreutils!
It's very hard to figure out under what cases FTS_DC can be returned
(is it always after FTS_D, or can it occur without a FTS_D, for
example), and similarly for FTS_DNR and FTS_ERR.  Perhaps at some
point we can find a cheerful contributor who can clean up the stables
in the fts code; or at least document it.  Anyway, I eventually gave
up, and wrote du.c so as to not assume properties of fts when I
couldn't be sure of them.


From 3e68ecc62ea435459f99bd8feff883f88f9a3823 Mon Sep 17 00:00:00 2001
From: Paul Eggert egg...@cs.ucla.edu
Date: Thu, 8 Jul 2010 10:34:40 -0700
Subject: [PATCH] du: tune, and fix some -L bugs with dangling or cyclic symlinks

* src/du.c (process_file): Avoid recalculation of hashes
and of file-exclusion for directories.  Do not descend into
the same directory more than once, unless -l is given; this is faster.
Calculate stat buffer lazily, since it
need not be computed at all for excluded files.
Count space if FTS_ERR, since stat buffer is always valid then.
No need for 'print' local variable.
(main): Use FTS_NOSTAT.  Use FTS_TIGHT_CYCLE_CHECK only when not
hashing everything, since process_file finds cycles on its own
when hashing everything.
* tests/du/deref: Add test cases for -L bugs.
---
 src/du.c   |  144 +---
 tests/du/deref |   16 ++
 2 files changed, 91 insertions(+), 69 deletions(-)

diff --git a/src/du.c b/src/du.c
index 739be73..d8c7e00 100644
--- a/src/du.c
+++ b/src/du.c
@@ -392,7 +392,7 @@ print_size (const struct duinfo *pdui, const char *string)
 static bool
 process_file (FTS *fts, FTSENT *ent)
 {
-  bool ok;
+  bool ok = true;
   struct duinfo dui;
   struct duinfo dui_to_print;
   size_t level;
@@ -407,79 +407,86 @@ process_file (FTS *fts, FTSENT *ent)
  The sum of the sizes of all entries in the hierarchy at or below the
  directory at the specified level.  */
   static struct dulevel *dulvl;
-  bool print = true;
 
   const char *file = ent-fts_path;
   const struct stat *sb = ent-fts_statp;
-  bool skip;
-
-  /* If necessary, set FTS_SKIP before returning.  */
-  skip = excluded_file_name (exclude, file);
-  if (skip)
-fts_set (fts, ent, FTS_SKIP);
+  int info = ent-fts_info;
 
-  switch (ent-fts_info)
+  if (info == FTS_DNR)
 {
-case FTS_NS:
-  error (0, ent-fts_errno, _(cannot access %s), quote (file));
-  return false;
-
-case FTS_ERR:
-  /* if (S_ISDIR (ent-fts_statp-st_mode)  FIXME */
-  error (0, ent-fts_errno, _(%s), quote (file));
-  return false;
-
-case FTS_DNR:
-  /* Don't return just yet, since although the directory is not readable,
- we were able to stat it, so we do have a size.  */
+  /* An error occurred, but the size is known, so count it.  */
   error (0, ent-fts_errno, _(cannot read directory %s), quote (file));
   ok = false;
-  break;
+}
+  else if (info != FTS_DP)
+{
+  bool excluded = excluded_file_name (exclude, file);
+  if (! excluded)
+{
+  /* Make the stat buffer *SB valid, or fail noisily.  */
+
+  if (info == FTS_NSOK)
+{
+  fts_set (fts, ent, FTS_AGAIN);
+  FTSENT const *e = fts_read (fts);
+  assert (e == ent);
+  info = ent-fts_info;
+}
 
-case FTS_DC:   /* directory that causes cycles */
-  if (cycle_warning_required (fts, ent))
+  if (info == FTS_NS || info == FTS_SLNONE

bug#5979: installation bugs

[Bob Proulx]

Bob Proulx wrote:
 What is ns2?

Since nothing has been heard in response I assume that your problem
has been resolved satisfactorily by the previous response.  Therefore
I am closing this bug.  It will remain in the archive and will remain
available for further comment.

Bob


 You have reached the GNU Coreutils mailing list.  The GNU Coreutils
 are the basic file, shell and text manipulation utilities of the GNU
 Operating System.  You can learn more about GNU Coreutils here:
 
   http://www.gnu.org/software/coreutils/
 
 The GNU Coreutils are part of the GNU Operating System.  You can learn
 more about the GNU Project here:
 
   http://www.gnu.org/
 
 But you are asking about ns2.  Whatever that is.  But ns2 is not a
 part of GNU coreutils and so I am at a loss as to how we might be able
 to help you with it.
 
 Bob

bug#5979: installation bugs

[Najla Al-Nabhan]

I'm trying to install ns2 under linux fedora 12. Could you please help me in
fixing these installation bugs:


/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:244: error:
‘TkBorder’ has no member named ‘darkGC’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:245: error:
‘TkBorder’ has no member named ‘lightGC’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:246: error:
‘TkBorder’ has no member named ‘hashPtr’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:247: error:
‘TkBorder’ has no member named ‘nextPtr’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:256: error:
‘gcValues’ undeclared (first use in this function)
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:256: error:
‘TkBorder’ has no member named ‘bgColorPtr’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:257: error:
‘TkBorder’ has no member named ‘bgGC’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:257: warning:
implicit declaration of function ‘Tk_GetGC’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:257: error:
‘GCForeground’ undeclared (first use in this function)
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c: In function
‘Tk_Draw3DRectangle’:
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:284: error: expected
declaration specifiers before ‘Drawable’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:292: error: argument
‘drawable’ doesn’t match prototype
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:247: error:
prototype declaration
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:292: error: argument
‘border’ doesn’t match prototype
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:247: error:
prototype declaration
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:292: error: number of
arguments doesn’t match prototype
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:247: error:
prototype declaration
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:300: warning: passing
argument 2 of ‘Tk_3DVerticalBevel’ makes pointer from integer without a cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:47: note: expected
‘Tk_3DBorder’ but argument is of type ‘int’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:300: warning: passing
argument 3 of ‘Tk_3DVerticalBevel’ makes integer from pointer without a cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:47: note: expected
‘int’ but argument is of type ‘Tk_3DBorder’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:300: error: too many
arguments to function ‘Tk_3DVerticalBevel’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:302: warning: passing
argument 2 of ‘Tk_3DVerticalBevel’ makes pointer from integer without a cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:47: note: expected
‘Tk_3DBorder’ but argument is of type ‘int’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:302: warning: passing
argument 3 of ‘Tk_3DVerticalBevel’ makes integer from pointer without a cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:47: note: expected
‘int’ but argument is of type ‘Tk_3DBorder’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:302: error: too many
arguments to function ‘Tk_3DVerticalBevel’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:304: warning: passing
argument 2 of ‘Tk_3DHorizontalBevel’ makes pointer from integer without a
cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:42: note: expected
‘Tk_3DBorder’ but argument is of type ‘int’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:304: warning: passing
argument 3 of ‘Tk_3DHorizontalBevel’ makes integer from pointer without a
cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:42: note: expected
‘int’ but argument is of type ‘Tk_3DBorder’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:304: error: too many
arguments to function ‘Tk_3DHorizontalBevel’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:306: warning: passing
argument 2 of ‘Tk_3DHorizontalBevel’ makes pointer from integer without a
cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:42: note: expected
‘Tk_3DBorder’ but argument is of type ‘int’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:306: warning: passing
argument 3 of ‘Tk_3DHorizontalBevel’ makes integer from pointer without a
cast
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tkDecls.h:42: note: expected
‘int’ but argument is of type ‘Tk_3DBorder’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:306: error: too many
arguments to function ‘Tk_3DHorizontalBevel’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c: In function
‘Tk_NameOf3DBorder’:
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:333: error:
‘TkBorder’ has no member named ‘hashPtr’
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c: At top level:
/root/ns-allinone-2.34/tk8.4.18/unix/../generic/tk3d.c:352: error: expected
‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__

bug#5979: installation bugs

[Bob Proulx]

tags 5979 + moreinfo
retitle 5979 ns2 installation problems
thanks

Najla Al-Nabhan wrote:
 I'm trying to install ns2 under linux fedora 12. Could you please help me in
 fixing these installation bugs:

What is ns2?

You have reached the GNU Coreutils mailing list.  The GNU Coreutils
are the basic file, shell and text manipulation utilities of the GNU
Operating System.  You can learn more about GNU Coreutils here:

  http://www.gnu.org/software/coreutils/

The GNU Coreutils are part of the GNU Operating System.  You can learn
more about the GNU Project here:

  http://www.gnu.org/

But you are asking about ns2.  Whatever that is.  But ns2 is not a
part of GNU coreutils and so I am at a loss as to how we might be able
to help you with it.

Bob

bug#5788: Savannah Bugs link broken

[Bob Proulx]

On the Savannah coreutils project page:

  https://savannah.gnu.org/bugs/?func=additemgroup=coreutils

The Bugs link points to:

  http://debbugs.gnu.org/coreutils/

But that location produces an HTTP 404 Not Found error.  The working
link location is:

  http://debbugs.gnu.org/coreutils

I don't know if enhancing debbugs.gnu.org to accept that URL is a
better solution than fixing the linking url.

Bob

bug#5788: Savannah Bugs link broken

[Bob Proulx]

Bob Proulx wrote:
 The Bugs link points to:
   http://debbugs.gnu.org/coreutils/
 But that location produces an HTTP 404 Not Found error.  The working
 link location is:
   http://debbugs.gnu.org/coreutils

Ah...  I found where to correct this on Savannah.  I also fixed the
Patches link too.

Bob

Re: new mailing list for non-bugs: coreut...@gnu.org

[Jim Meyering]

Sven Joachim wrote:
 On 2010-03-08 07:51 +0100, Jim Meyering wrote:
 There is a new mailing list: coreut...@gnu.org

 We will soon hook up a debbugs-based bug tracker to the existing,
 bug-coreutils list, and it will create a new ticket for each
 seemingly-new thread.

 We will then prefer to keep usage questions and general discussion on
 the new list.  Otherwise, we'll have to close each of those non-bugs.
 No big deal if people forget -- I'm sure it will take a while for the
 word to get out.  And finger-retraining takes time, too.

 Let's start with this policy: is if it might be a bug, send it to
 bug-coreut...@gnu.org.  Otherwise, use the new list: coreut...@gnu.org.

 I would like to subscribe this new list to Gmane¹ if nobody has done

Thanks!  That would be useful.

 this yet.  I suppose address encryption² could be turned off (makes it
 somewhat more convenient to reply) ?

Personally I wouldn't mind, but I know some
subscribers don't want their email shown in the clear,
so it's probably better not to do that.

 As for the group name, gmane.comp.gnu.core-utils.general seems to be a
 reasonable choice.

Like Bob, I would have preferred to spell it coreutils, but I think
we're stuck with gmane's existing/legacy spelling.

Re: new mailing list for non-bugs: coreut...@gnu.org

[Bob Proulx]

Jim Meyering wrote:
 Sven Joachim wrote:
  As for the group name, gmane.comp.gnu.core-utils.general seems to be a
  reasonable choice.
 
 Like Bob, I would have preferred to spell it coreutils, but I think
 we're stuck with gmane's existing/legacy spelling.

Legacy like this?

  http://dir.gmane.org/gmane.comp.gnu.coreutils.announce

Bob

Re: new mailing list for non-bugs: coreut...@gnu.org

[Sven Joachim]

On 2010-03-08 08:59 +0100, Jim Meyering wrote:

 Sven Joachim wrote:

 I would like to subscribe this new list to Gmane¹ if nobody has done

 Thanks!  That would be useful.

 this yet.  I suppose address encryption² could be turned off (makes it
 somewhat more convenient to reply) ?

 Personally I wouldn't mind, but I know some
 subscribers don't want their email shown in the clear,
 so it's probably better not to do that.

Okay.

 As for the group name, gmane.comp.gnu.core-utils.general seems to be a
 reasonable choice.

 Like Bob, I would have preferred to spell it coreutils, but I think
 we're stuck with gmane's existing/legacy spelling.

As Bob pointed out, there is gmane.comp.gnu.coreutils.announce already,
and it's not likely that there will be many gmane.comp.gnu.core* groups
in the future, so the coreutils groups will be adjacent anyway.

Sven

Re: new mailing list for non-bugs: coreut...@gnu.org

[Jim Meyering]

Bob Proulx wrote:

 Jim Meyering wrote:
 Sven Joachim wrote:
  As for the group name, gmane.comp.gnu.core-utils.general seems to be a
  reasonable choice.

 Like Bob, I would have preferred to spell it coreutils, but I think
 we're stuck with gmane's existing/legacy spelling.

 Legacy like this?

   http://dir.gmane.org/gmane.comp.gnu.coreutils.announce

Good point.  Forgot about that.  And that's the one *I* requested.
It's just that I don't use that one as much and had
become inured to the misspelling of

http://news.gmane.org/gmane.comp.gnu.core-utils.bugs

So getting the right name should be possible after all.

Re: new mailing list for non-bugs: coreut...@gnu.org

[Sven Joachim]

On 2010-03-08 09:57 +0100, Jim Meyering wrote:

 Bob Proulx wrote:

 Legacy like this?

   http://dir.gmane.org/gmane.comp.gnu.coreutils.announce

 Good point.  Forgot about that.  And that's the one *I* requested.
 It's just that I don't use that one as much and had
 become inured to the misspelling of

 http://news.gmane.org/gmane.comp.gnu.core-utils.bugs

 So getting the right name should be possible after all.

I went ahead and submitted a subscription request with the right name
and address encryption turned on.  If you should change your mind about
the latter at any time, contact the gmane.discuss group
(gmane-disc...@hawk.netfonds.no).

Sven

new mailing list for non-bugs: coreut...@gnu.org

[Jim Meyering]

There is a new mailing list: coreut...@gnu.org

We will soon hook up a debbugs-based bug tracker to the existing,
bug-coreutils list, and it will create a new ticket for each
seemingly-new thread.

We will then prefer to keep usage questions and general discussion on
the new list.  Otherwise, we'll have to close each of those non-bugs.
No big deal if people forget -- I'm sure it will take a while for the
word to get out.  And finger-retraining takes time, too.

Let's start with this policy: is if it might be a bug, send it to
bug-coreut...@gnu.org.  Otherwise, use the new list: coreut...@gnu.org.

Re: new mailing list for non-bugs: coreut...@gnu.org

[Chen Guo]

I'm assuming non-bug-fix patch submissions (i.e. adding features) should go to 
bug-coreutils still?

Re: new mailing list for non-bugs: coreut...@gnu.org

[Jim Meyering]

Chen Guo wrote:
 I'm assuming non-bug-fix patch submissions (i.e. adding features) should go 
 to bug-coreutils still?

Yes.
I've made coreutils-patc...@gnu.org an alias for bug-coreutils.

Re: new mailing list for non-bugs: coreut...@gnu.org

[Sven Joachim]

On 2010-03-08 07:51 +0100, Jim Meyering wrote:

 There is a new mailing list: coreut...@gnu.org

 We will soon hook up a debbugs-based bug tracker to the existing,
 bug-coreutils list, and it will create a new ticket for each
 seemingly-new thread.

 We will then prefer to keep usage questions and general discussion on
 the new list.  Otherwise, we'll have to close each of those non-bugs.
 No big deal if people forget -- I'm sure it will take a while for the
 word to get out.  And finger-retraining takes time, too.

 Let's start with this policy: is if it might be a bug, send it to
 bug-coreut...@gnu.org.  Otherwise, use the new list: coreut...@gnu.org.

I would like to subscribe this new list to Gmane¹ if nobody has done
this yet.  I suppose address encryption² could be turned off (makes it
somewhat more convenient to reply) ?

As for the group name, gmane.comp.gnu.core-utils.general seems to be a
reasonable choice.

Sven


¹ http://gmane.org/about.php
² http://gmane.org/tmda.php

Re: new mailing list for non-bugs: coreut...@gnu.org

[Bob Proulx]

Sven Joachim wrote:
 As for the group name, gmane.comp.gnu.core-utils.general seems to be a
 reasonable choice.

If we are voting then I would vote for coreutils and not
core-utils.

Bob

Re: new mailing list for non-bugs: coreut...@gnu.org

[Sven Joachim]

On 2010-03-08 08:50 +0100, Bob Proulx wrote:

 Sven Joachim wrote:
 As for the group name, gmane.comp.gnu.core-utils.general seems to be a
 reasonable choice.

 If we are voting then I would vote for coreutils and not
 core-utils.

Yes, good point.  It's just a bug that bug-coreutils@gnu.org is
gmane.comp.gnu.core-utils.bugs, and while existing groups on Gmane
cannot easily be renamed, there is no need to repeat this mistake.

Sven

Re: two new chroot bugs

[Giuseppe Scrivano]

Hi Jim,

Jim Meyering j...@meyering.net writes:

 From cfe8e7a0001a10d4deceb6065134fe8c402d0368 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@redhat.com
 Date: Thu, 28 May 2009 22:36:05 +0200
 Subject: [PATCH 1/4] tests: use nobody as the default group name in chroot 
 test

the nobody group is not present on all systems, for example on Debian
it is nogroup so IMHO it is better to find it at runtime using the
nobody user's group.

The second patch is just a small refactoring.

Cheers,
Giuseppe


From a089ec8770afa349f1e0b6e9d090d739f0afe6dd Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Sat, 4 Jul 2009 10:14:31 +0200
Subject: [PATCH 1/2] tests: use the nobody user's group as the default group 
id test

* tests/chroot/credentials: Use the group id, not its name.
* tests/test-lib.sh (NON_ROOT_GROUP): Use the nobody user's group in
place of nogroup.
---
 tests/chroot/credentials |2 +-
 tests/test-lib.sh|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/chroot/credentials b/tests/chroot/credentials
index 58c098f..f200f14 100755
--- a/tests/chroot/credentials
+++ b/tests/chroot/credentials
@@ -37,7 +37,7 @@ test $(chroot --userspec=$NON_ROOT_USERNAME:$NON_ROOT_GROUP 
/ whoami) != root
 || fail=1
 
 # Verify that there are no additional groups.
-test $(chroot --userspec=$NON_ROOT_USERNAME:$NON_ROOT_GROUP 
--groups=$NON_ROOT_GROUP / id -nG)\
+test $(chroot --userspec=$NON_ROOT_USERNAME:$NON_ROOT_GROUP 
--groups=$NON_ROOT_GROUP / id -G)\
 = $NON_ROOT_GROUP || fail=1
 
 # Verify that when specifying only the user name we get the current
diff --git a/tests/test-lib.sh b/tests/test-lib.sh
index d99e3a9..9797b55 100644
--- a/tests/test-lib.sh
+++ b/tests/test-lib.sh
@@ -209,7 +209,7 @@ require_root_()
 {
   uid_is_privileged_ || skip_test_ must be run as root
   NON_ROOT_USERNAME=${NON_ROOT_USERNAME=nobody}
-  NON_ROOT_GROUP=${NON_ROOT_GROUP=nobody}
+  NON_ROOT_GROUP=${NON_ROOT_GROUP=$(id -g $NON_ROOT_USERNAME)}
 }
 
 skip_if_root_() { uid_is_privileged_  skip_test_ must be run as non-root; }
-- 
1.6.3.3


From e892d0d2155dab81ded428e0c0d04d91febe9b3c Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Sat, 4 Jul 2009 10:25:03 +0200
Subject: [PATCH 2/2] tests: refactor code to use require_proc_pid_status_

* tests/tail-2/tail-n0f: Read the process status using the test-lib.sh
require_proc_pid_status_ function.
---
 tests/tail-2/tail-n0f |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/tests/tail-2/tail-n0f b/tests/tail-2/tail-n0f
index 322fddc..fce7ed1 100755
--- a/tests/tail-2/tail-n0f
+++ b/tests/tail-2/tail-n0f
@@ -40,9 +40,7 @@ for file in empty nonempty; do
 tail --sleep=4 -${c_or_n} 0 -f $file 
 pid=$!
 sleep .5
-set _ `sed -n '/^State:[]*\([^  ]\)/s//\1/p' /proc/$pid/status`
-shift # Remove the leading `_'.
-state=$1
+state=$(get_process_status_ $pid)
 case $state in
   S*) ;;
   *) echo $0: process in unexpected state: $state 12; fail=1 ;;
-- 
1.6.3.3



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: two new chroot bugs

[Jim Meyering]

Giuseppe Scrivano wrote:
 Hi Jim,

 Jim Meyering j...@meyering.net writes:

 From cfe8e7a0001a10d4deceb6065134fe8c402d0368 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@redhat.com
 Date: Thu, 28 May 2009 22:36:05 +0200
 Subject: [PATCH 1/4] tests: use nobody as the default group name in chroot 
 test

 the nobody group is not present on all systems, for example on Debian
 it is nogroup so IMHO it is better to find it at runtime using the
 nobody user's group.

 The second patch is just a small refactoring.

Thanks!
I've pushed both.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

two new chroot bugs

[Jim Meyering]

Eric Blake wrote:
 According to Jim Meyering on 5/26/2009 7:21 AM:
 Merged and pushed.
 Thanks again.

 Would it be worth starting to patch the testsuite to replace 'setuidgid -g
 list usr cmd arg' with 'chroot --user usr --groups=list / cmd arg' in
 order to give this feature more exposure and reduce our dependence on
 uninstalled apps?

Yes.  It would be good to get more coverage for installed tools.

However, I've just noticed that the new code in chroot.c needs work.

Two problems:
  - set*ID failure did not evoke non-zero exit
  - chroot --u=N / id -a currently uses gid uninitialized
i.e., when --userspec=USER (without :GROUP)
Same for --u=:1 (i.e, group ID with no user-ID)

$ sudo ./chroot --u=0 / id -g
3496015512

Here are patches, for review.
I'll add tests tomorrow.

From 63a1039e21fbf127e052f1b4d80176e3a2386d2a Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 27 May 2009 22:06:04 +0200
Subject: [PATCH] chroot: set-*-ID failure must provoke nonzero exit before 
execvp

* src/chroot.c (main): Exit upon set-group-ID or set-user-ID failure.
---
 src/chroot.c |   21 ++---
 1 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/chroot.c b/src/chroot.c
index 788a1fc..ab35944 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -207,6 +207,7 @@ main (int argc, char **argv)
   char *user;
   char *group;
   char const *err = parse_user_spec (userspec, uid, gid, user, group);
+  unsigned int fail = 0;

   if (err)
 error (EXIT_FAILURE, errno, %s, err);
@@ -214,14 +215,28 @@ main (int argc, char **argv)
   free (user);
   free (group);

+  /* Attempt to set all three: supplementary groups, group ID, user ID.
+ Diagnose any failures.  If any have failed, exit before execvp.  */
   if (groups  set_additional_groups (groups))
-error (0, errno, _(failed to set additional groups));
+{
+  error (0, errno, _(failed to set additional groups));
+  ++fail;
+}

   if (gid  setgid (gid))
-error (0, errno, _(failed to set group-ID));
+{
+  error (0, errno, _(failed to set group-ID));
+  ++fail;
+}

   if (uid  setuid (uid))
-error (0, errno, _(failed to set user-ID));
+{
+  error (0, errno, _(failed to set user-ID));
+  ++fail;
+}
+
+  if (fail)
+exit (EXIT_FAILURE);
 }

   /* Execute the given command.  */
--
1.6.3.1.268.g94d6d1

From 6752c02be6bc760e92687e5ae71e93513f5b84da Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 27 May 2009 23:06:15 +0200
Subject: [PATCH] chroot: don't set bogus user-ID or group-ID for --u=U or --u=:G

* src/chroot.c (main): Initialize both uid and gid.  To -1.
This also allows one to set the primary group-ID to 0, in case
it's not that already.
---
 src/chroot.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/chroot.c b/src/chroot.c
index ab35944..8bc4e59 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -202,8 +202,8 @@ main (int argc, char **argv)

   if (userspec)
 {
-  uid_t uid;
-  gid_t gid;
+  uid_t uid = -1;
+  gid_t gid = -1;
   char *user;
   char *group;
   char const *err = parse_user_spec (userspec, uid, gid, user, group);
@@ -223,13 +223,13 @@ main (int argc, char **argv)
   ++fail;
 }

-  if (gid  setgid (gid))
+  if (gid != (gid_t) -1  setgid (gid))
 {
   error (0, errno, _(failed to set group-ID));
   ++fail;
 }

-  if (uid  setuid (uid))
+  if (uid != (uid_t) -1  setuid (uid))
 {
   error (0, errno, _(failed to set user-ID));
   ++fail;
--
1.6.3.1.268.g94d6d1


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: two new chroot bugs

[Jim Meyering]

Jim Meyering wrote:
...
 Here are patches, for review.
 I'll add tests tomorrow.

That latter log wasn't complete.

 Subject: [PATCH] chroot: don't set bogus user-ID or group-ID for --u=U or 
 --u=:G

 * src/chroot.c (main): Initialize both uid and gid.  To -1.
 This also allows one to set the primary group-ID to 0, in case
 it's not that already.

Here's what I have, now:

chroot: don't set bogus user-ID or group-ID for --u=U: or --u=:G

* src/chroot.c (main): Initialize both uid and gid.  To -1.
This also allows one to set the user-ID or primary group-ID to 0,
in case it's not that already.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] Fix arpa_inet bugs found when installing coreutils 7.2 on Solaris 8.

[Paul Eggert]

I installed the following patch to gnulib, to fix the following
symptoms when trying to build coreutils 7.2 on Solaris 8:

inet_ntop.c:73: error: conflicting types for 'inet_ntop'
/usr/include/arpa/inet.h:55: error: previous declaration of 'inet_ntop' was here
make[4]: *** [inet_ntop.o] Error 1

-

* lib/arpa_inet.in.h (inet_ntop): Define to rpl_inet_ntop when
we implement it, to avoid colliding with Solaris 8's incompatible
declaration of the function (Solaris 8 lacks 'restrict').
(inet_pton): Likewise.
* modules/arpa_inet (arpa/inet.h): Depend on arpa_inet.in.h.
---
 ChangeLog  |8 
 lib/arpa_inet.in.h |8 
 modules/arpa_inet  |2 +-
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9708976..5662328 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2009-04-02  Paul Eggert  egg...@cs.ucla.edu
 
+   Fix bugs found when installing coreutils 7.2 on Solaris 8.
+
+   * lib/arpa_inet.in.h (inet_ntop): Define to rpl_inet_ntop when
+   we implement it, to avoid colliding with Solaris 8's incompatible
+   declaration of the function (Solaris 8 lacks 'restrict').
+   (inet_pton): Likewise.
+   * modules/arpa_inet (arpa/inet.h): Depend on arpa_inet.in.h.
+
* modules/fnmatch (Depends-on): Add mbsrtowcs, to fix a porting
problem to Solaris 8 encountered with coreutils 7.2, which
resulted in a message fnmatch.c:292: warning: passing argument 4
diff --git a/lib/arpa_inet.in.h b/lib/arpa_inet.in.h
index 315d966..d7b79b5 100644
--- a/lib/arpa_inet.in.h
+++ b/lib/arpa_inet.in.h
@@ -43,7 +43,8 @@ extern C {
 #endif
 
 #if @GNULIB_INET_NTOP@
-# if !...@have_decl_inet_ntop@
+# undef inet_ntop
+# define inet_ntop rpl_inet_ntop
 /* Converts an internet address from internal format to a printable,
presentable format.
AF is an internet address family, such as AF_INET or AF_INET6.
@@ -61,7 +62,6 @@ extern C {
http://www.opengroup.org/susv3xsh/inet_ntop.html.  */
 extern const char *inet_ntop (int af, const void *restrict src,
  char *restrict dst, socklen_t cnt);
-# endif
 #elif defined GNULIB_POSIXCHECK
 # undef inet_ntop
 # define inet_ntop(af,src,dst,cnt) \
@@ -71,9 +71,9 @@ extern const char *inet_ntop (int af, const void *restrict 
src,
 #endif
 
 #if @GNULIB_INET_PTON@
-# if !...@have_decl_inet_pton@
+# undef inet_pton
+# define inet_pton rpl_inet_pton
 extern int inet_pton (int af, const char *restrict src, void *restrict dst);
-# endif
 #elif defined GNULIB_POSIXCHECK
 # undef inet_pton
 # define inet_pton(af,src,dst) \
diff --git a/modules/arpa_inet b/modules/arpa_inet
index 3691fd5..d799403 100644
--- a/modules/arpa_inet
+++ b/modules/arpa_inet
@@ -19,7 +19,7 @@ BUILT_SOURCES += $(ARPA_INET_H)
 
 # We need the following in order to create arpa/inet.h when the system
 # doesn't have one.
-arpa/inet.h:
+arpa/inet.h: arpa_inet.in.h
@MKDIR_P@ arpa
rm -f $...@-t $@
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
-- 
1.6.2.1



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs!

[James Youngman]

On Wed, Apr 1, 2009 at 1:41 AM, Henry Purvis golfer81...@yahoo.com wrote:

 Hi, um.my name is henry and there is a bug on an application I have (from 
 cydia) and I typed in iPod --help on 'terminal' and it said to contact you 
 guys to say that there was a bug.so could you please get it fixed? PLEASE!

Could you let us know exactly what you typed and what the output was?
  The best thing would be to cut and paste all the text.

Thanks,
James.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Bugs!

[Henry Purvis]

Hi, um.my name is henry and there is a bug on an application I have (from 
cydia) and I typed in iPod --help on 'terminal' and it said to contact you 
guys to say that there was a bug.so could you please get it fixed? PLEASE!

  Thank you,
   
 Henry




  



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Multiple bugs and problems

[Jen Donier]

We have been working with Michael LeBlanc at Xandros Support and have had
one problem after another with the new Xandros 4 which we purchased in
December and installed. See details below.

Hi Michael  here is the update so far;
in regards to the .swp file.   We deleted it by thinking we could get it
back by the commands.  It did not come back though we followed what you
said.

vaio:~# swapoff-a

bash: swapoff-a: command not found

vaio:~# swapon-a

bash: swapon-a: command not found

vaio:~# swapoff -a

vaio:~# swapon -a

swapon: cannot stat /boot/linux-swap.swp: No such file or directory

vaio:~#

stat items:

swapon: cannot stat /boot/linux-swap.swp: No such file or directory

vaio:~# swapoff -a

vaio:~# swapon

usage: swapon [-hV]

swapon -a [-e] [-v]

swapon [-v] [-p priority] special|LABEL=volume_name ...

swapon [-s]

vaio:~# swapoff

usage: swapoff [-hV]

swapoff -a [-v]

swapoff [-v] special ...

vaio:~# swapon -e

usage: swapon [-hV]

swapon -a [-e] [-v]

swapon [-v] [-p priority] special|LABEL=volume_name ...

swapon [-s]

vaio:~# stat

stat: too few arguments

Try `stat --help' for more information.

vaio:~# stat --help

Usage: stat [OPTION] FILE...

Display file or filesystem status.

-f, --filesystem display filesystem status instead of file status

-c --format=FORMAT use the specified FORMAT instead of the default

-L, --dereference follow links

-t, --terse print the information in terse form

--help display this help and exit

--version output version information and exit

The valid format sequences for files (without --filesystem):

%A Access rights in human readable form

%a Access rights in octal

%B The size in bytes of each block reported by `%b'

%b Number of blocks allocated (see %B)

%D Device number in hex

%d Device number in decimal

%F File type

%f Raw mode in hex

%G Group name of owner

%g Group ID of owner

%h Number of hard links

%i Inode number

%N Quoted File name with dereference if symbolic link

%n File name

%o IO block size

%s Total size, in bytes

%T Minor device type in hex

%t Major device type in hex

%U User name of owner

%u User ID of owner

%X Time of last access as seconds since Epoch

%x Time of last access

%Y Time of last modification as seconds since Epoch

%y Time of last modification

%Z Time of last change as seconds since Epoch

%z Time of last change

Valid format sequences for file systems:

%a Free blocks available to non-superuser

%b Total data blocks in file system

%c Total file nodes in file system

%d Free file nodes in file system

%f Free blocks in file system

%i File System id in hex

%l Maximum length of filenames

%n File name

%s Optimal transfer block size

%T Type in human readable form

%t Type in hex


 Report bugs to bug-coreutils@gnu.org.

vaio:~#

Please note that the virus scannere seemed to work in the administrator
window; however it detected a virus in the boot/linux-swap.swp. It could
not repair but only quarentine. When deleated it was not able to be restored
as evidenced by the above quoted windows generated in administrative mode
and in the root console. Said virus was:DOS.Ramthes.655 and the user mode
found at least one virus :BAT.Haj.bsig. Both these viruses were in the
/boot/linux-swap.swp. The linux-swap.swp no longer exists. Security Suite
in the administrative mode shows all is well; however the user mode shows
the Security Suite as not ever completed a scan and will start a scan at odd
times and seems to always be scanning. Verbose check does not find any
problems and says scan okay for abnormalities.;

Joy told us to delete the virus in the swap.swp but when we did it took out
the file as well and it is not there any longer, what you told us has not
brought it back at all. .   There apparently is no disinfect system only
quarentine and delete which takes out the entire file.

One other issue apparently there is no Flash Player and never has been.
Not 9 or 10 all programs requiring a flashplayer all repeatedly say I need
flash player 9.  a couple only asked for 10.I think the xandros 4 sold
to us back in Late November, early December was not complete.  We have had
trouble on going.   We never had trouble with Xandros 3 other than it was
outdated and many programs on the net it was no longer working with
adequately.The gimp and photo shop is very hard to understand or use and
don't like it.  Also noticed the graphics most that were in 3 are not in 4
which is really disappointing as well.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Multiple bugs and problems

[Mike Frysinger]

On Friday 27 February 2009 21:54:55 Jen Donier wrote:
 We have been working with Michael LeBlanc at Xandros Support and have had
 one problem after another with the new Xandros 4 which we purchased in
 December and installed. See details below.

so you should keep working with Xandros.  nothing you showed here is relevant 
to the coreutils project.
-mike


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Old bugs in the man true man false

[Peter.Lawrey]

I apologise if this has been fixed already but we have an old version of
RedHat.

Both man true and man false state

DESCRIPTION
   These option names may not be abbreviated.

   --help display this help and exit

   --version
  output version information and exit

However both true and false ignore any options provided. They do not
support these options.

Solution: delete their mention from the man pages.
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Old bugs in the man true man false

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to peter.law...@barclayscapital.com on 2/20/2009 12:00 PM:
 However both true and false ignore any options provided. They do not
 support these options.
 
 Solution: delete their mention from the man pages.

Not a bug, but a misunderstanding on your part.  GNU coreutils' true and
false DO support options; in fact, the man page is generated from the
- --help option.

Did you read the rest of the man page?
 NOTE: your shell may have its own version of true, which usually
 supersedes the version described here.  Please refer to your
 shell's documentation for details about the options it supports.

And indeed, when compared to the bash builtin:

$ true --help
$ /bin/true --help
Usage: /bin/true [ignored command line arguments]
  or:  /bin/true OPTION
...

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmfNHIACgkQ84KuGfSFAYApJgCffUUDrJajsJZ2yFlFj9OVzRjY
DOoAnA9gNnFCW4wSstlWtji5QSSA5DhF
=gKVK
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Mike Frysinger]

On Wednesday 11 February 2009 02:04:11 Jim Meyering wrote:
 Mike Frysinger vap...@gentoo.org wrote:
 ...

   i was thinking a common change to the version-etc module to add a
   packager field rather than having every package out there allow
   people to tweak PACKAGE_NAME.  what do you think of that ?
 
  Sounds sensible.
  The question then becomes whether to change version_etc
  (probably not), or to add a new interface that takes
  the additional parameter.
 
  Does anyone prefer to add a parameter to version_etc?
 
  i prefer modifying version_etc as this would go a long way in
  acknowledging that end users are not the main consumer of software.  they
  get it by way of distro packagers.
 
  however, i dont think it needs to modify the function prototype ?  if the
  m4 set up a PACKAGE_PACKAGER define, the version_etc module could use
  that.  if the person running configure doesnt specify the
  --with-packager=... option, then  it wont show up in the output.

 That sounds even better.
 Post the patch!

one last question: where to put the string ?
$ ls --version
ls (GNU coreutils) 6.12
Packaged by ... some distro string here ...
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Stallman and David MacKenzie.

and if no packager option was used, then that Packaged by line will be 
entirely omitted ...
-mike


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Karl Berry]

$ ls --version
ls (GNU coreutils) 6.12
Packaged by ... some distro string here ...

That looks like the right place to me.  I'd be tempted to put a blank
line between Packaged by ... and Copyright 

Please include a url to your downstream coreutils package in the distro string.

This seems fine, but can we also include the information in --help,
which is what we did when we amended the coding standards a few days
ago?  For instance, grep 2.5.4 --help ends with:

  Report bugs to: bug-g...@gnu.org
  GNU Grep home page: http://www.gnu.org/software/grep/
  General help using GNU software: http://www.gnu.org/gethelp/

I suggest having another line such as
  Gentoo Grep home page and bug reports: http://whatever
between Report bugs to and GNU Grep home page.

Perhaps even the address in Report bugs to: should be changed also.

Perhaps that same line should be used in --version and --help.  I assume
we're trying to get across the same information.

karl



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Mike Frysinger]

On Wednesday 11 February 2009 13:31:57 Karl Berry wrote:
 $ ls --version
 ls (GNU coreutils) 6.12
 Packaged by ... some distro string here ...

 That looks like the right place to me.  I'd be tempted to put a blank
 line between Packaged by ... and Copyright 

the attached patch does this

 Please include a url to your downstream coreutils package in the distro
 string.

 This seems fine, but can we also include the information in --help,
 which is what we did when we amended the coding standards a few days
 ago?  For instance, grep 2.5.4 --help ends with:

   Report bugs to: bug-g...@gnu.org
   GNU Grep home page: http://www.gnu.org/software/grep/
   General help using GNU software: http://www.gnu.org/gethelp/

 I suggest having another line such as
   Gentoo Grep home page and bug reports: http://whatever
 between Report bugs to and GNU Grep home page.

 Perhaps even the address in Report bugs to: should be changed also.

 Perhaps that same line should be used in --version and --help.  I assume
 we're trying to get across the same information.

so should this be one or two new options ?
--with-packager=Gentoo
--with-packager-version=some patchset version info
--with-packager-bugurl=http://bugs.gentoo.org/;

$ ls --version
ls (GNU coreutils) 6.12
Packaged by Gentoo (some patchset version info)
..

$ ls --help
...
Report bugs to bug-coreutils@gnu.org.
GNU coreutils home page: http://www.gnu.org/software/coreutils/
Gentoo bug reporting page: http://bugs.gentoo.org/

with the last line looking something like:
%s bug reporting page: %s\n, PACKAGE_PACKAGER, PACKAGE_PACKAGER_BUGURL,
-mike
diff --git a/lib/version-etc.c b/lib/version-etc.c
index 2258c2e..e2daa0d 100644
--- a/lib/version-etc.c
+++ b/lib/version-etc.c
@@ -59,6 +59,10 @@ version_etc_va (FILE *stream,
   else
 fprintf (stream, %s %s\n, package, version);
 
+#ifdef PACKAGE_PACKAGER
+  fprintf (stream, Packaged by %s\n, PACKAGE_PACKAGER);
+#endif
+
   /* TRANSLATORS: Translate (C) to the copyright symbol
  (C-in-a-circle), if this symbol is available in the user's
  locale.  Otherwise, do not translate (C); leave it as-is.  */
diff --git a/m4/version-etc.m4 b/m4/version-etc.m4
new file mode 100644
index 000..eecbc47
--- /dev/null
+++ b/m4/version-etc.m4
@@ -0,0 +1,19 @@
+# version-etc.m4 serial 1
+# Copyright (C) 2009 Free Software Foundation, Inc.
+# This file is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN([gl_VERSION_ETC],
+[dnl
+  AC_ARG_WITH([packager],
+[AS_HELP_STRING([--with-packager],
+		[String identifying the packager of this software])],
+[dnl
+  case $withval in
+	yes|no) ;;
+	*)  AC_DEFINE_UNQUOTED([PACKAGE_PACKAGER], [$withval],
+   [Packager identification]);;
+  esac
+])
+])
diff --git a/modules/version-etc b/modules/version-etc
index aac2311..589c8c9 100644
--- a/modules/version-etc
+++ b/modules/version-etc
@@ -4,12 +4,14 @@ Print --version and bug-reporting information in a consistent format.
 Files:
 lib/version-etc.h
 lib/version-etc.c
+m4/version-etc.m4
 
 Depends-on:
 gettext-h
 stdarg
 
 configure.ac:
+gl_VERSION_ETC
 
 Makefile.am:
 lib_SOURCES += version-etc.h version-etc.c
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Jim Meyering]

Mike Frysinger vap...@gentoo.org wrote:
 On Friday 06 February 2009 01:13:13 Jim Meyering wrote:
 Pádraig Brady p...@draigbrady.com wrote:
  Mike Frysinger wrote:
  On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
  Mike Frysinger vap...@gentoo.org wrote:
  On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
  What distribution are you using (I'm guessing Fedora 10).
  Distributions that patch coreutils really should
  modify the version string accordingly.
 
  if coreutils wants distros to do that, it should really facilitate
  things. the way gcc does it now with gcc-4.3+ is a pretty good
  standard: ./configure ... --with-pkgversion=some vendor/distro
  string ...
 
  Good idea.
  Patches welcome.
 
  do you want the gcc method or a new method ?
 
  gcc does:
   - running `gcc --version` outputs:
gcc (GCC) 4.3.3
   - running `configure --with-pkgversion=PKG` changes it to:
gcc (PKG) 4.3.3
 
  so the coreutils analog would be:
   - running `ls --version` outputs:
ls (GNU coreutils) 6.12
   - running `configure --with-pkgversion=PKG` changes it to:
ls (PKG) 6.12
 
  that way we could end up with:
ls (Gentoo p1.0) 6.12
  -mike
 
  Well I'd be a little worried about putting numbers
  in there in case scripts parsing output from --version got confused
  (like our bootstrap script for example).
 
  How about:
 
  ls (Gentoo coreutils) 6.12
  ls (Red Hat coreutils) 6.12
  ...
 
  Or perhaps we could use the wget example on my fedora distro:
  GNU Wget 1.10.2 (Red Hat modified)

 Mike, if you're preparing a patch, please
 put the distro information inside the parentheses,
 and after GNU coreutils, i.e., do something like this:

  ls (GNU coreutils, Gentoo p1.0) 6.12

 Whether it has distro-specific patches doesn't change
 the fact that it's part of the GNU coreutils package,
 so it should continue to say that.

 i was thinking a common change to the version-etc module to add a packager
 field rather than having every package out there allow people to tweak
 PACKAGE_NAME.  what do you think of that ?

Sounds sensible.
The question then becomes whether to change version_etc
(probably not), or to add a new interface that takes
the additional parameter.

Does anyone prefer to add a parameter to version_etc?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Jim Meyering]

Mike Frysinger vap...@gentoo.org wrote:
...
  i was thinking a common change to the version-etc module to add a
  packager field rather than having every package out there allow people
  to tweak PACKAGE_NAME.  what do you think of that ?

 Sounds sensible.
 The question then becomes whether to change version_etc
 (probably not), or to add a new interface that takes
 the additional parameter.

 Does anyone prefer to add a parameter to version_etc?

 i prefer modifying version_etc as this would go a long way in acknowledging
 that end users are not the main consumer of software.  they get it by way of
 distro packagers.

 however, i dont think it needs to modify the function prototype ?  if the m4
 set up a PACKAGE_PACKAGER define, the version_etc module could use that.  if
 the person running configure doesnt specify the --with-packager=... option,
 then  it wont show up in the output.

That sounds even better.
Post the patch!


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Mike Frysinger]

On Friday 06 February 2009 01:13:13 Jim Meyering wrote:
 Pádraig Brady p...@draigbrady.com wrote:
  Mike Frysinger wrote:
  On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
  Mike Frysinger vap...@gentoo.org wrote:
  On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
  What distribution are you using (I'm guessing Fedora 10).
  Distributions that patch coreutils really should
  modify the version string accordingly.
 
  if coreutils wants distros to do that, it should really facilitate
  things. the way gcc does it now with gcc-4.3+ is a pretty good
  standard: ./configure ... --with-pkgversion=some vendor/distro
  string ...
 
  Good idea.
  Patches welcome.
 
  do you want the gcc method or a new method ?
 
  gcc does:
   - running `gcc --version` outputs:
 gcc (GCC) 4.3.3
   - running `configure --with-pkgversion=PKG` changes it to:
 gcc (PKG) 4.3.3
 
  so the coreutils analog would be:
   - running `ls --version` outputs:
 ls (GNU coreutils) 6.12
   - running `configure --with-pkgversion=PKG` changes it to:
 ls (PKG) 6.12
 
  that way we could end up with:
 ls (Gentoo p1.0) 6.12
  -mike
 
  Well I'd be a little worried about putting numbers
  in there in case scripts parsing output from --version got confused
  (like our bootstrap script for example).
 
  How about:
 
  ls (Gentoo coreutils) 6.12
  ls (Red Hat coreutils) 6.12
  ...
 
  Or perhaps we could use the wget example on my fedora distro:
  GNU Wget 1.10.2 (Red Hat modified)

 Mike, if you're preparing a patch, please
 put the distro information inside the parentheses,
 and after GNU coreutils, i.e., do something like this:

   ls (GNU coreutils, Gentoo p1.0) 6.12

 Whether it has distro-specific patches doesn't change
 the fact that it's part of the GNU coreutils package,
 so it should continue to say that.

i was thinking a common change to the version-etc module to add a packager 
field rather than having every package out there allow people to tweak 
PACKAGE_NAME.  what do you think of that ?
-mike


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Pádraig Brady]

Mike Frysinger wrote:
 On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
 Mike Frysinger vap...@gentoo.org wrote:
 On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
 What distribution are you using (I'm guessing Fedora 10).
 Distributions that patch coreutils really should
 modify the version string accordingly.
 if coreutils wants distros to do that, it should really facilitate
 things. the way gcc does it now with gcc-4.3+ is a pretty good standard:
 ./configure ... --with-pkgversion=some vendor/distro string ...
 Good idea.
 Patches welcome.
 
 do you want the gcc method or a new method ?
 
 gcc does:
  - running `gcc --version` outputs:
   gcc (GCC) 4.3.3
  - running `configure --with-pkgversion=PKG` changes it to:
   gcc (PKG) 4.3.3
 
 so the coreutils analog would be:
  - running `ls --version` outputs:
   ls (GNU coreutils) 6.12
  - running `configure --with-pkgversion=PKG` changes it to:
   ls (PKG) 6.12
 
 that way we could end up with:
   ls (Gentoo p1.0) 6.12
 -mike
 

Well I'd be a little worried about putting numbers
in there in case scripts parsing output from --version got confused
(like our bootstrap script for example).

How about:

ls (Gentoo coreutils) 6.12
ls (Red Hat coreutils) 6.12
...

Or perhaps we could use the wget example on my fedora distro:
GNU Wget 1.10.2 (Red Hat modified)

cheers,
Pádraig.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Pádraig Brady]

Mike Frysinger wrote:
 On Thursday 05 February 2009 20:03:36 Pádraig Brady wrote:
 Mike Frysinger wrote:
 On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
 Mike Frysinger vap...@gentoo.org wrote:
 On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
 What distribution are you using (I'm guessing Fedora 10).
 Distributions that patch coreutils really should
 modify the version string accordingly.
 if coreutils wants distros to do that, it should really facilitate
 things. the way gcc does it now with gcc-4.3+ is a pretty good
 standard: ./configure ... --with-pkgversion=some vendor/distro string
 ...
 Good idea.
 Patches welcome.
 do you want the gcc method or a new method ?

 gcc does:
  - running `gcc --version` outputs:
 gcc (GCC) 4.3.3
  - running `configure --with-pkgversion=PKG` changes it to:
 gcc (PKG) 4.3.3

 so the coreutils analog would be:
  - running `ls --version` outputs:
 ls (GNU coreutils) 6.12
  - running `configure --with-pkgversion=PKG` changes it to:
 ls (PKG) 6.12

 that way we could end up with:
 ls (Gentoo p1.0) 6.12
 Well I'd be a little worried about putting numbers
 in there in case scripts parsing output from --version got confused
 (like our bootstrap script for example).
 
 it's useful where distros version their own package.  with many packages in 
 Gentoo, we have patchsets which have their own version number.  being able to 
 know without a doubt what patchset is in use can be valuable.
 
 would scripts really be weirded out ?  i'd imagine they'd simply grab the 
 last 
 component when it comes to whitespace rather than anything else ...
 ls --version | awk '{print $NF;exit}'

Well our bootstrap script would break with it currently.
But don't worry about it if it's useful.
We can update the match to handle this case if required
(while being compatible with perl --version for example).

 
 How about:

 ls (Gentoo coreutils) 6.12
 ls (Red Hat coreutils) 6.12
 ...
 
 so you want a --with-distro=DISTRO which replaces GNU with some other 
 random string.  how about taking it a step further and extending the gnulib 
 version-etc module ?  if it included a m4 file which adds a --with-
 packager=... option and the source file printed that out, then all GNU 
 projects using version-etc would get this functionality for free.

Which could be enabled per project. Seems sensible.

 
 Or perhaps we could use the wget example on my fedora distro:
 GNU Wget 1.10.2 (Red Hat modified)
 
 that's just a random patch redhat themselves apply ... i think looking at 
 packages that themselves support arbitrary markings is better.

agreed. I was really referring to the version string format here.

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Jim Meyering]

Pádraig Brady p...@draigbrady.com wrote:
 Mike Frysinger wrote:
 On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
 Mike Frysinger vap...@gentoo.org wrote:
 On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
 What distribution are you using (I'm guessing Fedora 10).
 Distributions that patch coreutils really should
 modify the version string accordingly.
 if coreutils wants distros to do that, it should really facilitate
 things. the way gcc does it now with gcc-4.3+ is a pretty good standard:
 ./configure ... --with-pkgversion=some vendor/distro string ...
 Good idea.
 Patches welcome.

 do you want the gcc method or a new method ?

 gcc does:
  - running `gcc --version` outputs:
  gcc (GCC) 4.3.3
  - running `configure --with-pkgversion=PKG` changes it to:
  gcc (PKG) 4.3.3

 so the coreutils analog would be:
  - running `ls --version` outputs:
  ls (GNU coreutils) 6.12
  - running `configure --with-pkgversion=PKG` changes it to:
  ls (PKG) 6.12

 that way we could end up with:
  ls (Gentoo p1.0) 6.12
 -mike


 Well I'd be a little worried about putting numbers
 in there in case scripts parsing output from --version got confused
 (like our bootstrap script for example).

 How about:

 ls (Gentoo coreutils) 6.12
 ls (Red Hat coreutils) 6.12
 ...

 Or perhaps we could use the wget example on my fedora distro:
 GNU Wget 1.10.2 (Red Hat modified)

Mike, if you're preparing a patch, please
put the distro information inside the parentheses,
and after GNU coreutils, i.e., do something like this:

ls (GNU coreutils, Gentoo p1.0) 6.12

Whether it has distro-specific patches doesn't change
the fact that it's part of the GNU coreutils package,
so it should continue to say that.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bugs in unexpand(1) version 6.10

[Mike Frysinger]

On Tuesday 03 February 2009 03:28:58 Jim Meyering wrote:
 Mike Frysinger vap...@gentoo.org wrote:
  On Friday 23 January 2009 09:35:54 Pádraig Brady wrote:
  What distribution are you using (I'm guessing Fedora 10).
  Distributions that patch coreutils really should
  modify the version string accordingly.
 
  if coreutils wants distros to do that, it should really facilitate
  things. the way gcc does it now with gcc-4.3+ is a pretty good standard:
  ./configure ... --with-pkgversion=some vendor/distro string ...

 Good idea.
 Patches welcome.

do you want the gcc method or a new method ?

gcc does:
 - running `gcc --version` outputs:
gcc (GCC) 4.3.3
 - running `configure --with-pkgversion=PKG` changes it to:
gcc (PKG) 4.3.3

so the coreutils analog would be:
 - running `ls --version` outputs:
ls (GNU coreutils) 6.12
 - running `configure --with-pkgversion=PKG` changes it to:
ls (PKG) 6.12

that way we could end up with:
ls (Gentoo p1.0) 6.12
-mike


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils