[EMAIL PROTECTED]: Re: preserve-gid (Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0)]

[Elias Pipping]

Forwarding this because I took it off-list by accident.

- Forwarded message from Elias Pipping <[EMAIL PROTECTED]> -

From: Elias Pipping <[EMAIL PROTECTED]>
Date: Tue, 4 Dec 2007 08:42:25 +0100
To: Bob Proulx <[EMAIL PROTECTED]>
Subject: Re: preserve-gid (Re: coreutils-6.9.90 fail 1/84 (help-version) on
i386-apple-darwin9.1.0)

On Mon, Dec 03, 2007 at 09:00:32PM -0700, Bob Proulx wrote:
> Elias Pipping wrote:
> > FAIL: preserve-gid.log (exit: 1)
> 
> Here is the failure, the "good parts" version:
> 
> > + nameless_uid=1000
> > + nameless_gid1=1000
> > + nameless_gid2=1001
> 
> What range is the normal user range for your system? 

They start at 501. I don't know where they end, though.

> Because it looks like your system has no non-root users but I assume
> they are simply in a different id range such as down in the 100 or
> 500 numbers.
> 

501 is me.

> > + chown +1000 .
> > + echo a0
> > + chown +0:+0 a0
> > + cp a0 b
> > ++ stat -c '%u %g' b
> > + s='0 20'
> > + test 'x0 20' '!=' 'x0 0'
> > + echo './preserve-gid: cp a0 b: 0 0 != 0 20'
> > ./preserve-gid: cp a0 b: 0 0 != 0 20
> 
> Can you try this?  This is a slightly modified form of the above.  It
> is explicitly setting the group of the test directory to group 20
> whereas in the above I think it is happening arbitrarily.
> 
>   mkdir preserve-gid
>   cd preserve-gid
>   chown +1000:+20 .
>   echo a0 > a0
>   ls -ld . a0
>   chown +0:+0 a0
>   cp a0 b
>   ls -ld . a0 b

  # mkdir preserve-gid
  # cd preserve-gid
  # chown +1000:+20 .
  # echo a0 > a0
  # ls -ld . a0
  drwxr-xr-x 2 1000 staff 102 2007-12-04 08:32 .
  -rw-r--r-- 1 root staff   3 2007-12-04 08:32 a0
  # chown +0:+0 a0
  # cp a0 b
  # ls -ld . a0 b
  drwxr-xr-x 2 1000 staff 136 2007-12-04 08:33 .
  -rw-r--r-- 1 root wheel   3 2007-12-04 08:32 a0
  -rw-r--r-- 1 root staff   3 2007-12-04 08:33 b

run as root, with PATH=${PWD}

> I don't see where in the test it is setting the group of the
> directory.  A BSD based system I expect would create the new file with
> the same group as the parent directory.  When b is copied I don't see
> where the group would be getting set explicitly and so it will inherit
> the directory group.  It looks like the group is inheriting your users
> group of 20.
> 
> Then try again with this modification.  If this passes then we can fix
> the test.
> 
>   chown +1000:+0 .
>   echo a0 > a0
>   ls -ld . a0
>   chown +0:+0 a0
>   cp a0 b
>   ls -ld . a0 b
>   test "x`stat -c '%u %g' b`" = 'x0 0' && echo passed || echo failed

It does.

  # mkdir preserve-gid2
  # cd preserve-gid2
  #   chown +1000:+0 .
  #   echo a0 > a0
  #   ls -ld . a0
  drwxr-xr-x 2 1000 wheel 102 2007-12-04 08:35 .
  -rw-r--r-- 1 root wheel   3 2007-12-04 08:35 a0
  #   chown +0:+0 a0
  #   cp a0 b
  #   ls -ld . a0 b
  drwxr-xr-x 2 1000 wheel 136 2007-12-04 08:35 .
  -rw-r--r-- 1 root wheel   3 2007-12-04 08:35 a0
  -rw-r--r-- 1 root wheel   3 2007-12-04 08:35 b
  #   test "x`stat -c '%u %g' b`" = 'x0 0' && echo passed || echo failed
  passed

again, run as root, with PATH=${PWD}

> > + chmod -R u+rwx 
> > /Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.xoMcxRWTmq
> > + rm -rf /Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.xoMcxRWTmq
> > rm: cannot remove 
> > `/Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.xoMcxRWTmq': 
> > Operation not permitted
> 
> This does not seem like it should have failed when run by root.
> What type of a filesystem is /Users ?  Is that local or networked?

I've just re-ran the test, absolutely positively as root, and it failed
again.

+ rm -rf /Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.jiAjPyuxIY
rm: cannot remove 
`/Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.jiAjPyuxIY': 
Operation not permitted

/Users is a directory on the local harddrive.


-- Elias



- End forwarded message -


pgpXltoNxCBUt.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[EMAIL PROTECTED]: Re: special-bits (Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0)]

[Elias Pipping]

Forwarding this because I took it off-list by accident.

- Forwarded message from Elias Pipping <[EMAIL PROTECTED]> -

From: Elias Pipping <[EMAIL PROTECTED]>
Date: Tue, 4 Dec 2007 08:46:42 +0100
To: Bob Proulx <[EMAIL PROTECTED]>
Subject: Re: special-bits (Re: coreutils-6.9.90 fail 1/84 (help-version) on
i386-apple-darwin9.1.0)

On Mon, Dec 03, 2007 at 08:26:21PM -0700, Bob Proulx wrote:
> Elias Pipping wrote:
> 
> Here is the failure, the "good parts" version:
> 
> >  * special-bits
> > ++ : nobody
> > +++ id -u nobody
> > ++ coreutils_non_root_uid=4294967294
> > + touch a b c
> > + chmod u+sx,go= a
> > + chmod u=rwx,g=sx,o= b
> > + chmod a=r,ug+sx c
> > + chown nobody .
> > + chmod u=rwx,g=rx,o=rx .
> > + fail=0
> > + cp -p a a2
> > cp: `a': No such file or directory
> > + fail=1
> 
> The touch and chmod created a file and set the mode bits but then cp
> is complaining that it does not exist.  Can you run this set of
> commands?
> 
>   touch a
>   chmod u+sx,go= a
>   chown nobody .
>   chmod u=rwx,g=rx,o=rx .
>   cp -p a a2
>   ls -ld . a

  # touch a
  # chmod u+sx,go= a
  # chown nobody .
  # chmod u=rwx,g=rx,o=rx .
  # cp -p a a2
  cp: `a': No such file or directory
  # ls -ld . a
  drwxr-xr-x 5 nobody staff 11288 2007-12-04 08:43 .
  -rws-- 1 root   staff 0 2007-12-04 08:43 a

run as root, with PATH=${PWD}

  # cp --version
  cp (GNU coreutils) 6.9.90
  [ snip ]

> That should fail the same as the test case.  If it does then the ls
> should report what was actually created and the permission of the
> directory.  I expect to see something like this:
> 
>   drwxr-xr-x 2 nobody root 4096 2007-12-03 20:21 .
>   -rws-- 1 root   root0 2007-12-03 20:21 a
> 
> In which case the "No such file or directory" error is very strange.
> The touch and chmod succeeded operating on the file but the cp failed
> to open it?
> 
> Bob

-- Elias



- End forwarded message -


pgpchpgcP437g.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: preserve-gid (Re: coreutils-6.9.90 test results for x86_64-linux-gnu)

[Mike Frysinger]

On Tuesday 04 December 2007, Bob Proulx wrote:
> Mike Frysinger wrote:
> > > fchown(4, 0, 1017)  = -1 EPERM (Operation not
> > > permitted) fchown(4, 4294967295, 1017) = 0
> >
> > i'm not seeing the second fchown(), just the first
>
> Is this still within the same failure space as the directory that was
> go-rwx?  Because if so then I think it means that this got the system
> cp instead of the freshly built one.  A cascade failure.  Fixing that
> should fix this too.  I hope.

i looked but i missed that ... the strace shows execve() on the new `cp` 
failing with EACCESS as it uses the full path
-mike


signature.asc
Description: This is a digitally signed message part.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: fail-2eperm (was: coreutils-6.9.90 test results for x86_64-linux-gnu)

[Mike Frysinger]

On Tuesday 04 December 2007, Bob Proulx wrote:
> Mike Frysinger wrote:
> > because the nobody user does not have access to
> > the /full/path/to/the/directory which the new `rm` resides
>
> Ah!  That explains it.
>
> > one of the directories in the absolute tree is actually go-rwx, so i
> > guess the failure cascades from there
>
> Above the tree outside of coreutils or in the tree within coreutils?
> I am assuming it was outside the tree above it?

above the coreutils source/build tree ... so everything under 
coreutils-6.9.90/ is OK ...

> The test should check for this possibility.  Should this be a global
> check for all of the root tests that might use nobody?  Probably.

i thought there was already such a helper function, but i dont know off the 
top of my head ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

preserve-gid (Re: coreutils-6.9.90 test results for x86_64-linux-gnu)

[Bob Proulx]

Mike Frysinger wrote:
> > fchown(4, 0, 1017)  = -1 EPERM (Operation not permitted)
> > fchown(4, 4294967295, 1017) = 0 
> 
> i'm not seeing the second fchown(), just the first

Is this still within the same failure space as the directory that was
go-rwx?  Because if so then I think it means that this got the system
cp instead of the freshly built one.  A cascade failure.  Fixing that
should fix this too.  I hope.

I think the difference is this one:

  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=cbc06bb6390c1

Bob


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

Re: fail-2eperm (was: coreutils-6.9.90 test results for x86_64-linux-gnu)

[Bob Proulx]

Mike Frysinger wrote:
> because the nobody user does not have access to 
> the /full/path/to/the/directory which the new `rm` resides

Ah!  That explains it.

> one of the directories in the absolute tree is actually go-rwx, so i
> guess the failure cascades from there

Above the tree outside of coreutils or in the tree within coreutils?
I am assuming it was outside the tree above it?

The test should check for this possibility.  Should this be a global
check for all of the root tests that might use nobody?  Probably.

Bob


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

Re: coreutils-6.9.90 test results for x86_64-linux-gnu

[Mike Frysinger]

On Monday 03 December 2007, Bob Proulx wrote:
> Mike Frysinger wrote:
> > + echo './../../../tests/cp/preserve-gid: setuidgid -g 1000,1017 1000 cp
> > -p c1 b: 1000 1017 != 1000 1000' ./../../../tests/cp/preserve-gid:
> > setuidgid -g 1000,1017 1000 cp -p c1 b: 1000 1017 != 1000 1000 + exit 1
>
> Can you strace it at this point?  This is what I see on my system.
>
> env PATH=/path/to/coreutils/src:$PATH setuidgid -g 1001,1017 1001 strace
> -e fchown cp -p c1 b
> fchown(4, 0, 1017)  = -1 EPERM (Operation not permitted)
> fchown(4, 4294967295, 1017) = 0 

i'm not seeing the second fchown(), just the first ... full strace attached
-mike


signature.asc
Description: This is a digitally signed message part.


cp.strace.out.lzma
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: fail-2eperm (was: coreutils-6.9.90 test results for x86_64-linux-gnu)

[Mike Frysinger]

On Monday 03 December 2007, Bob Proulx wrote:
> Mike Frysinger wrote:
> > running as root i see these test failures:
> > pretty sure the first one is known
> > FAIL: fail-2eperm.log (exit: 1)
>
> + rm --version
> rm (GNU coreutils) 6.9.90
> +++ id -u nobody
> ++ coreutils_non_root_uid=65534
>
> Looks like your nobody user is 65534 which is typical.
>
> > + rm_version=6.9
>
> Shouldn't that say 6.9.90?  I get 6.9.90.  The log showed 6.9.90
> earlier.
>
> The code is:
>
>   rm_version=`setuidgid $NON_ROOT_USERNAME env PATH="$PATH" rm
> --version|sed -n '1s/.* //p'`
>
> Try this:
>
>   ./src/rm --version | sed 1q
>   rm (GNU coreutils) 6.9.90
>
>   ./src/setuidgid nobody env PATH=$PWD/src:$PATH rm --version | sed -n
> '1s/.* //p' 6.9.90
>
> Can you look at that more closely and figure out why the output is
> inconsistent?

because the nobody user does not have access to 
the /full/path/to/the/directory which the new `rm` resides

one of the directories in the absolute tree is actually go-rwx, so i guess the 
failure cascades from there
-mike


signature.asc
Description: This is a digitally signed message part.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

preserve-gid (Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0)

[Bob Proulx]

Elias Pipping wrote:
> FAIL: preserve-gid.log (exit: 1)

Here is the failure, the "good parts" version:

> + nameless_uid=1000
> + nameless_gid1=1000
> + nameless_gid2=1001

What range is the normal user range for your system?  Because it looks
like your system has no non-root users but I assume they are simply in
a different id range such as down in the 100 or 500 numbers.

> + chown +1000 .
> + echo a0
> + chown +0:+0 a0
> + cp a0 b
> ++ stat -c '%u %g' b
> + s='0 20'
> + test 'x0 20' '!=' 'x0 0'
> + echo './preserve-gid: cp a0 b: 0 0 != 0 20'
> ./preserve-gid: cp a0 b: 0 0 != 0 20

Can you try this?  This is a slightly modified form of the above.  It
is explicitly setting the group of the test directory to group 20
whereas in the above I think it is happening arbitrarily.

  mkdir preserve-gid
  cd preserve-gid
  chown +1000:+20 .
  echo a0 > a0
  ls -ld . a0
  chown +0:+0 a0
  cp a0 b
  ls -ld . a0 b

I don't see where in the test it is setting the group of the
directory.  A BSD based system I expect would create the new file with
the same group as the parent directory.  When b is copied I don't see
where the group would be getting set explicitly and so it will inherit
the directory group.  It looks like the group is inheriting your users
group of 20.

Then try again with this modification.  If this passes then we can fix
the test.

  chown +1000:+0 .
  echo a0 > a0
  ls -ld . a0
  chown +0:+0 a0
  cp a0 b
  ls -ld . a0 b
  test "x`stat -c '%u %g' b`" = 'x0 0' && echo passed || echo failed

> + chmod -R u+rwx 
> /Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.xoMcxRWTmq
> + rm -rf /Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.xoMcxRWTmq
> rm: cannot remove 
> `/Users/pipping/coreutils-6.9.90/tests/cp/cu-preserve-gid.xoMcxRWTmq': 
> Operation not permitted

This does not seem like it should have failed when run by root.
What type of a filesystem is /Users ?  Is that local or networked?

Thanks
Bob


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

Qustions about CPU usage of "dd" process

[Shane Huang]

Greetings:

This is Shane, I'm sorry to disturb you guys.

I have some questions which are about CPU usage percentage of "dd"
process.
I'm appreciated if you can give me some help or suggestion.

When we do some test on our motherboards, we find that in some cases,
the CPU usage percentage of "dd" is a little high when we dump data
from SATA ODD DVD disc to SATA HDD:
# dd if=/dev/cdwriter of=/root/temp.iso

The CPU percentage of "dd" process sometimes is 30% to 50%,
which is higher than we expect (<= 20%), and there is no other big
program running at the same time.
If the disc in SATA ODD is CD-R instead of DVD-R, the percentage is
much smaller(<=20).

So my questions are:
(1) Is there an official normal range(or criteria) to the "dd" CPU
percentage?
(2) Can we say that it's abnormal if it is higher than 30% or even 50%?
(3) And what kinds of factors lead to the high CPU percentage of "dd"
and
how to decrease it?


BTW, my HW/SW Env:
AMD SB700 + RS690
SAMSUNG SATA ODD
Seagate SATA HDD
RedHat RHEL5/RHEL4.6 and openSUSE10.3 Linux


Thanks
Best Regards
Shane





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

special-bits (Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0)

[Bob Proulx]

Elias Pipping wrote:

Here is the failure, the "good parts" version:

>  * special-bits
> ++ : nobody
> +++ id -u nobody
> ++ coreutils_non_root_uid=4294967294
> + touch a b c
> + chmod u+sx,go= a
> + chmod u=rwx,g=sx,o= b
> + chmod a=r,ug+sx c
> + chown nobody .
> + chmod u=rwx,g=rx,o=rx .
> + fail=0
> + cp -p a a2
> cp: `a': No such file or directory
> + fail=1

The touch and chmod created a file and set the mode bits but then cp
is complaining that it does not exist.  Can you run this set of
commands?

  touch a
  chmod u+sx,go= a
  chown nobody .
  chmod u=rwx,g=rx,o=rx .
  cp -p a a2
  ls -ld . a

That should fail the same as the test case.  If it does then the ls
should report what was actually created and the permission of the
directory.  I expect to see something like this:

  drwxr-xr-x 2 nobody root 4096 2007-12-03 20:21 .
  -rws-- 1 root   root0 2007-12-03 20:21 a

In which case the "No such file or directory" error is very strange.
The touch and chmod succeeded operating on the file but the cp failed
to open it?

Bob


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

Re: df not for subfs?

[cool_mail]

Hello Phillip,
thanks for your answer, I'will update to 10.3 before new year, but first do any 
important things ... I think about murphy's law ;-)

 Original-Nachricht 
> Datum: Mon, 03 Dec 2007 13:29:21 -0500
> Von: Phillip Susi <[EMAIL PROTECTED]>
> An: "Günter" <[EMAIL PROTECTED]>, bug-coreutils@gnu.org
> Betreff: Re: df not for subfs?

> Bob Proulx wrote:
> > It appears that something failed getting the file system values.  Try
> > debugging this using strace.  The following produces useful debug
> > output on my GNU/Linux system for usb storage devices.
> 
> Most likely that is the case as this subfs does not appear to have been 
> actively maintained since 2004, before the 2.6 kernel series new world 
> plug and play order came about.  I'd suggest updating your distribution 
> to a new one that does not use subfs.
> 
> 

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger


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

Re: bug-coreutils date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Philip Rowlands on 12/3/2007 6:23 PM:
>> I am currently running GNU coreutils 6.9 with Cygwin on Windows XP
>> version "CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57".
> 
> What version of the tzcode package do you have, if any?
> /var/log/setup.log contains this info on my Cygwin installation - I
> don't know the "proper" way to check, which the installer uses.

Checking cygwin packages is as simple as:

cygcheck -c tzcode

If you don't have 2007h-1, you should probably upgrade.  Furthermore, this
is unlikely to be a bug in coreutils; if the problem persists after
upgrading, then the bug lies in the timezone database or in your
environment selecting which portion of the database to use.

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

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHVMDv84KuGfSFAYARAjnWAKCTzLayxtCP+bjHsgylZrmN6Pwq4ACeKWVl
YYd6eOlF9xdX5PmvdlmBh6Y=
=/oUT
-END PGP SIGNATURE-


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

Re: bug-coreutils date command

[Philip Rowlands]

On Mon, 3 Dec 2007, Richard Narum wrote:

I'm not sure if you would call this a bug or not but I'm wondering why 
the GNU date command doesn't have the correct time adjustment for 
daylight savings from years past on its output when using an input 
date string to generate its output.


I am currently running GNU coreutils 6.9 with Cygwin on Windows XP 
version "CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57".


What version of the tzcode package do you have, if any? 
/var/log/setup.log contains this info on my Cygwin installation - I 
don't know the "proper" way to check, which the installer uses.



The following commands shows dates when CST switches to CDT and back.

$ export TZ=CST6CDT


What does this mean? Specifically, without giving the full syntax (e.g. 
"EST5EDT4,116/2:00:00,298/2:00:00") how is the C library to know what 
rules are passed by Congress regarding the DST switchover date?


The usual way is to have a large collection of files giving the 
historical date patterns and gmt offsets. If your system has an old 
(pre-2005?) version of these files, or none at all, date and the 
localtime(3) function it calls can't help.


Could someone shed some light on why maybe additional rules are not 
applied?


I remember being told once that the "CST8CDT" pattern was now broken by 
the Energy Policy Act changes, but I can't find a reference. The best 
thing to do is avoid that syntax and use the location-based files 
instead; e.g. "America/Chicago" for Central Standard/Daylight Time.



Cheers,
Phil


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

Re: Compression Comparison

[Bob Proulx]

Jim Meyering wrote:
> I'm surprised you'd compare in such a pessimistic manner.

The obvious conclusion is that I am a pessimist! :-)  More seriously
though I think that is the proper way to compare the data.  We are
talking about how well compression works which means we have to take
into consideration the data that is being compressed.

> I look at it differently:
> 
> compare download time:
>   going from gzip to lzma, I see a speed-up of 2.39
>   going from bzip2 to lzma, I see a speed-up of 1.55

But when talking about times that are less than a minute is it
significant?  Not to me.  I am sure that my bandwidth wasted to spam
swamps it.

> compare disk usage:
>   going from gzip to lzma, I can store more than twice as much (2.39x) data
>   going from bzip2 to lzma, I can store 55% more data

A 100G disk could hold 10,000 copies of 10M projects.  Compressed
source code projects are not usually what fills up the typical disk.
Being able to store 2.39x more projects means 24,000 copies.  A 100G
disk is now small.  Being able to buy a 500G disk for $100 means being
able to store 50,000 copies.  Combined is 120,000 copies.  "Enough is
equal to a feast."  I won't be disk space limited due to the
relatively small difference in compressed distribution files.

Alternatively a git clone contains the complete history (what was
converted to it) and rests at 53M.  In terms of efficiency it can
reproduce any version in the history very efficiently.

Comparing lzma to gzip does not produce the huge benefit that is
obtained when comparing, for example, git to cvs.  That is clearly so
much improved that it is worth the cost associated with it to move to
it.

I am not unhappy with lzma.  It seems quite reasonable.  I am happy to
use it.  I am just providing a counterpoint to balance some of the
discussion.  But I am not wanting to be too quarrelsome about this
(just a little bit but not too much) so I will quiet down about
it. :-)

Bob


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

bug-coreutils date command

[Richard Narum]

FYI, 

I'm not sure if you would call this a bug or not but I'm wondering why the GNU 
date command doesn't have the correct time adjustment for daylight savings from 
years past on its output when using an input date string to generate its 
output. It seems to have the current rules applied to all dates, i.e. in 2007 
daylight savings starts second Sunday in March and ends the first Sun in 
November while in 2006 it should start on the first Sunday in April ending the 
last Sunday in October. I live in the Central Timezone, TZ=CST6CDT, and have 
found that the time adjustments for previous years don't line up to their 
proper dates. It doesn't seem like there is any daylight savings rules based on 
year. The site http://aa.usno.navy.mil/faq/docs/daylight_time.php has some 
reference to the rules I am talking about. 

I am currently running GNU coreutils 6.9 with Cygwin on Windows XP version 
"CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57". 

The following commands shows dates when CST switches to CDT and back. 

$ export TZ=CST6CDT 
$ i=$(date --date="01/01/2005" +%s) 
$ while true; do date --date="1970-01-01 00:00:00 $i sec UTC"; ((i=$i+86400)); 
done 

Summary: 

Sun Mar 12 00:00:00 CST 2006 (should be Sun Apr 2 00:00:00 CST 2006) 
Mon Mar 13 01:00:00 CDT 2006 (should be Mon Apr 3 01:00:00 CDT 2006) 
Sun Nov 5 01:00:00 CDT 2006 (should be Sun Oct 29 01:00:00 CDT 2006) 
Mon Nov 6 00:00:00 CST 2006 (should be Mon Oct 30 00:00:00 CST 2006) 

Sun Mar 11 00:00:00 CST 2007 
Mon Mar 12 01:00:00 CDT 2007 
Sun Nov 4 01:00:00 CDT 2007 
Mon Nov 5 00:00:00 CST 2007 

What I got out of the above article the rules would be something like the 
following. 

1974 starts Jan 6 ends last Sun in Oct 
1975 starts Feb 23 ends last Sun in Oct 
1976-1986 starts last Sun in Apr ends last Sun in Oct 
1987-2006 starts first Sun in Apr ends last Sun in Oct 
2007- starts second Sun in Mar ends first Sun in Nov 

Could someone shed some light on why maybe additional rules are not applied? 

Thanks, 

Richard Narum, Design/CAD Systems Engineer 
Applied Engineering, Inc. 
1025 Airport Road 
Bismarck, ND 58504 
Phone: 701-255-1137 
Fax: 701-255-1046 
www.ae-solutions.com 
-- 
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Compression Comparison

[Jim Meyering]

[EMAIL PROTECTED] (Bob Proulx) wrote:

> Jim Meyering wrote:
>> To reiterate, here are the sizes:
>>   coreutils-6.9.90.tar.gz8.6 MB
>>   coreutils-6.9.90.tar.bz2   5.6 MB
>>   coreutils-6.9.90.tar.lzma  3.6 MB
>
> I am a hard sell.  It is impressive but not hugely.  The original size
> was 35M and so all of these already make large size reductions.  Let's
> look at the numbers.
>
>  36280320 coreutils-6.9.90.tar
>  12955108 coreutils-6.9.90.tar.Z
>   8996724 coreutils-6.9.90.tar.gz
>   5952780 coreutils-6.9.90.tar.bz2
>   3682634 coreutils-6.9.90.tar.lzma
>
> That yields[1]:
>
>   100% 36280320 coreutils-6.9.90.tar
>64% 12955108 coreutils-6.9.90.tar.Z
>75%  8996724 coreutils-6.9.90.tar.gz
>83%  5952780 coreutils-6.9.90.tar.bz2
>89%  3682634 coreutils-6.9.90.tar.lzma
>
> Let's see that more visually.  Here is a bar graph.
>
>   +--+--+
>   | compress |  |
>   | gzip |= |
>   | bzip2|= |
>   | lzma |  |
>   | true |==|
>   +--+--+

Hi Bob,

I'm surprised you'd compare in such a pessimistic manner.
I look at it differently:

compare download time:
  going from gzip to lzma, I see a speed-up of 2.39
  going from bzip2 to lzma, I see a speed-up of 1.55

compare disk usage:
  going from gzip to lzma, I can store more than twice as much (2.39x) data
  going from bzip2 to lzma, I can store 55% more data


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

Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0

[Elias Pipping]

On Mon, Dec 03, 2007 at 01:16:26PM -0700, Bob Proulx wrote:
> Elias Pipping wrote:
> > Bob Proulx wrote:
> > > Can you try this:
> > >
> > >   echo > foo
> > >   ./src/ginstall foo bar
> > 
> > That fails, too, indeed.
> 
> That is definitely the problem to debug then.
> 
> > However there's no such thing as strace on darwin. there was ktrace
> > in darwin8 and now there's dtrace (the one from solaris) in darwin9
> > but i'm not familiar with it.
> 
> I do not have access to a Darwin machine.  I am not sure who does.
> Can you debug this further?

What should I be looking out for? I tried this out (the test suite, that
is) on a powerpc running darwin8 and it worked fine. darwin has changed
quite a lot from version 8 to 9, and i think those changes are to blame.
although i can't test this, i assume it'd work on an intel mac running
darwin8 as well.
> 
> > PS: please at least CC me, because i'm not subscribed to bug-coreutils
> > and i had a hell of a time finding out the message-id, setting the
> > in-reply-to header correctly (i hope i did) and so on
> 
> I don't know why you would think that I had not done so.  My mail logs
> show that message sent to mail.gentoo.org[140.211.166.183] and queued
> as message 60C31653D5 at Dec 3 04:22:27.  But if that message did not
> reach you then I see no reason this message would either since they
> are addressed the same.  Sorry but that is another problem for you to
> debug.

Nevermind -- I got the message some hours late -- don't know what
happened.


-- Elias


pgpFvDz8NOPgh.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0

[Bob Proulx]

Elias Pipping wrote:
> Bob Proulx wrote:
> > Can you try this:
> >
> >   echo > foo
> >   ./src/ginstall foo bar
> 
> That fails, too, indeed.

That is definitely the problem to debug then.

> However there's no such thing as strace on darwin. there was ktrace
> in darwin8 and now there's dtrace (the one from solaris) in darwin9
> but i'm not familiar with it.

I do not have access to a Darwin machine.  I am not sure who does.
Can you debug this further?

> PS: please at least CC me, because i'm not subscribed to bug-coreutils
> and i had a hell of a time finding out the message-id, setting the
> in-reply-to header correctly (i hope i did) and so on

But I *did* address the message directly to you and the mailing list.
I don't know why you would think that I had not done so.  My mail logs
show that message sent to mail.gentoo.org[140.211.166.183] and queued
as message 60C31653D5 at Dec 3 04:22:27.  But if that message did not
reach you then I see no reason this message would either since they
are addressed the same.  Sorry but that is another problem for you to
debug.

> PPS: couldn't CC you because i don't know your email address, again
>  because of the above reason

That is okay.  I don't need a CC since I read the mailing list.

Bob


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

Re: df not for subfs?

[Phillip Susi]

Bob Proulx wrote:

It appears that something failed getting the file system values.  Try
debugging this using strace.  The following produces useful debug
output on my GNU/Linux system for usb storage devices.


Most likely that is the case as this subfs does not appear to have been 
actively maintained since 2004, before the 2.6 kernel series new world 
plug and play order came about.  I'd suggest updating your distribution 
to a new one that does not use subfs.






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

Re: coreutils ls

[Vitaly V. Ch]

On Dec 3, 2007 12:26 PM, Vitaly V. Ch <[EMAIL PROTECTED]> wrote:

>
>
> On Dec 3, 2007 12:06 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
>
> > Micah Cowan <[EMAIL PROTECTED]> writes:
> >
> > > Bob Proulx wrote:
> > >> Vitaly V. Ch wrote:
> > >>> As I understand  ls require null-separated format of output stream
> > which
> > >>> will suitable for xargs.
> > >>>
> > >>> in this case I systematically use find instead of ls.
> > >>
> > >> Your message seems to be garbled and I, and perhaps others on the
> > >> mailing list too, cannot understand what you are trying to say.  If
> > >> you have a bug please describe the problem such that we can recreated
> > >> it.  If you are requesting a feature then try to state the feature
> > >> request in such a way that other people can understand it.  Thanks.
> > >
> > > It reads to me like a request for ls to produce null-separated output,
> > > so that
> > >
> > >  $ ls -0 .
> >
> > This comes close:
> >
> > $ printf "%s\0" *
>
>
> as far as I understand it's will not work if the total size of filenames
> in current directory is more then 32K bytes
>

bash-3.1# /usr/bin/printf "%s\0" *
bash: /usr/bin/printf: Argument list too long
bash-3.1#


>
>
> >
> >
> > Andreas.
> >
> > --
> > Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
> > SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> > PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> >
> > "And now for something completely different."
> >
>
>
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0

[Elias Pipping]

On Sun, Dec 02, 2007 at 07:29:49PM +0100, Elias Pipping wrote:
> On Sun, Dec 02, 2007 at 09:05:05AM -0800, Paul Eggert wrote:
> > Elias Pipping <[EMAIL PROTECTED]> writes:
> > 
> > > coreutils-6.9.90 fail a single test, help-version, on 
> > > i386-apple-darwin9.1.0.
> > 
> > Can you please try running that test in verbose mode?  Like this:
> > 
> > cd misc
> > VERBOSE=yes make TESTS=help-version check

I've just run the check-root test suite, with these two tests failing:

 * preserve-gid
 * special-bits

I've attached the (verbose) logs.


-- Elias
FAIL: special-bits.log (exit: 1)


+ cp --version
cp (GNU coreutils) 6.9.90
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
+ PRIV_CHECK_ARG=require-root
+ . ./../priv-check
++ case "$PRIV_CHECK_ARG" in
++ who='as root'
+++ id -u
++ my_uid=0
++ test 0 = 0
++ case $my_uid in
++ test 0 = 0
++ : nobody
+++ id -u nobody
++ coreutils_non_root_uid=4294967294
++ test 0 = 0
++ test 4294967294 = 0
++ give_msg=no
++ case $PRIV_CHECK_ARG:$my_uid in
++ test no = yes
+ . ./../test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++ test_dir_=/Users/pipping/coreutils-6.9.90/tests/cp
+++ this_test_
+++ echo ././special-bits
+++ sed 's,.*/,,'
++ this_test=special-bits
++ . ./../envvar-check
+++ as_unset=unset
+++ envvar_check_failed=0
+++ vars='
  _POSIX2_VERSION
  BLOCKSIZE
  BLOCK_SIZE
  CDPATH
  COLUMNS
  DF_BLOCK_SIZE
  DU_BLOCK_SIZE
  LS_BLOCK_SIZE
  LS_COLORS
  POSIXLY_CORRECT
  QUOTING_STYLE
  SIMPLE_BACKUP_SUFFIX
  TABSIZE
  TERM
  TIME_STYLE
  TMPDIR
  VERSION_CONTROL
'
+++ for var in '$vars'
+++ unset _POSIX2_VERSION
+++ eval test '"${_POSIX2_VERSION+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset BLOCKSIZE
+++ eval test '"${BLOCKSIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset BLOCK_SIZE
+++ eval test '"${BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset CDPATH
+++ eval test '"${CDPATH+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset COLUMNS
+++ eval test '"${COLUMNS+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset DF_BLOCK_SIZE
+++ eval test '"${DF_BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset DU_BLOCK_SIZE
+++ eval test '"${DU_BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset LS_BLOCK_SIZE
+++ eval test '"${LS_BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset LS_COLORS
+++ eval test '"${LS_COLORS+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset POSIXLY_CORRECT
+++ eval test '"${POSIXLY_CORRECT+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset QUOTING_STYLE
+++ eval test '"${QUOTING_STYLE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset SIMPLE_BACKUP_SUFFIX
+++ eval test '"${SIMPLE_BACKUP_SUFFIX+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TABSIZE
+++ eval test '"${TABSIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TERM
+++ eval test '"${TERM+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TIME_STYLE
+++ eval test '"${TIME_STYLE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TMPDIR
+++ eval test '"${TMPDIR+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset VERSION_CONTROL
+++ eval test '"${VERSION_CONTROL+set}"' = set
 test '' = set
+++ test '' = 1
+++ /Users/pipping/coreutils-6.9.90/src/mktemp -d 
--tmp=/Users/pipping/coreutils-6.9.90/tests/cp cu-special-bits.XX
++ t_=/Users/pipping/coreutils-6.9.90/tests/cp/cu-special-bits.0r5WYmPw89
++ trap 'st=$?; cleanup_; 
d=/Users/pipping/coreutils-6.9.90/tests/cp/cu-special-bits.0r5WYmPw89;
cd /Users/pipping/coreutils-6.9.90/tests/cp && chmod -R u+rwx "$d" && rm 
-rf "$d" && exit $st' 0
++ trap '(exit $?); exit $?' 1 2 13 15
++ cd /Users/pipping/coreutils-6.9.90/tests/cp/cu-special-bits.0r5WYmPw89
++ diff --version
++ grep GNU
+ touch a b c
+ chmod u+sx,go= a
+ chmod u=rwx,g=sx,o= b
+ chmod a=r,ug+sx c
+ chown nobody .
+ chmod u=rwx,g=rx,o=rx .
+ fail=0
+ cp -p a a2
cp: `a': No such file or directory
+ fail=1
++ ls -l a
+ set _ -rws-- 1 root staff 0 2007-12-03 12:05 a
+ shift
+ p1=-rws--
++ ls -l a2
+ set _ -rwx-- 1 root staff 0 2007-12-03 12:05 a2
+ shift
+ p2=-rwx--
+ test -rws-- = -rwx--
+ fail=1
+ cp -p b b2
cp: `b': No such file or directory
+ fail=1
++ ls -l b
+ set _ -rwx--s--- 1 root staff 0 2007-12-03 12:05 b
+ shift
+ p1=-rwx--s---
++ ls -l b2
+ set _ -rwx-- 1 root staff 0 2007-12-03 12:05 b2
+ shift
+ p2=-rwx--
+ test -rwx--s--- = -rwx--
+ fail=1
+ setuidgid nobod

Re: coreutils ls

[Andreas Schwab]

"Vitaly V. Ch" <[EMAIL PROTECTED]> writes:

> bash-3.1# /usr/bin/printf "%s\0" *
> bash: /usr/bin/printf: Argument list too long
> bash-3.1#

Use the builtin printf.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


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

Re: coreutils ls

[Vitaly V. Ch]

On Dec 3, 2007 12:06 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:

> Micah Cowan <[EMAIL PROTECTED]> writes:
>
> > Bob Proulx wrote:
> >> Vitaly V. Ch wrote:
> >>> As I understand  ls require null-separated format of output stream
> which
> >>> will suitable for xargs.
> >>>
> >>> in this case I systematically use find instead of ls.
> >>
> >> Your message seems to be garbled and I, and perhaps others on the
> >> mailing list too, cannot understand what you are trying to say.  If
> >> you have a bug please describe the problem such that we can recreated
> >> it.  If you are requesting a feature then try to state the feature
> >> request in such a way that other people can understand it.  Thanks.
> >
> > It reads to me like a request for ls to produce null-separated output,
> > so that
> >
> >  $ ls -0 .
>
> This comes close:
>
> $ printf "%s\0" *


as far as I understand it's will not work if the total size of filenames in
current directory is more then 32K bytes


>
>
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-6.9.90 fail 1/84 (help-version) on i386-apple-darwin9.1.0

[Elias Pipping]

Bob Proulx wrote:
> Can you try this:
>
>   echo > foo
>   ./src/ginstall foo bar

That fails, too, indeed. However there's no such thing as strace on
darwin. there was ktrace in darwin8 and now there's dtrace (the one from
solaris) in darwin9 but i'm not familiar with it.


-- Elias

PS: please at least CC me, because i'm not subscribed to bug-coreutils
and i had a hell of a time finding out the message-id, setting the
in-reply-to header correctly (i hope i did) and so on
PPS: couldn't CC you because i don't know your email address, again
 because of the above reason


pgpmX1cxnjOXx.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils ls

[Andreas Schwab]

Micah Cowan <[EMAIL PROTECTED]> writes:

> Bob Proulx wrote:
>> Vitaly V. Ch wrote:
>>> As I understand  ls require null-separated format of output stream which
>>> will suitable for xargs.
>>>
>>> in this case I systematically use find instead of ls.
>> 
>> Your message seems to be garbled and I, and perhaps others on the
>> mailing list too, cannot understand what you are trying to say.  If
>> you have a bug please describe the problem such that we can recreated
>> it.  If you are requesting a feature then try to state the feature
>> request in such a way that other people can understand it.  Thanks.
>
> It reads to me like a request for ls to produce null-separated output,
> so that
>
>  $ ls -0 .

This comes close:

$ printf "%s\0" *

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


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

Re: coreutils ls

[Vitaly V. Ch]

On Nov 30, 2007 11:58 PM, Micah Cowan <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bob Proulx wrote:
> > Vitaly V. Ch wrote:
> >> As I understand  ls require null-separated format of output stream
> which
> >> will suitable for xargs.
> >>
> >> in this case I systematically use find instead of ls.
> >
> > Your message seems to be garbled and I, and perhaps others on the
> > mailing list too, cannot understand what you are trying to say.  If
> > you have a bug please describe the problem such that we can recreated
> > it.  If you are requesting a feature then try to state the feature
> > request in such a way that other people can understand it.  Thanks.
>
> It reads to me like a request for ls to produce null-separated output,
> so that


Yes, it is.

>
>
>  $ ls -0 .


which ls can  understand it? on my system:

 bash-3.1# LANG= ls -0 .
ls: invalid option -- 0
Try `ls --help' for more information.
bash-3.1# LANG= ls --version
ls (GNU coreutils) 6.9
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License .
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Stallman and David MacKenzie.
bash-3.1#

>
>
> will produce output like
>
>  $ find . -print0 -maxdepth 1
>
> Vitaly: note that both find's -print0 and xarg's -0 are GNU extensions,
> and are not portable.


I know it.  I do not use non-GNU systems.

>
>
> And, if find does the job, then why do you need a second tool to be able
> to accomplish the same thing?


find is extra-power but ls is simple:)

>
>
> - --
> Micah J. Cowan
> Programmer, musician, typesetting enthusiast, gamer...
> http://micah.cowan.name/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHUIdv7M8hyUobTrERApeCAJ96OSHf2LaJ3rQPdPbK1BHMZucu9gCfchuW
> /UYB8IciNH7QH80O2p/XcNg=
> =NKV9
> -END PGP SIGNATURE-
>
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils