date,,,

2008-04-24 Thread Gnthoralf 
Hello,
I have the following bug in date,
if I type date +%s the unixtimestamp is correct, but if I type "date" then I
have 23 sec difference. I use suse 9 distro, with ntpd.
date version is date (GNU coreutils) 5.93.
Can you helpe me and say, how I can fix it ?
regards,
Thoralf Roch


--
Mit freundlichen Grüßen
T.Roch
Tel 01632583241
email [EMAIL PROTECTED]
msn [EMAIL PROTECTED]

http://www.xing.com/profile/Thoralf_Roch2"; target="_blank">http://www.xing.com/img/buttons/6_de_btn.gif"; width="118" height="23"
alt="XING" border="0" />


-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.2 (GNU/Linux)

mIsERq2P1AEEAKnYh7yis5xF+2UpPMdgaE4uRMKJAw6quqwO/VPFASVQWAVakhNj
qTOCpCOexuwyWcbb5YrwcHvFFXPOSUUvVuQyJ1/VVI4AnckJRjG5uk83dYHhfAT4
oK9zwen7NopXyNLrGY+ejq3g4Vhpo+EJQqPLbU7j3DyJu+skgx2mRuTvAAYptBxU
aG9yYWxmIDx0aG9yYWxmQGdlcmFuZXQuZGU+iLMEEwECAB0FAkatj9QGCwkIBwMC
BBUCCAMEFgIDAQIeAQIXgAAKCRAHb6lkhO5Lrpp0BACWqEqiD3CqMgqTYh7lSaZC
95UTaqepfPnRS9vTICpGwENBvrN0p4tWnlFrfjWX71ySqdnJJbromI+U4VUN8tCb
1yUxwaoJFjWiXEdWQxS9ROVC+MJ4lEOfpQiH+m8FbranJuYVqO4Lr6ILPtKD/s12
5MB8n8DeZ5vsIGW69A6qz9HKLsosARAAAQEAAAD/2P/gABBKRklG
AAEBAQBgAGAAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRoc
HCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIh
HCEyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMv/AABEIALkAjAMBIgACEQEDEQH/xAAcAAEAAQUBAQAAAwIE
BQYHAQj/xAA9EAABAwIFAAYIBQMCBwABAAIDBBEFBhIhMRNBUVKR0QcWVmFx
gZShFCIyscEVI0IkYjNTVbLS8PH/xAAZAQEBAQEBAQAAAgEDBAX/
xAAhEQEBAAICAgIDAQAAAQIRAxMSYQQxIUFRgf/aAAwDAQACEQMRAD8A
7+iIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiDzW
3vDxTW3vDxXFrKoBc+z06dft2fW3vDxTW3vDxXGrKq2ydno6/bsetveHimtveHiu
O2XhCdno8HY9be8PFNbe8PFcasvCE7PR4Oza294eK81t7w8Vxc/FUlOz0eDtWtve
HimtveHiuJkKg9adno8Hb9be8PFNbO83xXDnKNydno8HddbO83xTWzvN8VwV291G
etOw8HftbO+3xTpGd9vivnx/Kgc3dOw8GygbqoBehqlaxc9Om1IavdKlDdlWGLdJ
2h0rwtVwY1HUPjp4XyyuDI2Auc48ABNG2Prq2noI9c8rGD/cbLQ8b9JdNAJYsMYZ
pNg2Rws0dp7StdzrmqLGastotYpxcFzuXfDsC06xJ4VzH+pyy/jY6jPOPzyteavQ
AQdLWgBZbBPSHXx1w/qcrZKY7WDQCPfstJ0nlwJHCoeLf4kfFV4xPlX0HQYjSYpT
CejnZKy+5aeD7+xXDguIZYzDNgGItkBLqd5AlZ2jtHvXb45GTwsljcHRvaHNcOCC
Niudx0uZbUuCicFO4bqNwUqQOHKicOVORdRuCC3eOVGRupnDlRkboNnaFMxm6oYN
lcxt3VyMtetj2UrYtlLHHcFXDYhbhVpFq1MW3C070k1rsPylUNa03qCIrjqvz9rr
fnRbcLUfSFhJxHKVWAPzQDpxtzpG/wBrpYSuBUOFS4g+zHNaB1lbRh+RzPCekmaH
f42/lYnAXEYk5vDAF0TC5LWc1wN/evPycmUy09fFxY5Y7ayfR3VveXGdjQXHb3KO
qyPFDGP751W3twSugve7rA+ZWDxWshi1GWeNtuq6m8mX6VOHCfbl2JYU/D5SzUDb
ddWyFiBr8rQscSX0zjCSewbj7ED5LnGYJmzVDJ4nh7DtcLp2SKBtDlemdaz6i8zv
nx9rLvLbjNvNljMc7Iz7lE4bqVyjd1rGInDdRPCmdyonDZY1C8bqI8qZwUZ5QbO3
jZXkXIVi0q8hduukTWQhbYK7Y29irGJ9iFeRvGypFSub+XcdSx+IMBo6i7Q4dG67
XC4O3BV6940fJW0rgQQRcHqSsfN7MNP4mrYHFo1C+jrHNgp6fD3STNMTJ6dobfU2
Ug37OFsmNUTMNzFNA1oawPOkf7TuPsbfJXDIomxGRxAAHUvHc7Lqvp48WOU3FpHO
6PDZ4JJ5JHsOkSF2+/vWGqsHayoEsLWS6jd7njVce6+11k4YjNTTkDY7/AKXD3Nm
p3RybPZ19qnHOz8uufFjZGr12Hf6ZxdG2ORxBLW8eC6flp0n9ChZI8uMf5Gm1thx
5LS8Ss2eNpPBvf4Lf8MgNLhlPE7Zwbd3xO5/ddcLa8nNjMV0VGSqiVQ4ro86hyid
sFW5yjcVjUbuVEeVI47qI8oNja6yumPCsA5TteriayMcvCuWzWWKbIQpxKq2isg6
a45ULpeVbdLsqHSXBWjVM/0ccmHNxFsdp4XtaXjuE9fzWmfip3U5cz8zRyByuiZl
mpRgVU2rcGxyN6Nt+txNm/ey5RHNNh9U+CdpaWnSQV5+XHd29XDnqaXcEtKWPJ6W
55ABsVTBODUObTtc1truvsFdRwsnu6GUNv8AqCs6uSKljc1h/MT8yVz+3qtxk2yW
CxNr8xwNlb0jIg57gdxtwfGy38uWhZNlbBVyz1B0CoIhiJ/ydzZby4rtjNR4eTLe
Sou2UZPK8JVJctRKpcbg3VBOy9LrqNx2RqhxUd91U4qO+5RrOat1K1+6tNW6rDlS
V06dsbC57g1o5LjYBYmrzngFESJcThLh1RXk/wC265x6Qsckq8WOHRyH8PTW1AHZ
zzub/DjxWmEqpEWuuV3pVw2FpFHSVFQ7tfaNv8n7LU8R9JePVd207oaRh/5TLu8X
X+1lpxK8VaZtlf61iOIV1KK6tnqGMma4NkkJA3HUuvVmW6fHaJrxZlU1tmyd4djv
NcNabOBGxC77gFU52DQSsLC+SNpZqNgSQozx26cd05/WYFV4fO6GVskTh77Aq+wj
J8+IydNPqjph+qR3Lvc3zVjX1WKzYxPBiD3sqHPGtp3bvxbqt2LYMq4lUdNU0cN5
qKIfnmcQAHnqb/71Ly4Zb5PGvqc/xevhnJMpWNzoyOjwYx046IRFnRBpsWkOG9+3
3rAUfpFxanYyOeKCoa0WLnAhzviQbfZZjPx04Xc8ulaPsT/C5wvZJNPkWunUnpHw
+WwqqWeA9rbPH8H7LN0+ZcGrB/axGAE9T3aD4OsuLryyXGMmTuzKiGa/RSskA7rg
V6SuGwVE1LKJYJXxvB2cx1iutYDigxXBoagkGW2mUDqcOfHn5qbjpcy2ybzuo77r
15Ud1KmX1brFZmxJ2F5erKmN2mUN0xnrDibXHwvf5K3zJjT8GwaSqia10pcGMDuA
T1n7rlWI41iOKn/W1T5Wg3DSbNB9wGyuRFqyLi43O5PJKKleq0HKIiD1dgyLK6ry
zStd+mLUwn4E/wAWXH1030a1oZg9bE4n+3LqHuuB5LKrH7XOa3ROq2Rtv00NO+Qu
J3FyAP2KzeX8MgpcIomxf8N8TZXe8kbkrR6ipfWZgrnuJIlY5jb9gBt+wWfyRjJM
Bw6dxLonXiJ7t+Plf7rycWcvJfb7PyvjZYfGxk/X3/rFekpzY4aOEH9cjn+AH/ku
dFb96TrfjMPHX0bj+y0JeyPi37eIUtZEYLask4nFSV01LPLobUBui/BcP/q1UrzU
Q64NiOCFlmx2tztyoy7fhWWG1zK/DIKljtRcwavc7r+6ndJuubpK+gKnKeXayIRV
OB4dNGDfTJTMcL9u4Vr6gZP9lsG+ij8lsSLq5td9QMn+y2DfRR+SeoOT/ZfB/oo/
JbEiDXfUHJ/stg/0UfknqDk/2Xwf6KPyWxIg131Byf7L4P8ARR+SuKXKGW6IPFLg
OGwCS2sR0rG6vjYe8rNIgwgydlkSdIMv4Zr734Vl/wBl7DlDLVPKJIcAwyOQcOZS
sB/ZZpFnjP4u8ud/FtYWryhlqvc11XgGGTuaLNMtKx1vEK39Qcn+y+D/AEUfktiR
ahrvqDk/2Wwb6KPyT1Ayf7LYN9FH5LYkQa76g5P9l8H+ij8l56gZO9lsG+ij8lsa
IMJT5OyzSNLafAMMia43IZSsF/AKX1XwD/ouH/Ts8llkQEREBERAREQEREBERARE
QEREBERAREQEREBERAREQEREBERAREQEREBERAREQf/ZiLYEEwECACAFAkatj+YC
Gy8GCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAHb6lkhO5Lrr77A/9T8okWwzb7
K4sUC08I5QplDitRlVZ/cAuhLFiQl

Re: date,,,

2008-04-24 Thread Eric Blake 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Gnthoralf on 4/24/2008 2:13 AM:
| Hello,
| I have the following bug in date,
| if I type date +%s the unixtimestamp is correct, but if I type "date" then I
| have 23 sec difference. I use suse 9 distro, with ntpd.

Sounds like it might be due to the number of leap seconds that have
occurred since 1970?

| date version is date (GNU coreutils) 5.93.

Consider upgrading; the latest stable version is 6.11 (although it is
unlikely to change the behavior you observe).

| -BEGIN PGP PUBLIC KEY BLOCK-
| Version: GnuPG v1.4.2 (GNU/Linux)
|
| mIsERq2P1AEEAKnYh7yis5xF+2UpPMdgaE4uRMKJAw6quqwO/VPFASVQWAVakhNj

Wow - your mail has a higher percentage of line noise than content; you
may want to consider posting merely an URL to your public key rather than
sending the entire ascii-armored block in every mail; particularly since
your mail wasn't even gpg signed.

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

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

iEYEARECAAYFAkgQh9AACgkQ84KuGfSFAYCvowCeMdHTLD6eeR9ycA+DYoVyihPM
6lQAn0uKjRJML1LcYkQfjUmg2oC8neHO
=sJ+N
-END PGP SIGNATURE-


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

Re: date bug

2008-04-24 Thread Eric Blake 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please keep replies on the list, so that others may chime in.

According to Aganan, Nicholas on 4/24/2008 6:28 AM:
| You said "'last month' is documented to be equivalent to
| 'alter only the month field, then renormalize'" but your computation is
| based on the date. 'last month' should provide the name of the previous
| month with no dates.

You are looking at +%b in isolation.  But the code currently doesn't work
that way.  When -d is encountered, the code computes a complete date,
orthogonal to the date components that are later requested by the + format
string.  Therefore, "last month" on Mar 31 results in Feb 31, which must
be normalized, prior to even looking at what is to be output.

|
| If this month is Mar and you execute the 'last month' parameter the
| expected output should be Feb regardless what date it is.
|
| The best way to test this theory is by asking a person candidly "If this
| month is March, what was last month?" or "What is today's month? What
| was last month?".
|
| If users want to get the date, I think the right parameter is '
| days ago' or ' weeks ago'.

Then please propose a patch to improve date's behavior.  I think it would
be reasonable to make the -d computation be a bit smarter about what
fields need to be normalized based on what fields will be output, but the
task is not trivial, and I am not volunteering for the work.

|
| I found the workaround solution by using '31 days ago' if it is the 31st
| day of the month.

And that is what the manual recommends, too, since it does not result in
an ambiguous date that needs normalization.

|
| I will certainly move to 6.11.
|
| Thanks and more power.
|

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

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

iEYEARECAAYFAkgQgmQACgkQ84KuGfSFAYCjjQCdFz/mOKX1+i3kvbDrdqa4nMTU
e5kAn01/f1IHgDiBnb3ndtNYvsPXNuuR
=JXCP
-END PGP SIGNATURE-


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

Re: id not showing supplementary groups

2008-04-24 Thread Jim Meyering 
Javier Pello <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have just downloaded and installed coreutils-6.11 and I have come
> across a change in behaviour in the id program which does not seem
> to be documented. Specifically, id no longer prints the supplementary
> groups of the current process when invoked without a user argument,
> as in the following example:
>
> ~$ ./coreutils-6.10/src/id -G
> 100 8 10 14
> ~$ ./coreutils-6.11/src/id -G
> 100
>
> Furthermore, the behaviour is not consistent. If the uid of the
> process appears in /etc/passwd, then id shows the groups that uid
> is a member of (as defined in /etc/group); if the uid does not appear
> in /etc/passwd, then id shows the actual supplementary groups of the
> process (which is the right thing to do). I have attached a simple
> program that can be used to check this:
>
> ~# ./a.out 100
> (100:0) 13 17 19
> 0 13 17 19
> ~# ./a.out 101
> (101:0) 13 17 19
> 0 100
> ~# ./a.out 102
> (102:0) 13 17 19
> 0 13 17 19

Hi Javier,

Thanks for the report and patch.
I confess I haven't looked closely at either, but suspect
the problem is fixed in the latest snapshot:

  http://meyering.net/cu/coreutils-ss.tar.gz8.6 MB
  http://meyering.net/cu/coreutils-ss.tar.lzma  3.6 MB
  http://meyering.net/cu/coreutils-ss.tar.gz.sig
  http://meyering.net/cu/coreutils-ss.tar.lzma.sig

Would you please confirm and let us know?

Jim


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

Re: RFE for id(1) -- ability to specify uid/gid values on the command line (reverse lookups)

2008-04-24 Thread James Youngman 
On Thu, Apr 24, 2008 at 2:18 AM, Greg Ercolano <[EMAIL PROTECTED]> wrote:
>  [gnu/linux] $ id 0
>  id: 0: No such user

getent from libc already does this:

$ getent passwd 0
root:x:0:0:root:/root:/bin/bash


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

RE: date bug

2008-04-24 Thread Aganan, Nicholas 
Normally we use '+%' to get the desired information. Why don't we
use '-% to denote the 'last or previous' value or maybe use
'+%-'

Example:
  %-b   locale's abbreviated previous month name (e.g., Jan)
  %-B   locale's full previous month name (e.g., January)
  %-C   previous century; like %Y, except omit last two digits (e.g.,
21)
  %-m   previous month (01..12)
  %-W   previous week number of year, with Monday as first day of week
(00..53)
  %-y   last two digits of the previous year (00..99)
  %-Y   previous year


Sorry, I'm not a programmer, I'm only a SysAd (your end user :). I want
to help but can't do anything.

-Original Message-
From: Eric Blake [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 24, 2008 8:52 AM
To: Aganan, Nicholas; bug-coreutils
Subject: Re: date bug

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please keep replies on the list, so that others may chime in.

According to Aganan, Nicholas on 4/24/2008 6:28 AM:
| You said "'last month' is documented to be equivalent to
| 'alter only the month field, then renormalize'" but your computation
is
| based on the date. 'last month' should provide the name of the
previous
| month with no dates.

You are looking at +%b in isolation.  But the code currently doesn't
work
that way.  When -d is encountered, the code computes a complete date,
orthogonal to the date components that are later requested by the +
format
string.  Therefore, "last month" on Mar 31 results in Feb 31, which must
be normalized, prior to even looking at what is to be output.

|
| If this month is Mar and you execute the 'last month' parameter the
| expected output should be Feb regardless what date it is.
|
| The best way to test this theory is by asking a person candidly "If
this
| month is March, what was last month?" or "What is today's month? What
| was last month?".
|
| If users want to get the date, I think the right parameter is '
| days ago' or ' weeks ago'.

Then please propose a patch to improve date's behavior.  I think it
would
be reasonable to make the -d computation be a bit smarter about what
fields need to be normalized based on what fields will be output, but
the
task is not trivial, and I am not volunteering for the work.

|
| I found the workaround solution by using '31 days ago' if it is the
31st
| day of the month.

And that is what the manual recommends, too, since it does not result in
an ambiguous date that needs normalization.

|
| I will certainly move to 6.11.
|
| Thanks and more power.
|

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

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

iEYEARECAAYFAkgQgmQACgkQ84KuGfSFAYCjjQCdFz/mOKX1+i3kvbDrdqa4nMTU
e5kAn01/f1IHgDiBnb3ndtNYvsPXNuuR
=JXCP
-END PGP SIGNATURE-

*

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from all computers. GA622




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

Re: date,,,

2008-04-24 Thread Bob Proulx 
Gnthoralf wrote:
> I have the following bug in date,
> if I type date +%s the unixtimestamp is correct, but if I type "date" then I
> have 23 sec difference. I use suse 9 distro, with ntpd.

How are you determining that the +%s time is correct?  (I would use
date for this, rather circularly.)

  date -d @1209055313

It seems to me that if 'date +%s' is correct then 'date' should also
be correct.

If you are running ntp then using 'ntpq -p' will print useful
information about the state of ntpd on your system.

  ntpq -p

Perhaps a firewall is blocking your ntp packets and preventing things
from being able to sync the time with other systems?

Bob


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

tsort 6.9, incorrect output

2008-04-24 Thread Guillaume Bailey 


I have an example of the latest tsort producing invalid output. The 
output clearly disobeys the partial ordering 'i k a h g j', because 'a' 
precedes both 'i' and 'k'. There may be other errors.



[EMAIL PROTECTED] toolDependencies]$ tsort --version
tsort (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 Mark Kettenis.
[EMAIL PROTECTED] toolDependencies]$ tsort << EOF
> b k
> b m
> k m f
> i b f
> i k a h g j
> b g c
> h c
> g d
> h d
> h e
> h j l
> c l
> EOF
a
b
c
d
e
f
g
h
i
j
k
l
m 



Guillaume

--

Guillaume Bailey
Software Engineer II
Lymba Corporation
[EMAIL PROTECTED]
1701 N. Collins Blvd. Ste. 3000
Richardson, TX 75080
Phone: +1 972 680 0800 ext. 105
Fax:   +1 972 680 0808
Cell:  +1 214 502 5664
AIM:   GuillaumeLCC
MSN:   [EMAIL PROTECTED]


begin:vcard
fn:Guillaume Bailey
n:Bailey;Guillaume
org:Lymba Corporation;NLP Research
adr:;;1701 N. Collins Blvd. Ste. 3000;Richardson;TX;75080;United States of America
email;internet:[EMAIL PROTECTED]
title:Software Engineer II
tel;work:+1 972.680.0800.x105
tel;fax:+1 972.680.0808
tel;cell:+1 214.502.5664
x-mozilla-html:TRUE
url:http://www.Lymba.com/
version:2.1
end:vcard

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

Re: id not showing supplementary groups

2008-04-24 Thread Javier Pello 
Hi,

> I confess I haven't looked closely at either, but suspect
> the problem is fixed in the latest snapshot:

> Would you please confirm and let us know?

I can confirm that the problem is now fixed. In fact, looking
at the code, I can see that there are changes that indirectly
include my proposed patch.

Thanks,
Javier


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

Re: tsort 6.9, incorrect output

2008-04-24 Thread Jim Meyering 
Guillaume Bailey <[EMAIL PROTECTED]> wrote:
> I have an example of the latest tsort producing invalid output. The

6.9 is over two years old.
The latest coreutils release is coreutils-6.11.

> output clearly disobeys the partial ordering 'i k a h g j', because
> a' precedes both 'i' and 'k'. There may be other errors.
...
>> [EMAIL PROTECTED] toolDependencies]$ tsort << EOF
>> > b k
>> > b m
>> > k m f
>> > i b f
>> > i k a h g j
>> > b g c
>> > h c
>> > g d
>> > h d
>> > h e
>> > h j l
>> > c l
>> > EOF

Thanks for the report, but you have misunderstood
tsort's input format.  From "info tsort",

   `tsort' reads its input as pairs of strings, separated by blanks,
indicating a partial ordering.  The output is a total ordering that
corresponds to the given partial ordering.

Note the "as pairs of strings".
The placement of newline characters is irrelevant.
So the input above is equivalent to this:

  b k b m k m f i b f i k a h g j b g c h c g d h d h e h j l c l

and this:

  b k
  b m
  k m
  f i
  b f
  i k
  a h
  g j
  b g
  c h
  c g
  d h
  d h
  e h
  j l
  c l


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

Re: date,,,

2008-04-24 Thread Eric Blake 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Please keep the lists involved in replies, so that others may participate
in the thread]

According to [EMAIL PROTECTED] on 4/24/2008 12:01 PM:
| | if I type date +%s the unixtimestamp is correct, but if I type
| "date" then I
| | have 23 sec difference. I use suse 9 distro, with ntpd.
|
| Sounds like it might be due to the number of leap seconds that have
| occurred since 1970?

| its correct, If  I update with ntpdate the time is 23 sec to late, on
| the other hand I hav install an other pc , with the same linux distro,
| and this computer work correct.
| its possible that any configfiles make this mistake ?
| regards,

I don't think this is a coreutils bug, but probably a difference in
configuration of whether you are enabling leap second support between the
two machines.  But I personally don't know how to do that, so hopefully
someone else can step in and give more advice.

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

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

iEYEARECAAYFAkgQ2QwACgkQ84KuGfSFAYBsiQCgpj/2j4DjZ16qBCOBo/4SxBIe
wqoAoLkFQOyE5rWUzIig96ZodaKqb/FF
=gdAu
-END PGP SIGNATURE-


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

"cp --no-preserve=mode" doesn't work as-expected

2008-04-24 Thread CJ Kucera 
Hello...  I've run into a problem best described by a post to this list
from 2003:

> When the destination file does not exist cp uses the permissions of the
> source file for creating the destination, as specified by POSIX.  Wouldn't
> it be useful if --no-preserve=mode would cause cp to use the default
> permissions (ie. 0666 - umask) instead?

It was said at the time[1] that it'd be taken care of soon, but either
it never was, or the older behavior's crept back into the tree as of
6.11.  It'd be great to have this behavior changed.  It would be quite
useful to be able to copy files from readonly media (cd/dvd/etc) and not
have to chmod afterwards.

Thanks!

-CJ

[1] http://lists.gnu.org/archive/html/bug-coreutils/2003-02/msg00051.html


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

Re: tsort 6.9, incorrect output

2008-04-24 Thread Guillaume Bailey 

   Ah, I see now. I suggest a different example in the info page, since:
 * the example doesn't prevent my misunderstanding (it evaluates the same
   either way)
 * topological sorts are part of graph theory; I was trying to give a
   topological ordering to a 'dot' graph file, by simply removing the '->'
   arrows. There's a superficial similarity between the example and a dot
   file.

   Here's a simple clarified example:

For example
  tsort < wrote:


I have an example of the latest tsort producing invalid output. The


6.9 is over two years old.
The latest coreutils release is coreutils-6.11.



output clearly disobeys the partial ordering 'i k a h g j', because
a' precedes both 'i' and 'k'. There may be other errors.


...


[EMAIL PROTECTED] toolDependencies]$ tsort << EOF


b k
b m
k m f
i b f
i k a h g j
b g c
h c
g d
h d
h e
h j l
c l
EOF


Thanks for the report, but you have misunderstood
tsort's input format.  From "info tsort",

   `tsort' reads its input as pairs of strings, separated by blanks,
indicating a partial ordering.  The output is a total ordering that
corresponds to the given partial ordering.

Note the "as pairs of strings".
The placement of newline characters is irrelevant.
So the input above is equivalent to this:

  b k b m k m f i b f i k a h g j b g c h c g d h d h e h j l c l

and this:

  b k
  b m
  k m
  f i
  b f
  i k
  a h
  g j
  b g
  c h
  c g
  d h
  d h
  e h
  j l
  c l


--

Guillaume Bailey
Software Engineer II
Lymba Corporation
[EMAIL PROTECTED]
1701 N. Collins Blvd. Ste. 3000
Richardson, TX 75080
Phone: +1 972 680 0800 ext. 105
Fax:   +1 972 680 0808
Cell:  +1 214 502 5664
AIM:   GuillaumeLCC
MSN:   [EMAIL PROTECTED]

References

   1. mailto:[EMAIL PROTECTED]
   2. mailto:[EMAIL PROTECTED]
   3. mailto:[EMAIL PROTECTED]
begin:vcard
fn:Guillaume Bailey
n:Bailey;Guillaume
org:Lymba Corporation;NLP Research
adr:;;1701 N. Collins Blvd. Ste. 3000;Richardson;TX;75080;United States of America
email;internet:[EMAIL PROTECTED]
title:Software Engineer II
tel;work:+1 972.680.0800.x105
tel;fax:+1 972.680.0808
tel;cell:+1 214.502.5664
x-mozilla-html:TRUE
url:http://www.Lymba.com/
version:2.1
end:vcard

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

Re: "cp --no-preserve=mode" doesn't work as-expected

2008-04-24 Thread Jim Meyering 
CJ Kucera <[EMAIL PROTECTED]> wrote:
> Hello...  I've run into a problem best described by a post to this list
> from 2003:
>
>> When the destination file does not exist cp uses the permissions of the
>> source file for creating the destination, as specified by POSIX.  Wouldn't
>> it be useful if --no-preserve=mode would cause cp to use the default
>> permissions (ie. 0666 - umask) instead?
>
> It was said at the time[1] that it'd be taken care of soon, but either
> it never was, or the older behavior's crept back into the tree as of
> 6.11.  It'd be great to have this behavior changed.  It would be quite
> useful to be able to copy files from readonly media (cd/dvd/etc) and not
> have to chmod afterwards.
>
> Thanks!
>
> -CJ
>
> [1] http://lists.gnu.org/archive/html/bug-coreutils/2003-02/msg00051.html

Thank you for reviving that thread.  Actually, I never did fix it.
I remember looking at it, and finding that any fix would be more
than a little invasive.  So, while the value of the fix is obvious,
there was also the matter of risk to the rest of the code, time to
write and test the patch, including the obligatory test suite additions,
so I added it to the TODO list:

  cp --no-preserve=X should not attempt to preserve attribute X
reported by Andreas Schwab

Patches welcome.


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