Bug#1041588: bug#64773: grep 3.11 -r on 100000+ files fails with "Operation not supported"

[Jim Meyering]

On Fri, Jul 21, 2023 at 4:38 PM Paul Eggert  wrote:
> To fix just this bug (as opposed to the other Gnulib-related bugs that
> may be lurking) try applying the attached Gnulib patch to a grep 3.11
> tarball.
>
> Closing the debbugs.gnu.org bug report, as the bug has been fixed upstream.

Thanks for reporting that.
I've just pushed the following, adding a NEWS entry for the 3.11 bug and a test.
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=v3.11-12-gd1c3fbe

Bug#684713: support for partitioned linux md devices

[Jim Meyering]

Miquel van Smoorenburg wrote:
 I've also filed this as a debian bugreport,
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684713

 Linux md raid array devices come in two flavours: partionable
 (/dev/md_d0) and non-partitionable (/dev/md0). Or at least,
 that used to be the case, until kernel 2.6.28 where the two have
 been consolidated. Now all md devices can have partitions.

 However, there is one minor oversight/bug in the kernel: the
 sysfs range key is still set to 1 for md devices. That means
 libparted thinks that it's not possible to partition that device,
 when in fact it is.

 The attached patch reckognizes that situation: if running on
 a kernel = 2.6.28, and the device is a PED_DEVICE_MD, and the
 sysfs 'range' key is set to '1', _device_get_partition_range()
 returns MAX_NUM_PARTS instead.

 Mike.

 Index: parted-2.3/libparted/arch/linux.c
 ===
 --- parted-2.3.orig/libparted/arch/linux.c2010-05-10 10:57:54.0 
 +
 +++ parted-2.3/libparted/arch/linux.c 2012-08-05 13:24:14.449768577 +
 @@ -2415,6 +2415,11 @@
  ok = fscanf(fp, %d, range) == 1;
  fclose(fp);

 + /* starting at 2.6.28 partitions are OK but range doesn't show it */
 + if (dev-type == PED_DEVICE_MD  range == 1 
 + _get_linux_version() = KERNEL_VERSION (2,6,28))
 + ok = 0;
 +
  /* (range = 0) is none sense.*/
  return ok  range  0 ? range : MAX_NUM_PARTS;
  }

Thanks for the patch.
FYI, Petr Uzel made the following change in v3.0-61-gca97da9:


http://anonscm.debian.org/gitweb/?p=parted/parted.git;a=commitdiff;h=ca97da905bd21f2a4371f4717f7c46a936af6b2c

commit ca97da905bd21f2a4371f4717f7c46a936af6b2c
Author: Petr Uzel petr.u...@suse.cz
Date:   Sat Nov 26 15:45:08 2011 +0100

libparted: use ext_range to find out largest possible partition

Parted uses /sys/block/DEV/range file to find out how many partitions
can the blockdevice hold and uses this number in its algorithm
for informing the kernel about modified partitions. This works
fine for most devices, however, it fails on partitionable MD arrays,
because these have 1 in range file. Using ext_range should be safer
and work for all devices.

* libparted/arch/linux.c (_device_get_partition_range): Use
/sys/block/DEV/ext_range instead of range sysfs file
* NEWS: Mention the change.

Addresses: http://bugzilla.novell.com/567652

diff --git a/NEWS b/NEWS
index 566484c..5d8df35 100644
--- a/NEWS
+++ b/NEWS
@@ -38,6 +38,10 @@ GNU parted NEWS-*- 
outline -*-
   with an HFS or HFS+ signature, but with invalid -total_blocks and/or
   -block_size values.

+  parted now uses ext_range device sysfs attribute to determine maximum number
+  of partitions the device can hold.  With this change, parted now correctly
+  informs kernel about new partitions on partitionable MD RAID devices.
+
 ** Changes in behavior

   parted: mkpart command has changed semantics with regard to specifying end
diff --git a/libparted/arch/linux.c b/libparted/arch/linux.c
index ab3d904..1da3343 100644
--- a/libparted/arch/linux.c
+++ b/libparted/arch/linux.c
@@ -2484,7 +2484,7 @@ _loop_get_partition_range(PedDevice const* dev)

 /*
  * The number of partitions that a device can have depends on the kernel.
- * If we don't find this value in /sys/block/DEV/range, we will use our own
+ * If we don't find this value in /sys/block/DEV/ext_range, we will use our own
  * value.
  */
 static unsigned int
@@ -2495,7 +2495,7 @@ _device_get_partition_range(PedDevice const* dev)
 return _loop_get_partition_range(dev);

 int range;
-bool ok = _sysfs_int_entry_from_dev(dev, range, range);
+bool ok = _sysfs_int_entry_from_dev(dev, ext_range, range);

 return ok  range  0 ? range : MAX_NUM_PARTS;
 }


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#669555: coreutils: FTBFS: env: setfacl: No such file or directory

[Jim Meyering]

Lucas Nussbaum wrote:
 Source: coreutils
 Version: 8.13-3.1
 Severity: serious
 Tags: wheezy sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20120419 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part:

Hi Lucas,

Thanks for the report.
The failure is unrelated to env/setfacl.
In general, you need to search for FAIL: and (within that block) fail=1:

This test is ensuring that sort works even when it requires every single
available file descriptor.  If something about sort or one of the programs
it execs happens to keep just one extra file descriptor open, then this
test will fail.

The following upstream fix to the failing test script,
v8.14-38-g91a5bad may solve this problem:

commit 91a5badc7b8b96916147f28b1d094af98efa5aa7
Author: Paul Eggert egg...@cs.ucla.edu
Date:   Sat Nov 12 00:20:01 2011 -0800

* tests/misc/sort-continue: Port to Fedora 15.

Redirect with the shell command, not in a separate 'exec'.
Without this patch, Fedora 15 x86-64 /bin/sh (i.e., Bash 4.2.10)
complained about running out of file descriptors in the shell.


...
 FAIL: misc/sort-continue (exit: 1)
 ==
...
 + tee -a in
 + echo 31
 + ulimit -n 6
 + exec
 ./misc/sort-continue: redirection error: cannot duplicate fd: Invalid 
 argument
 ./misc/sort-continue: line 33: /dev/null: Invalid argument
 + sort -n -m __test.1 __test.10 __test.11 __test.12 __test.13
 __test.14 __test.15 __test.16 __test.17 __test.18 __test.19 __test.2
 __test.20 __test.21 __test.22 __test.23 __test.24 __test.25 __test.26
 __test.27 __test.28 __test.29 __test.3 __test.30 __test.31 __test.4
 __test.5 __test.6 __test.7 __test.8 __test.9
 sort: open failed: __test.10: Too many open files
 + fail=1
 + echo 'file descriptor exhaustion not handled'
 file descriptor exhaustion not handled
 + tee -a in
 + echo 32
 + ulimit -n 6
 + exec
 ./misc/sort-continue: redirection error: cannot duplicate fd: Invalid 
 argument
 ./misc/sort-continue: line 42: 0: Invalid argument
 + sort -n -m __test.1 __test.10 __test.11 __test.12 __test.13
 __test.14 __test.15 __test.16 __test.17 __test.18 __test.19 __test.2
 __test.20 __test.21 __test.22 __test.23 __test.24 __test.25 __test.26
 __test.27 __test.28 __test.29 __test.3 __test.30 __test.31 __test.4
 __test.5 __test.6 __test.7 __test.8 __test.9 -
 + compare in out
 + diff -u in out
 + Exit 1
 + set +e
 + exit 1
 + exit 1
 + remove_tmp_
 + __st=1
 + cleanup_
 + :
 + cd /«PKGBUILDDIR»/tests
 + chmod -R u+rwx /«PKGBUILDDIR»/tests/gt-sort-continue.HX7W
 + rm -rf /«PKGBUILDDIR»/tests/gt-sort-continue.HX7W
 + exit 1



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#622182: FTBFS: test touch/now-owned-by-other fails

[Jim Meyering]

Mathias Brodala wrote:
 FAIL: misc/tail (exit: 1)
 =
...
 f-pipe-1.p...
 tail: test f-pipe-1.p: stderr mismatch, comparing f-pipe-1.p.E
 (actual) and f-pipe-1.p.3 (expected)
 *** f-pipe-1.p.E Sat Apr  9 22:58:08 2011
 --- f-pipe-1.p.3 Sat Apr  9 22:58:08 2011
 ***
 *** 1 
 - tail: cannot determine location of `standard input'. reverting to
 polling: Function not implemented
 --- 0 

Thanks.
However, that's nothing serious (certainly not grave).
Even if it were, how often does anyone run tail -f on a pipe?



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#622182: FTBFS: test touch/now-owned-by-other fails

[Jim Meyering]

Mathias Brodala wrote:

 Hi.

 Jim Meyering, 11.04.2011 09:13:
 Mathias Brodala wrote:
 FAIL: misc/tail (exit: 1)
 =
 ...
 f-pipe-1.p...
 tail: test f-pipe-1.p: stderr mismatch, comparing f-pipe-1.p.E
 (actual) and f-pipe-1.p.3 (expected)
 *** f-pipe-1.p.E   Sat Apr  9 22:58:08 2011
 --- f-pipe-1.p.3   Sat Apr  9 22:58:08 2011
 ***
 *** 1 
 - tail: cannot determine location of `standard input'. reverting to
 polling: Function not implemented
 --- 0 

 Thanks.
 However, that's nothing serious (certainly not grave).
 Even if it were, how often does anyone run tail -f on a pipe?

 The usual dmesg | tail -f comes into mind. ;-)

tail -f still works on pipes.

The test fails because it's printing a diagnostic
(when none was expected) when reverting from inotify-based
to the classic polling-based method.

 Aside from that I actually meant this report to be about the FTFBS issue
 alone since that pretty much makes the package unusable to me. If I
 can’t compile it, then I cannot make modifications.

Failing a single nit-picky test should not be seen as making
the entire 100+-program package unusable.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#579948: [parted-devel] Some debugging info

[Jim Meyering]

Colin Watson wrote:

 On Mon, Jun 14, 2010 at 08:40:12PM +0200, Karel Zak wrote:
 On Mon, Jun 14, 2010 at 01:06:09PM +0100, Colin Watson wrote:
  parted-devel, can anyone comment on this?  It seems to me that either
  (a) _get_lax_constraint should be using ped_alignment_any for its start
  alignment, rather than aligning to sectors * heads boundaries, or (b)
  Sun labels really and truly require cylinder alignment, in which case
  requests to use optimal alignment shouldn't be honoured.

 The begin of the partition has to be defined in cylinders:

 struct __attribute__ ((packed)) _SunRawPartition {
 u_int32_t   start_cylinder; /* where the part starts... 
 */
 u_int32_t   num_sectors;/* ...and it's length */
 };

 IMHO it does not make sense to use non-cylinder alignment here.

 In that case, I think that the sun part of
 723ea23c5df68cbe67d1f518ef484f4c77f516fa should be reverted.  CCing Hans
 since that was his change.


 From: Colin Watson cjwat...@ubuntu.com
 Date: Tue, 15 Jun 2010 19:49:40 +0100
 Subject: [PATCH] sun: revert implement disk flag operations

 This reverts the libparted/labels/sun.c part of
 723ea23c5df68cbe67d1f518ef484f4c77f516fa.  Sun disk labels do not appear
 to be able to handle non-cylinder alignment
 (http://bugs.debian.org/579948).

Thanks!  I've applied that.
However, since it would have made a test fail,
I first applied this change:


From a582ca642f4817dd02e65a3ecc55e951008969b2 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 26 Jun 2010 09:22:59 +0200
Subject: [PATCH] tests: adjust sun-partition-creating test to conform

* tests/t4000-sun-raid-type.sh: Adjust partition size so the
end falls on a cylinder boundary.
---
 tests/t4000-sun-raid-type.sh |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/t4000-sun-raid-type.sh b/tests/t4000-sun-raid-type.sh
index 5ef8ab4..853809e 100755
--- a/tests/t4000-sun-raid-type.sh
+++ b/tests/t4000-sun-raid-type.sh
@@ -26,7 +26,7 @@ ss=$sector_size_

 N=2000 # number of sectors
 dev=sun-disk-file
-exp=BYT;\n---:${N}s:file:$ss:$ss:sun:;\n1:0s:50s:51s
+exp=BYT;\n---:${N}s:file:$ss:$ss:sun:;\n1:0s:127s:128s
 test_expect_success \
 'create an empty file as a test disk' \
 'dd if=/dev/zero of=$dev bs=${ss}c count=$N 2 /dev/null'
@@ -38,7 +38,7 @@ test_expect_success 'check for empty output' 'compare out 
/dev/null'

 test_expect_success \
 'create a single partition' \
-'parted -s $dev unit s mkpart ext2 0s 50s  out 21'
+'parted -s $dev unit s mkpart ext2 0s 127s  out 21'
 test_expect_success 'check for empty output' 'compare out /dev/null'

 test_expect_success \
--
1.7.1.755.geb6f2



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#577095: grep: bracket expressions fails depending on the locale

[Jim Meyering]

Aníbal Monsalve Salazar wrote:
 I reproduced this bug, see below.

 grep --version
 GNU grep 2.6.3

 cat /tmp/a
 root:x:0:0:root:/root:/bin/bash
 anibal:x:1000:1000:Anibal Monsalve Salazar,,,:/home/anibal:/bin/bash
 Debian-exim:x:102:104::/var/spool/exim4:/bin/false
 ntp:x:106:108::/home/ntp:/bin/false

 grep -E '^[A-Z]' /tmp/a
 root:x:0:0:root:/root:/bin/bash
 Debian-exim:x:102:104::/var/spool/exim4:/bin/false
 ntp:x:106:108::/home/ntp:/bin/false

 grep -Ev '^[A-Z]' /tmp/a
 anibal:x:1000:1000:Anibal Monsalve Salazar,,,:/home/anibal:/bin/bash

Thanks for Cc'ing bug-grep, however this is not a bug in grep-2.6.3.
Rather, it demonstrates that grep-2.5.4-4 failed to honor your locale
settings.

As you noticed, what the [A-Z] range matches depends on your locale settings.
Run locale to print those settings.

In the C (aka POSIX) locale [A-Z] matches ASCII upper case ABC...Z,
but in many other locales it matches AbBbCc...Zz.
Demonstrate with this:

  $ for i in a A b B c C; do \
printf $i: ; echo $i | LC_ALL=en_US.UTF-8 grep -E '[A-Z]' || echo; done
  a:
  A: A
  b: b
  B: B
  c: c
  C: C

If you really want to match only the 26 ASCII upper case letters,
you can run grep in the C locale, even using that risky range notation:

  $ echo b | LC_ALL=C grep '[A-Z]'
  [Exit 1]
  $

However, it's better to avoid the '[A-Z]' range notation and to
prefer the '[[:upper:]]' character class.

Using the [[:CLASS_NAME:]] notation is essential if you also
want to match other (non-ASCII) upper case characters in your locale:

  $ echo É | LC_ALL=fr_FR.UTF-8 grep '[[:upper:]]'
  É

Using range notation is often not what you want:

  $ echo á | LC_ALL=fr_FR.UTF-8 grep '[A-F]'
  á



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548493: reassign to dash

[Jim Meyering]

retitle 548493 dash: don't read-uninitialized for \177 in a here-doc
reassign 548493 dash



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548493: [PATCH] don't read-uninitialized for \177 in a here-doc

[Jim Meyering]

It was indeed a bug in dash.
I tracked it down and wrote the patch below:

From 53924ce6da7fece91e57b7238e6aa81a4df636a5 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 28 Sep 2009 11:00:05 +0200
Subject: [PATCH] don't read-uninitialized for \177 in a here-doc

A DEL (0177, dec 127) byte in a here-document would cause dash to
access uninitialized memory at the end of one of the syntax.c tables,
since those tables are sized to accommodate a maximum index of
BASESYNTAX + 126.  Make the generated tables one byte larger.
printf ':\\E\n\200y\nE'|./dash
* src/mksyntax.c (filltable): Use 258, not 257 as the size,
so that BASESYNTAX(=130) + 127 is a valid index.
(print): Likewise.
Don't emit explicit array dimension in declaration.
---
 ChangeLog  |   13 +
 src/mksyntax.c |6 +++---
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d9dcb0c..fabb0e1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2009-09-28  Jim Meyering  meyer...@redhat.com
+
+   don't read-uninitialized for \177 in a here-doc
+   A DEL (0177, dec 127) byte in a here-document would cause dash to
+   access uninitialized memory at the end of one of the syntax.c tables,
+   since those tables are sized to accommodate a maximum index of
+   BASESYNTAX + 126.  Make the generated tables one byte larger.
+   printf ':\\E\n\200y\nE'|./dash
+   * src/mksyntax.c (filltable): Use 258, not 257 as the size,
+   so that BASESYNTAX(=130) + 127 is a valid index.
+   (print): Likewise.
+   Don't emit explicit array dimension in declaration.
+
 2009-08-31  Eric Blake e...@byu.net

* Avoid compiler warnings on isdigit.
diff --git a/src/mksyntax.c b/src/mksyntax.c
index 7a8a9ae..a23c18c 100644
--- a/src/mksyntax.c
+++ b/src/mksyntax.c
@@ -223,7 +223,7 @@ filltable(char *dftval)
 {
int i;

-   for (i = 0 ; i  257; i++)
+   for (i = 0 ; i  258; i++)
syntax[i] = dftval;
 }

@@ -269,9 +269,9 @@ print(char *name)
int col;

fprintf(hfile, extern const char %s[];\n, name);
-   fprintf(cfile, const char %s[%d] = {\n, name, 257);
+   fprintf(cfile, const char %s[] = {\n, name);
col = 0;
-   for (i = 0 ; i  257; i++) {
+   for (i = 0 ; i  258; i++) {
if (i == 0) {
fputs(  , cfile);
} else if ((i  03) == 0) {
--
1.6.5.rc2.177.ga9dd6



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548493: [PATCH] don't read-uninitialized for \177 in a here-doc

[Jim Meyering]

Jim Meyering wrote:

 It was indeed a bug in dash.
 I tracked it down and wrote the patch below:

From 53924ce6da7fece91e57b7238e6aa81a4df636a5 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@redhat.com
 Date: Mon, 28 Sep 2009 11:00:05 +0200
 Subject: [PATCH] don't read-uninitialized for \177 in a here-doc

 A DEL (0177, dec 127) byte in a here-document would cause dash to
 access uninitialized memory at the end of one of the syntax.c tables,
 since those tables are sized to accommodate a maximum index of
 BASESYNTAX + 126.  Make the generated tables one byte larger.
 printf ':\\E\n\200y\nE'|./dash

More details:

The above command fails as follows on certain systems, but not on others:

albeniz/sid$ printf ':\\E\n\177y\nE'|dash
dash: y: not found
dash: E: not found

If you want to simulate the failure consistently, simply enlarge
the sqsyntax table by one and make the last entry anything other
than CWORD.  Use 11 (CEOF) and it'll evoke the symptoms shown above.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548493: test-yesno.sh failure

[Jim Meyering]

Bruno Haible wrote:
 Jim Meyering wrote:
  # Test with seekable stdin; the followon process must see remaining data.
 -cat EOF  ${p}in.tmp
 +cat EOF |tr @ '\177' ${p}in.tmp

 This can be simplified to:

   tr @ '\177' EOF  ${p}in.tmp

Of course!  Thanks.
I've pushed this:

From a9ab119464cf6faa7551ff0b090072adc660eb67 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 27 Sep 2009 08:41:55 +0200
Subject: [PATCH] test-yesno: work around sparc-dash here-document infelicity

Without this change, the literal \177 byte in a here document
would make dash 0.5.5.1-3 access uninitialized memory.
* tests/test-yesno.sh: Don't put the \177 byte in the here document.
Instead, use a marker, @, and filter through tr to create the desired
contents.  Reported as http://bugs.debian.org/548493 by Kurt Roeckx.
---
 ChangeLog   |9 +
 tests/test-yesno.sh |4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 12962ec..f7ef1d6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-09-27  Jim Meyering  meyer...@redhat.com
+
+   test-yesno: work around sparc-dash here-document infelicity
+   Without this change, the literal \177 byte in a here document
+   would make dash 0.5.5.1-3 access uninitialized memory.
+   * tests/test-yesno.sh: Don't put the \177 byte in the here document.
+   Instead, use a marker, @, and filter through tr to create the desired
+   contents.  Reported as http://bugs.debian.org/548493 by Kurt Roeckx.
+
 2009-09-27  Bruno Haible  br...@clisp.org

Disable untested support for new flavours of ACLs on AIX.
diff --git a/tests/test-yesno.sh b/tests/test-yesno.sh
index 52b94ef..b1a5b65 100755
--- a/tests/test-yesno.sh
+++ b/tests/test-yesno.sh
@@ -19,9 +19,9 @@ else
 fi

 # Test with seekable stdin; the followon process must see remaining data.
-cat EOF  ${p}in.tmp
+tr @ '\177' EOF  ${p}in.tmp
 n - entire line consumed
-yn - backspace does not change result
+...@n - backspace does not change result
 y
 does not match either yesexpr or noexpr
 n
--
1.6.5.rc2.177.ga9dd6



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548493: test-yesno.sh failure

[Jim Meyering]

Kurt Roeckx wrote:
 Source: coreutils
 Version: 7.5-1
...
 Build-Depends: gettext (= 0.10.37), debhelper, dh-buildinfo, texinfo (= 
 4.2), groff, dpatch, libattr1-dev | not+linux-gnu, libacl1-dev | 
 not+linux-gnu, libselinux1-dev (= 1.32) | not+linux-gnu, gperf, bison

 [...]

 Toolchain package versions: libc6.1-dev_2.9-26 linux-libc-dev_2.6.30-6 
 g++-4.3_4.3.4-2 gcc-4.3_4.3.4-2 binutils_2.19.91.20090910-1 
 libstdc++6_4.4.1-4 libstdc++6-4.3-dev_4.3.4-2

 [...]

 FAIL: test-yesno.sh (exit: 1)
 =

 ./test-yesno.sh: 24: n: not found
 ./test-yesno.sh: 25: y: not found
 ./test-yesno.sh: 26: does: not found
 ./test-yesno.sh: 27: n: not found
 ./test-yesno.sh: 28: EOF: not found
 t-yesno-xout.tmp t-yesno-out.tmp differ: char 3, line 2
 ==
 1 of 128 tests failed
...
 A full build log can be found at:
 http://buildd.debian.org/build.php?arch=alphapkg=coreutilsver=7.5-6

Thanks for the report.
Does the following change fix it?
If so, please tell me what version of bash it's using
so I can add that to the commit log.

From 0f02aaf44de2d5dc0470bc9ca979f047df7df024 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 27 Sep 2009 08:41:55 +0200
Subject: [PATCH] test-yesno: use here document *without* parameter 
substitution...

to prevent the interpretation of ^?.
* tests/test-yesno.sh: Use \EOF, not EOF on the here
document containing the non-printable ^? (aka DEL, \0177).
Reported as http://bugs.debian.org/548493 by Kurt Roeckx.
---
 ChangeLog   |7 +++
 tests/test-yesno.sh |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f1bcf69..f3e39c0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-09-27  Jim Meyering  meyer...@redhat.com
+
+   test-yesno: use here document *without* parameter substitution...
+   to prevent the interpretation of ^?.
+   * tests/test-yesno.sh: Use \EOF, not EOF on the here
+   document containing the non-printable ^? (aka DEL, \0177).
+
 2009-09-26  Eric Blake  e...@byu.net

argp: fix compilation of getopt
diff --git a/tests/test-yesno.sh b/tests/test-yesno.sh
index 52b94ef..0926683 100755
--- a/tests/test-yesno.sh
+++ b/tests/test-yesno.sh
@@ -19,7 +19,7 @@ else
 fi

 # Test with seekable stdin; the followon process must see remaining data.
-cat EOF  ${p}in.tmp
+cat \EOF  ${p}in.tmp
 n - entire line consumed
 yn - backspace does not change result
 y
--
1.6.5.rc2.177.ga9dd6



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548493: test-yesno.sh failure

[Jim Meyering]

Kurt Roeckx wrote:
 On Sun, Sep 27, 2009 at 08:51:48AM +0200, Jim Meyering wrote:
 Thanks for the report.
 Does the following change fix it?
 If so, please tell me what version of bash it's using
 so I can add that to the commit log.

 Note that /bin/sh points to dash, not bash.  And the same version
 of dash seems to work on other arches.

 Running the test with bash instead of dash seems to work.  Adding
 the \ also doesn't seem to have any effect.

 Removing the '^?' does fix it.

 If you believe this to be a bug in dash, please reassign the bug.
 This was tested using dash 0.5.5.1-3 and bash 4.0-7.

Thanks for the details.
Here's a patch that's more likely to work.
That this failure is specific to the sparc build
is a strong indication that it is a bug in dash or the compiler.
Maybe a sign-extension bug?

FYI, I couldn't reproduce that failure on sparc64 (sperger/unstable)
with dash built from git using gcc version 4.3.4 (Debian 4.3.4-2).

Jim

From 6ffca52a1b2d0c43241c101d847a20cf7875c2fd Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 27 Sep 2009 08:41:55 +0200
Subject: [PATCH] test-yesno: work around sparc-dash here-document infelicity

Without this change, the literal \177 byte in a here document
would make Debian's dash 0.5.5.1-3 (sparc only) misbehave.
* tests/test-yesno.sh: Don't put the \177 byte in the here document.
Instead, use a marker, @, and filter through tr to create the desired
contents.  Reported as http://bugs.debian.org/548493 by Kurt Roeckx.
---
 ChangeLog   |9 +
 tests/test-yesno.sh |4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 12962ec..6043957 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2009-09-27  Jim Meyering  meyer...@redhat.com
+
+   test-yesno: work around sparc-dash here-document infelicity
+   Without this change, the literal \177 byte in a here document
+   would make Debian's dash 0.5.5.1-3 (sparc only) misbehave.
+   * tests/test-yesno.sh: Don't put the \177 byte in the here document.
+   Instead, use a marker, @, and filter through tr to create the desired
+   contents.  Reported as http://bugs.debian.org/548493 by Kurt Roeckx.
+
 2009-09-27  Bruno Haible  br...@clisp.org

Disable untested support for new flavours of ACLs on AIX.
diff --git a/tests/test-yesno.sh b/tests/test-yesno.sh
index 52b94ef..6791f1b 100755
--- a/tests/test-yesno.sh
+++ b/tests/test-yesno.sh
@@ -19,9 +19,9 @@ else
 fi

 # Test with seekable stdin; the followon process must see remaining data.
-cat EOF  ${p}in.tmp
+cat EOF |tr @ '\177' ${p}in.tmp
 n - entire line consumed
-yn - backspace does not change result
+...@n - backspace does not change result
 y
 does not match either yesexpr or noexpr
 n
--
1.6.5.rc2.177.ga9dd6



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#544965: Is umask o+w set?

[Jim Meyering]

Tom Fitzhenry wrote:
 Is umask o+w set where the test directory 'sticky' is being created?

 I compiled coreutils and ran its tests. ls-misc passed.

 The colour your `ls` returns for the directory 'sticky' in the test
 'ls-misc', 30;42, corresponds to other-writable sticky directories.
 The colour that's expected, 37;44, corresponds to sticky directories.

 From src/ls.c:
 if ((mode  S_ISVTX)  (mode  S_IWOTH))
   type = C_STICKY_OTHER_WRITABLE;
 else if ((mode  S_IWOTH) != 0)
   type = C_OTHER_WRITABLE;
 else if ((mode  S_ISVTX) != 0)
   type = C_STICKY;

 So what may be causing the behaviour you're witnessing, is the
 directory 'sticky' being o+w.

 With umask set to o+w, all tests but ls-misc pass. (ls-misc fails with
 the same output as you posted)

Thanks for finding the root cause.
I've fixed it upstream like this:

From 9403417175b40656bbaac0f109841c90f9c05838 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 6 Sep 2009 18:35:40 +0200
Subject: [PATCH] tests: ls-misc: don't let a bogus umask cause test failure

* tests/misc/ls-misc: Set umask to 022.  A umask setting permitting
world-write access, e.g., umask o+w, would cause this test to fail.
Report by Mathias Brodala and analysis by Tom Fitzhenry in
http://bugs.debian.org/544965.
---
 THANKS |2 ++
 tests/misc/ls-misc |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/THANKS b/THANKS
index 961785e..0c5bb40 100644
--- a/THANKS
+++ b/THANKS
@@ -386,6 +386,7 @@ Matthew Swift   sw...@alum.mit.edu
 Matthew Woehlke mw_tr...@users.sourceforge.net
 Matthias Urlichssm...@noris.de
 Matti Aarniomatti.aar...@zmailer.org
+Mathias Brodala i...@noctus.net
 Mattias Wadenstein  mas...@acc.umu.se
 Max Chang   maxch...@ucla.edu
 Meelis Roos mr...@tartu.cyber.ee
@@ -562,6 +563,7 @@ Tim Waugh   twa...@redhat
 Tobias Stoeckmann   tob...@bugol.de
 Toby Peterson   t...@opendarwin.org
 Todd A. Jacobs  tjac...@codegnome.org
+Tom Fitzhenry   t...@tom-fitzhenry.me.uk
 Tom Haynes  tho...@netapp.com
 Tom Quinn   t...@dionysos.thphys.ox.ac.uk
 Tomas Pospisek  t...@sourcepole.ch
diff --git a/tests/misc/ls-misc b/tests/misc/ls-misc
index 63810a5..a734d5f 100755
--- a/tests/misc/ls-misc
+++ b/tests/misc/ls-misc
@@ -239,6 +239,8 @@ my @Tests =
  ],
 );

+umask 022;
+
 # Start with an unset LS_COLORS environment variable.
 delete $ENV{LS_COLORS};

--
1.6.4.2.409.g85dc3



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525048: [PATCH] sort -m: don't segfault when output file is also an input file

[Jim Meyering]

Thanks to Otavio Salvador for finding/reporting this.

Here's the patch I'm considering:

From 570beb56f58bb087a614af885bec7e9cf6b19423 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 22 Apr 2009 08:45:27 +0200
Subject: [PATCH] sort -m: don't segfault when output file is also an input file

* src/sort.c (avoid_trashing_input): Fix an off-by-one error and
guard the use of memmove.
* NEWS (Bug fixes): Mention it.
* tests/misc/sort: Add tests to exercise the offending code.
* THANKS: Update.
Reported by Otavio Salvador in http://bugs.debian.org/525048.
---
 NEWS|6 +-
 THANKS  |1 +
 src/sort.c  |   10 ++
 tests/misc/sort |   17 -
 4 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index 5951bb5..ee44a23 100644
--- a/NEWS
+++ b/NEWS
@@ -1,9 +1,13 @@
 GNU coreutils NEWS-*- outline -*-

-* Noteworthy changes in release ?.? (-??-??) [?]
+* Noteworthy changes in release 7.3 (-??-??) [?]

 ** Bug fixes

+  sort -m no longer segfaults when its output file is also an input file.
+  E.g., with this, touch 1; sort -m -o 1 1, sort would segfault.
+  [introduced in coreutils-7.2]
+
   ls now aligns output correctly in the presence of abbreviated month
   names from the locale database that have differing widths.

diff --git a/THANKS b/THANKS
index fe523fe..876a6b6 100644
--- a/THANKS
+++ b/THANKS
@@ -435,6 +435,7 @@ Ole Laursen o...@hardworking.dk
 Oliver Kiddle   okid...@yahoo.co.uk
 Ørn E. Hansen   oehan...@daimi.aau.dk
 Oskar Liljeblad o...@hem.passagen.se
+Otavio Salvador ota...@ossystems.com.br
 Pádraig Brady   p...@draigbrady.com
 Patrick Mauritz oxyg...@studentenbude.ath.cx
 Paul D. Smith   psm...@gnu.org
diff --git a/src/sort.c b/src/sort.c
index 2e6ce87..f48d727 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1,5 +1,5 @@
 /* sort - sort lines of text (with all kinds of options).
-   Copyright (C) 1988, 1991-2008 Free Software Foundation, Inc.
+   Copyright (C) 1988, 1991-2009 Free Software Foundation, Inc.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -2602,18 +2602,20 @@ avoid_trashing_input (struct sortfile *files, size_t 
ntemps,
  pid_t pid;
  char *temp = create_temp (tftp, pid);
  size_t num_merged = 0;
- while (i + num_merged  nfiles)
+ do
{
  num_merged += mergefiles (files[i], 0, nfiles - i, tftp, temp);
  files[i].name = temp;
  files[i].pid = pid;

- memmove(files[i], files[i + num_merged],
- num_merged * sizeof *files);
+ if (i + num_merged  nfiles)
+   memmove(files[i + 1], files[i + num_merged],
+   num_merged * sizeof *files);
  ntemps += 1;
  nfiles -= num_merged - 1;;
  i += num_merged;
}
+ while (i  nfiles);
}
 }

diff --git a/tests/misc/sort b/tests/misc/sort
index 4f377df..a27f47a 100755
--- a/tests/misc/sort
+++ b/tests/misc/sort
@@ -1,6 +1,6 @@
 #!/usr/bin/perl

-# Copyright (C) 2008 Free Software Foundation, Inc.
+# Copyright (C) 2008, 2009 Free Software Foundation, Inc.

 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -339,6 +339,21 @@ my @Tests =
 [sort-numeric, '--sort=numeric', {IN=.01\n0\n}, {OUT=0\n.01\n}],
 [sort-gennum, '--sort=general-numeric',
   {IN=1e2\n2e1\n}, {OUT=2e1\n1e2\n}],
+
+# -m with output file also used as an input file
+# In coreutils-7.2, this caused a segfault.
+# This test looks a little strange.  Here's why:
+# since we're using -o f, standard output will be empty, hence OUT=''
+# We still want to ensure that the output file, f has expected contents,
+# hence the added CMP= directive.
+[output-is-input, '-m -o f', {IN= {f= a\n}}, {OUT=''},
+ {CMP= [a\n, {'f'= undef}]} ],
+[output-is-input-2, '-m -o f', {OUT=''},
+ {IN= {f= a\n}}, {IN= {g= b\n}}, {IN= {h= c\n}},
+ {CMP= [a\nb\nc\n, {'f'= undef}]} ],
+[output-is-input-3, '-m -o f', {OUT=''},
+ {IN= {g= a\n}}, {IN= {h= b\n}}, {IN= {f= c\n}},
+ {CMP= [a\nb\nc\n, {'f'= undef}]} ],
 );

 # Add _POSIX2_VERSION=199209 to the environment of each test
--
1.6.3.rc1.205.g37f8



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#464118: rm -r broken: Function not implemented

[Jim Meyering]

Adam Conrad [EMAIL PROTECTED] wrote:
 On Fri, Feb 15, 2008 at 07:16:12PM -0500, Michael Stone wrote:
 Could you send an strace from one of the non-working systems? That might
 be enough to figure out what's going wrong and whether it can be worked
 around.

 Attached.

Thanks.

Please double-check the version of the rm binary you
used to create that strace output.
When I try to reproduce the situation (no openat support
and no /proc), the fchdir-based openat emulation works
just fine.  But I'm merely simulating the situation,
and am actually running tests on a system with a recent
kernel, so there may be other factors.

That said, ...
I used a version of rm from the trunk (i.e., post-coreutils-6.10)
and comparing an strace of my working rm -r dir/ command to yours
shows fundamental differences that make me think your version of
rm is out of date.   Maybe even from coreutils-5.9x.

If you can confirm you're using something based on 6.10, please
also attach config.status and lib/config.h.

---
For the record, here's what I did:

Simulate the lack of openat functions:
ac_cv_func_openat=no ./configure  make  make check
All tests passed.

Next, pretend we don't have /proc/self/fd support either, by changing
the openat-emulation code to use nonexistent /proc/self/FD:
  perl -pi -e 's,/proc/self/fd,/proc/self/FD,' lib/openat-proc.c \
tests/du/long-from-unreadable tests/rm/inaccessible

That passed all tests, too, and gave the strace results that looked
so different from yours.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#464118: rm -r broken: Function not implemented

[Jim Meyering]

Jim Meyering [EMAIL PROTECTED] wrote:
 For the record, here's what I did:

 Simulate the lack of openat functions:
 ac_cv_func_openat=no ./configure  make  make check
 All tests passed.

 Next, pretend we don't have /proc/self/fd support either, by changing
 the openat-emulation code to use nonexistent /proc/self/FD:
   perl -pi -e 's,/proc/self/fd,/proc/self/FD,' lib/openat-proc.c \
 tests/du/long-from-unreadable tests/rm/inaccessible

 That passed all tests, too, and gave the strace results that looked
 so different from yours.

Actually, Michael pointed out that your strace includes an fstatat call
(failing with ENOSYS, no less), which suggests you're using a new-enough
version.

I dug a little deeper and think I have identified the problem.  I suspect
that your system has a working openat function and that coreutils detects
it, but that your fstatat function always returns ENOSYS.

The openat module's configure-time test checks only for the existence
of the openat function.  If that test succeeds on your system, yet it
lacks fstatat, then that would explain what's happening.

To support such a system you have a choice:

  1) easy: turn off all openat support. i.e., build like this:

ac_cv_func_openat=no ./configure

  2) more work: add a configure-time test for a working fstatat, and
if it's not available, link with the replacement function that is
currently included unconditionally via the definition in openat.c.

Since this is for a kernel that is old, but not *that* old, (i.e., the
problem affects only the few kernels, that had incomplete openat support)
spending time on #2 does not seem worthwhile to me.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#460422: Alignment issue with sha1 code from gnulib

[Jim Meyering]

Bruno Haible [EMAIL PROTECTED] wrote:

 Jim Meyering wrote:
 Thanks for the suggestion.  It looks like a good one.

 The suggestion also applies to the 'md5' module, after which the 'sha1' module
 is modeled.

Yep.  md2 and md4 too.
For now, I've pushed the sha1 changes.

 But if you apply the suggestion to both the sha1 and md5 modules, we get
 an additional difference to glibc code.

That's unfortunate, but I agree it's not a big problem.
If upstream glibc is no longer able to evolve, I don't want
to let that impede progress here.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#460422: Alignment issue with sha1 code from gnulib

[Jim Meyering]

Jim Meyering [EMAIL PROTECTED] wrote:
 David Shaw [EMAIL PROTECTED] wrote:
 Peter Palfrader reported a bug against the sha1 code in paperkey, but
 that code actually comes from gnulib, so I'm referring it to you.

 The issue comes up (as noted in the comment) if resbuf is not 32-bit
 aligned.  Rather than requiring all programs that use the gnulib sha1
 code to align their result buffer, Peter's patch seems to make more
 sense in that it just works on any platform.

 David

 - Forwarded message from Peter Palfrader [EMAIL PROTECTED] -

 This seems to fix the issue:

 -sha1_read_ctx (const struct sha1_ctx *ctx, void *resbuf)
 +sha1_read_ctx (const struct sha1_ctx *ctx, char *resbuf)
  {
 -  ((uint32_t *) resbuf)[0] = SWAP (ctx-A);
 -  ((uint32_t *) resbuf)[1] = SWAP (ctx-B);
 -  ((uint32_t *) resbuf)[2] = SWAP (ctx-C);
 -  ((uint32_t *) resbuf)[3] = SWAP (ctx-D);
 -  ((uint32_t *) resbuf)[4] = SWAP (ctx-E);
 +  set_uint32(resbuf[0*4], SWAP (ctx-A));
 +  set_uint32(resbuf[1*4], SWAP (ctx-B));
 +  set_uint32(resbuf[2*4], SWAP (ctx-C));
 +  set_uint32(resbuf[3*4], SWAP (ctx-D));
 +  set_uint32(resbuf[4*4], SWAP (ctx-E));

 Thanks for the suggestion.  It looks like a good one.
 However, I don't want to change the type of the resbuf parameter.
 Here's the change I'm considering:

 diff --git a/lib/sha1.c b/lib/sha1.c
 index 035f898..d9e99d8 100644
 --- a/lib/sha1.c
 +++ b/lib/sha1.c
 @@ -67,28 +67,32 @@ sha1_init_ctx (struct sha1_ctx *ctx)
ctx-buflen = 0;
  }

 -/* Put result from CTX in first 20 bytes following RESBUF.  The result
 -   must be in little endian byte order.
 +/* Copy the 4 byte value from v into the memory location pointed to by *cp,
 +   If your architecture allows unaligned access this is equivalent to
 +   * (uint32_t *) cp = v  */
 +void
 +set_uint32 (char *cp, uint32_t v)
 +{
 +  memcpy (cp, v, 4);
 +}

Oops.
While applying a nearly identical patch to md5.c,
I noticed a minor error: that new function must have static scope.
I'll fix that in sha1.c shortly.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#460422: Alignment issue with sha1 code from gnulib

[Jim Meyering]

David Shaw [EMAIL PROTECTED] wrote:
 Peter Palfrader reported a bug against the sha1 code in paperkey, but
 that code actually comes from gnulib, so I'm referring it to you.

 The issue comes up (as noted in the comment) if resbuf is not 32-bit
 aligned.  Rather than requiring all programs that use the gnulib sha1
 code to align their result buffer, Peter's patch seems to make more
 sense in that it just works on any platform.

 David

 - Forwarded message from Peter Palfrader [EMAIL PROTECTED] -

 This seems to fix the issue:

 -sha1_read_ctx (const struct sha1_ctx *ctx, void *resbuf)
 +sha1_read_ctx (const struct sha1_ctx *ctx, char *resbuf)
  {
 -  ((uint32_t *) resbuf)[0] = SWAP (ctx-A);
 -  ((uint32_t *) resbuf)[1] = SWAP (ctx-B);
 -  ((uint32_t *) resbuf)[2] = SWAP (ctx-C);
 -  ((uint32_t *) resbuf)[3] = SWAP (ctx-D);
 -  ((uint32_t *) resbuf)[4] = SWAP (ctx-E);
 +  set_uint32(resbuf[0*4], SWAP (ctx-A));
 +  set_uint32(resbuf[1*4], SWAP (ctx-B));
 +  set_uint32(resbuf[2*4], SWAP (ctx-C));
 +  set_uint32(resbuf[3*4], SWAP (ctx-D));
 +  set_uint32(resbuf[4*4], SWAP (ctx-E));

Thanks for the suggestion.  It looks like a good one.
However, I don't want to change the type of the resbuf parameter.
Here's the change I'm considering:

diff --git a/lib/sha1.c b/lib/sha1.c
index 035f898..d9e99d8 100644
--- a/lib/sha1.c
+++ b/lib/sha1.c
@@ -67,28 +67,32 @@ sha1_init_ctx (struct sha1_ctx *ctx)
   ctx-buflen = 0;
 }

-/* Put result from CTX in first 20 bytes following RESBUF.  The result
-   must be in little endian byte order.
+/* Copy the 4 byte value from v into the memory location pointed to by *cp,
+   If your architecture allows unaligned access this is equivalent to
+   * (uint32_t *) cp = v  */
+void
+set_uint32 (char *cp, uint32_t v)
+{
+  memcpy (cp, v, 4);
+}

-   IMPORTANT: On some systems it is required that RESBUF is correctly
-   aligned for a 32-bit value.  */
+/* Put result from CTX in first 20 bytes following RESBUF.  The result
+   must be in little endian byte order.  */
 void *
 sha1_read_ctx (const struct sha1_ctx *ctx, void *resbuf)
 {
-  ((uint32_t *) resbuf)[0] = SWAP (ctx-A);
-  ((uint32_t *) resbuf)[1] = SWAP (ctx-B);
-  ((uint32_t *) resbuf)[2] = SWAP (ctx-C);
-  ((uint32_t *) resbuf)[3] = SWAP (ctx-D);
-  ((uint32_t *) resbuf)[4] = SWAP (ctx-E);
+  char *r = resbuf;
+  set_uint32 (r + 0*4, SWAP (ctx-A));
+  set_uint32 (r + 1*4, SWAP (ctx-B));
+  set_uint32 (r + 2*4, SWAP (ctx-C));
+  set_uint32 (r + 3*4, SWAP (ctx-D));
+  set_uint32 (r + 4*4, SWAP (ctx-E));

   return resbuf;
 }

 /* Process the remaining bytes in the internal buffer and the usual
-   prolog according to the standard and write the result to RESBUF.
-
-   IMPORTANT: On some systems it is required that RESBUF is correctly
-   aligned for a 32-bit value.  */
+   prolog according to the standard and write the result to RESBUF.  */
 void *
 sha1_finish_ctx (struct sha1_ctx *ctx, void *resbuf)
 {
diff --git a/lib/sha1.h b/lib/sha1.h
index 9545f0b..9e55974 100644
--- a/lib/sha1.h
+++ b/lib/sha1.h
@@ -1,6 +1,7 @@
 /* Declarations of functions and data types used for SHA1 sum
library functions.
-   Copyright (C) 2000, 2001, 2003, 2005, 2006 Free Software Foundation, Inc.
+   Copyright (C) 2000, 2001, 2003, 2005, 2006, 2008
+   Free Software Foundation, Inc.

This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
@@ -57,19 +58,13 @@ extern void sha1_process_bytes (const void *buffer, size_t 
len,
 /* Process the remaining bytes in the buffer and put result from CTX
in first 20 bytes following RESBUF.  The result is always in little
endian byte order, so that a byte-wise output yields to the wanted
-   ASCII representation of the message digest.
-
-   IMPORTANT: On some systems it is required that RESBUF be correctly
-   aligned for a 32 bits value.  */
+   ASCII representation of the message digest.  */
 extern void *sha1_finish_ctx (struct sha1_ctx *ctx, void *resbuf);


 /* Put result from CTX in first 20 bytes following RESBUF.  The result is
always in little endian byte order, so that a byte-wise output yields
-   to the wanted ASCII representation of the message digest.
-
-   IMPORTANT: On some systems it is required that RESBUF is correctly
-   aligned for a 32 bits value.  */
+   to the wanted ASCII representation of the message digest.  */
 extern void *sha1_read_ctx (const struct sha1_ctx *ctx, void *resbuf);




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#460422: Alignment issue with sha1 code from gnulib

[Jim Meyering]

Jim Meyering [EMAIL PROTECTED] wrote:
...
 Thanks for the suggestion.  It looks like a good one.
 However, I don't want to change the type of the resbuf parameter.
 Here's the change I'm considering:

And of course, coreutils/lib/sha*.c would get the same change.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#462226: coreutils: FTBFS on mips: tests failed: rm/deep-1, rm/dangling-symlink, ...

[Jim Meyering]

Michael Stone [EMAIL PROTECTED] wrote:

 On Wed, Jan 23, 2008 at 09:04:22PM +0100, Lucas Nussbaum wrote:
Note that the mipsel buildd failed in the exact same way.

 Yeah, same theory holds. Until it can be duplicated with a manual
 build or we get the build logs it ain't gonna be easy to fix. It's
 obviously trivial to special case mips and not run the build tests on
 that platform, but there's something going on here that's beyond
 coreutils that's probably worth fixing.

One more data point: I tried to reproduce by building
manually on casals, but all tests passed.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#442040: coreutils: FTBFS on PPC in seq test suite

[Jim Meyering]

Bram Senders [EMAIL PROTECTED] wrote:

 On Wed, Sep 12, 2007 at 07:58:22PM +0200, Jim Meyering wrote:
 Thanks for the report.
 However, I've just built from the very latest upstream sources
 (but probably no change to seq since the 20070907 snapshot)
 on bruckner, with CFLAGS=-g ./configure  make, and it passes
 that same test:

 bruckner$ ./seq 10.8 0.1 10.95
 10.8
 10.9

 I also recompiled seq.o with CFLAGS=-O2.  Same result.

 Can you try the same thing on whatever system you used?

 I pulled the latest sources from git and built them with CFLAGS=-g, like
 you said, giving again the same erroneous results:

 [EMAIL PROTECTED] ./seq 10.8 0.1 10.95
 10.8
 10.9
 11.0

 Recompiling seq by hand with -O2 gives the same faulty result as
 compiling with -g gives for me.  So there seems to be some kind of
 difference between bruckner and my machine...  I don't understand this.
 Any hints or pointers?

gcc version?
Maybe libc

bruckner has this:

  gcc version 3.3.5 (Debian 1:3.3.5-13)
  libc6: Version: 2.3.2.ds1-22sarge6

Please send me your lib/config.h file so I can compare it with mine.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#442040: coreutils: FTBFS on PPC in seq test suite

[Jim Meyering]

Bram Senders [EMAIL PROTECTED] wrote:
 Package: coreutils
 Version: 6.10~20070907
 Severity: serious
 Justification: no longer builds from source

 Hi there,

 I cannot build the current coreutils from experimental from source on
 PowerPC, because of a failure in the seq test suite:
...
 *** float-3.O   Wed Sep 12 12:47:28 2007
 --- float-3.1   Wed Sep 12 12:47:28 2007
 ***
 *** 1,3 
   10.8
   10.9
 - 11.0
 --- 1,2 
 FAIL: basic
 === 8 ===

Thanks for the report.
However, I've just built from the very latest upstream sources
(but probably no change to seq since the 20070907 snapshot)
on bruckner, with CFLAGS=-g ./configure  make, and it passes
that same test:

bruckner$ ./seq 10.8 0.1 10.95
10.8
10.9

I also recompiled seq.o with CFLAGS=-O2.  Same result.

Can you try the same thing on whatever system you used?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#433394: FTBFS: conflicting types for 'futimens'

[Jim Meyering]

Michael Stone [EMAIL PROTECTED] wrote:

 On Tue, Jul 17, 2007 at 03:54:03PM +0200, you wrote:
Alright. Will there be an update? Upstream already is at version 6.9.

 I'm aware of the upstream version. The difficulty is with the
 integration of the selinux stuff (which wasn't in the experimental
 version). If that managed to get integrated upstream the releases
 would come much faster.

The SELinux changes *are* all integrated upstream, just not
in an official release yet.
I put all of that on the trunk right after the 6.9 release.
Bringing the SELinux changes up to standard exposed several
mostly-minor bugs in that area.

It'd really be nice to get feedback from a few people who use
SELinux and coreutils-6.9+ before I release 6.10.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#426904: coreutils: FTBFS

[Jim Meyering]

Tshepang Lekhonkhobe [EMAIL PROTECTED] wrote:
 Package: coreutils
 Version: 5.97-5
 Severity: serious
 Justification: no longer builds from source

 make[3]: Entering directory
 `/home/wena/temp/coreutils-5.97/build-tree/coreutils-5.97/tests/chgrp'
 /usr/bin/make  check-TESTS
 make[4]: Entering directory
 `/home/wena/temp/coreutils-5.97/build-tree/coreutils-5.97/tests/chgrp'
 cmp: EOF on out
 0a1
 chgrp: `d/no-x': Permission denied
 FAIL: no-x

Thanks for reporting that.
Would you please repeat that test with
a small change to tests/chgrp/no-x:

In place of this line,

  chgrp -R $g2 d /dev/null 2out  fail=1

use this:

  strace -o /tmp/chgrp-log chgrp -R $g2 d /dev/null 2out  fail=1

and then /tmp/chgrp-log should give us a clue about why that
chgrp invocation is succeeding when it shouldn't.

It might be useful also to see the output of running that
test in verbose mode:

  cd coreutils 
env VERBOSE=yes DEBUG=yes make check -C tests/chgrp TESTS=no-x \
   test-log 21


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421555: coreutils: printf %-1.25000000s segfaults

[Jim Meyering]

Pierre Habouzit [EMAIL PROTECTED] wrote:

 Package: coreutils
 Version: 5.97-5.3
 Severity: important

 $ /usr/bin/printf '%-1.2500s\n' 'Hello'

   Is a quite good testcase :)

   FWIW libc printf seems to work properly. Further poking shows that it
 may be locale-dependant as the following works:

Thanks for the report!
To reproduce it, I did this:

$ LC_ALL=fr_FR.utf8 ./printf %1.25s x
zsh: bus error  LC_CTYPE=fr_FR.utf8 ./printf %1.25s x
[Exit 135 (BUS)]

Actually that's due to a bug in glibc that affects even the very
latest in CVS.  I've dug a little and reported it upstream:

http://bugzilla.redhat.com/238406


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#380552: a possible medium term soloution

[Jim Meyering]

Bastian Blank [EMAIL PROTECTED] wrote:
 On Sat, Feb 24, 2007 at 04:52:12AM -0800, Steve Langasek wrote:
 Bastian, do you have any explanation for this?  coreutils now builds
 successfully in the test environment Manoj set up using bind mounts, but
 still fails on the s390 buildd.  What is special/different still about the
 bind mount setup on the s390 buildd?

 It fails with the old message in my testsetup on the buildd but not on
 my notebook. It also succeds with a newer kernel. So this is likely a
 change in kernel behaviour in this case.

If my upstream fix for this doesn't work, please let me know.
Or maybe it's just that you can't use it, for some reason?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#380552: failed again on the same test

[Jim Meyering]

peter green [EMAIL PROTECTED] wrote:
 reopen 380552
 thanks

 looks like this is still an issue.
 http://buildd.debian.org/fetch.cgi?pkg=coreutils;ver=5.97-5.3;arch=s390;stamp=1170189620
 FAIL: pwd-long

Thanks for reporting that.
Somehow, even gnulib's getcwd is failing,
and then the robust_getcwd from pwd.c fails, too,
with the diagnostic:

/build/buildd/coreutils-5.97/build-tree/coreutils-5.97/tests/misc/../../src/pwd:
 couldn't find directory entry in 
`../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../..'
 with matching i-node
pwd-long:  does not contain old CWD
FAIL: pwd-long

Can I get access to the build directory?
I've just confirmed I have access to raptor.debian.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#380552: failure of pwd-long test on linux bind mount

[Jim Meyering]

Michael Stone [EMAIL PROTECTED] wrote:
 If you run the coreutils pwd-long test from within a bind mount it'll
 fail. Reproduce with:
 | mkdir test1 test2
 | mount --bind test1 test2
 | cd test2
 | env BUILD_SRC_DIR=/bin ./pwd-long

 looking at what pwd returns:
 (expects)
 /tmp/test2/pwd-long.tmp/19496/zzz/z[...]
 (gets)
 /tmp/test1/pwd-long.tmp/19496/zzz/z[...]

 this actually makes sense based on the algorithm (stat ., list .., find
 the directory which has the right inode) and I'm not sure that I can
 think of a way to rewrite the test so that it would actually work on a
 bind mount. Maybe we could only compare the part from pwd-long.tmp on,
 but would that still test for whatever failure lead to the test in the
 first place?

Thanks.
I've fixed it on the trunk like this:

2007-01-20  Jim Meyering  [EMAIL PROTECTED]

* tests/misc/pwd-long: Work properly even when run from the
wrong one of two or more bind-mounted sibling directories.
Suggestion from Mike Stone in http://bugs.debian.org/380552.

diff --git a/tests/misc/pwd-long b/tests/misc/pwd-long
index 546550e..1306b32 100755
--- a/tests/misc/pwd-long
+++ b/tests/misc/pwd-long
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Ensure that pwd works even when run from a very deep directory.

-# Copyright (C) 2006 Free Software Foundation, Inc.
+# Copyright (C) 2006-2007 Free Software Foundation, Inc.

 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -51,18 +51,39 @@ $PERL -Tw -- - \EOF
 # Show that pwd works even when the length of the resulting
 # directory name is longer than PATH_MAX.
 use strict;
-use Cwd;

 (my $ME = $ENV{ARGV_0}) =~ s|.*/||;

+sub normalize_to_cwd_relative ($$$)
+{
+  my ($dir, $dev, $ino) = @_;
+  my $slash = -1;
+  my $next_slash;
+  while (1)
+{
+  $slash = index $dir, '/', $slash + 1;
+  $slash = -1
+   and die $ME: $dir does not contain old CWD\n;
+  my $dir_prefix = $slash ? substr ($dir, 0, $slash) : '/';
+  my ($d, $i) = (stat $dir_prefix)[0, 1];
+  $d == $dev  $i == $ino
+   and return substr $dir, $slash + 1;
+}
+}
+
 # Set up a safe, well-known environment
 delete @ENV{qw(BASH_ENV CDPATH ENV PATH)};
 $ENV{IFS}  = '';

-my $cwd = $ENV{CWD};
+# Save CWD's device and inode numbers.
+my ($dev, $ino) = (stat '.')[0, 1];
+
+# Construct the expected .-relative part of pwd's output.
 my $z = 'z' x 31;
 my $n = 256;
-my $expected = $cwd . (/$z x $n);
+my $expected = /$z x $n;
+# Remove the leading /.
+substr ($expected, 0, 1) = '';

 my $i = 0;
 do
@@ -89,6 +110,15 @@ my $pwd_binary = $build_src_dir/pwd;
 -x $pwd_binary
   or die $ME: $pwd_binary is not an executable file\n;
 chomp (my $actual = `$pwd_binary`);
+
+# Convert the absolute name from pwd into a $CWD-relative name.
+# This is necessary in order to avoid a spurious failure when run
+# from a directory in a bind-mounted partition.  What happens is
+# pwd reads a .. that contains two or more entries with identical
+# dev,ino that match the ones we're looking for, and it chooses a
+# name that does not correspond to the one already recorded in $CWD.
+$actual = normalize_to_cwd_relative $actual, $dev, $ino;
+
 if ($expected ne $actual)
   {
 my $e_len = length $expected;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#380552: coreutils - FTBFS

[Jim Meyering]

[EMAIL PROTECTED] (Bob Proulx) wrote:
 Michael Stone wrote:
 Bastian Blank wrote:
 [...]
 FAIL: pwd-long

 Since this is the only failure listed, I'll assume it's the problem. Was
 there any actual diagnostic message in the part you snipped?

 Thanks for the report.  If you can set the VERBOSE=yes variable and
 build again and report the detailed debugging output that would allow
 us to know more information about this problem.

 In the build directory:

   env VERBOSE=yes make -C tests/misc TESTS=pwd-long

 Or whatever you need to do to get VERBOSE=yes set for the pwd-long
 test.  That will produce shell tracing output.

Thanks for the report.
Please do as Bob suggests and also tell us the
type of file system in use (df -T) and kernel/libc versions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#339136: Which packages rely on the old stat behavior?

[Jim Meyering]

Thomas Hood [EMAIL PROTECTED] wrote:
 If the solution is going to be: to fix the programs that use
 the stat program so that they work either with the old or with the
 new behavior, and/or to add versioned Conflicts to coreutils for
 each package version containing a program that depends on the old
 behavior, then I would suggest that someone perform a systematic
 search through current Debian packages looking for the stat command
 so that all the required Conflicts can be added at once.

FYI, I plan to revert the offending change for coreutils-5.94,
and to add a new option: --printf=FMT with the current semantics.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#339136: stat behavior change

[Jim Meyering]

Junichi Uekawa [EMAIL PROTECTED] wrote:
 reopen 339136
 retitle 339136 stat --format behavior change with default newline
 thanks
...
 Older (sarge system):
...
 stat * --format %d %i:|tr : '\n' | head
 2054 21186142
 2054 21186136
 2054 7831563

 Newer(current sid):
...
 $ stat * --format %d %i:|tr : '\n' | head
 2049 212424

 2049 212508

 2049 212509

You can get portable results by adding tr's
--squeeze-repeats (-s) option:

  $ stat * --format %d %i:|tr -s : '\n' | head

Also, it's a good idea to put file names after `--'
in case the expansion of `*' includes names starting with `-'.

  $ stat --format %d %i: -- *|tr -s : '\n' | head


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#339136: Changes in stat package output break apt-move

[Jim Meyering]

[ For those reading this via bug-coreutils, the original bug report
  is here: http://bugs.debian.org/339136. ]

Thanks for the report.
FYI, this change was mentioned in the NEWS for upstream coreutils-5.3.0,
10 months ago.

  With stat, a specified format is no longer automatically newline terminated.
  If you want a newline at the end of your output, append `\n' to the format
  string.

One problem is that the NEWS entry is inaccurate,
since appending \n doesn't help at all.
Unfortunately, no one reported the problem before this.

Petr Vandrovec [EMAIL PROTECTED] wrote:
 Package: coreutils
 Version: 5.93-2
 Severity: critical
 Justification: renders apt-move unusable

 Hello,
 in the past 'stat -L -c %s / /' produced

 4096 LF
 4096 LF

 while now (since 5.93 update) it produces

 40964096

You can work around that portably by using e.g.,

  stat -L -c %s: / / | tr : '\n'

I expect to make stat accept \n, as NEWS says it does,
and to document that.  Preliminary patch below.
I'm vacillating on whether to accept other backslash escapes.

 without any explanation why this happened.  This breaks at least apt-move and
 some programs I've written.

 But what's worse is that now stat does not provide any way how to get each of
 stat results on separate line - %s\n just generates 4096\n4096\n, without
 interpreting \n...

 Can you revert to the old behavior and provide special option for new (IMHO
 broken) one, or provide some method how to embed LF to the output without
 actually having LF embedded directly into shell scripts?  Though I would 
 prefer
 backward compatibility over even bigger incompatibility.

 See bug 339024 for apt-move's half of story.

Index: stat.c
===
RCS file: /fetish/cu/src/stat.c,v
retrieving revision 1.89
diff -u -p -r1.89 stat.c
--- stat.c  15 Oct 2005 10:15:48 -  1.89
+++ stat.c  15 Nov 2005 10:41:03 -
@@ -536,6 +536,24 @@ print_stat (char *pformat, size_t buf_le
 }
 
 static void
+print_esc (FILE *fp, char const *s)
+{
+  while (*s)
+{
+  if (*s == '\\'  s[1] == 'n')
+   {
+ fputc ('\n', fp);
+ ++s;
+   }
+  else
+   {
+ fputc (*s, fp);
+   }
+  ++s;
+}
+}
+
+static void
 print_it (char const *masterformat, char const *filename,
  void (*print_func) (char *, size_t, char, char const *, void const *),
  void const *data)
@@ -558,7 +576,7 @@ print_it (char const *masterformat, char
{
  size_t len;
  *p++ = '\0';
- fputs (b, stdout);
+ print_esc (stdout, b);
 
  len = strspn (p, #-+.I 0123456789);
  dest[0] = '%';
@@ -573,6 +591,9 @@ print_it (char const *masterformat, char
  b = NULL;
  /* fall through */
case '%':
+ if (0  len)
+   error (EXIT_FAILURE, 0, _(%s%s: invalid directive),
+  quotearg_colon (dest), *p ? % : );
  putchar ('%');
  break;
default:
@@ -582,7 +603,7 @@ print_it (char const *masterformat, char
}
   else
{
- fputs (b, stdout);
+ print_esc (stdout, b);
  b = NULL;
}
 }


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#339136: Changes in stat package output break apt-move

[Jim Meyering]

Michael Stone [EMAIL PROTECTED] wrote:
 On Tue, Nov 15, 2005 at 11:42:12AM +0100, Jim Meyering wrote:
  With stat, a specified format is no longer automatically newline terminated.
  If you want a newline at the end of your output, append `\n' to the format
  string.

 Hmm. I don't know if I like this change--it really screws with
 compatability without offering any obvious advantage in my mind.

I do see your point of view, since the `stat' program doesn't feel
very new, now.  But back when I made the change, it *was* relatively new.
And now that I've made 5 releases (two stable) with this behavior,
changing stat back to always emit a trailing newline seems like it'd be
even more disruptive.

FYI, I proposed this change almost two years ago:

  http://lists.gnu.org/archive/html/bug-coreutils/2004-02/msg6.html

And checked it in 2 months later, just after the release of 5.2.1.
There were no objections.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#339136: Changes in stat package output break apt-move

[Jim Meyering]

Michael Stone [EMAIL PROTECTED] wrote:
...
 My main concern here is that there is no way for someone to use
 stat -c %whatever file1 file2
 and expect it to work for both syntaxes without reverting to some truely
 hideous sed games or somesuch.

But there *is* a way.  It's just that the portable solution
doesn't fit on one line:

  $ stat -c '%G
   ' / /
  root
  root

You can also do something like this:

#!/bin/sh
nl='
'
stat -c %G$nl / /

If you don't mind relying on a feature that
works in both bash and zsh, there's yet another way:

  $ stat -c $'%G\n' / /
  root
  root


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#274705: mv: --reply doesn't work

[Jim Meyering]

Anthony Towns aj@azure.humbug.org.au wrote:
 tag 274705 + patch
 thanks

 So the relevant code seems to be in src/copy.c, where it checks if
 --reply=no was set _and_ the file isn't overwritable; or if -i was
 set, or if no option was given and the file isn't overwritable. So
 --reply=no has an effect when you do:

   touch a b
   chmod 000 b
   mv --reply=no a b  # can't overwrite, so do nothing

 This seems quite deliberate, but afaics it's a bug. I think the attached
 patch fixes the problem.

 Cheers,
 aj

Thanks for the patch.
There's been a lot of talk about mv's --reply option, recently.
I'm planning to deprecate that option.
Here's the main thread:

  http://lists.gnu.org/archive/html/bug-coreutils/2005-06/msg00160.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]