Re: [PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Jim Meyering
Sami Kerola wrote: > Either this is bug or an unintuitive feature. > > s...@lelux ~/foo touch src dest > s...@lelux ~/foo chmod g-rwx src > s...@lelux ~/foo chmod g+rwx dest > s...@lelux ~/foo ls -l > total 0 > -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest > -rwr-- 1 sake sake 0 2009-03-30 13:

Bug in 'date'

2009-03-30 Thread Sergey Trubnikov
Hi! I'am find a some strange bug in a 'date' program:) Look at this: [...@localhost Shell]$ date +%Y-%m-%d 2009-03-30 [...@localhost Shell]$ date -d "0 day -1 month" +%Y-%m-%d 2009-03-02 but must be 2009-02-30 O_o Thanks for attention. P.S. Sorry for my english :) -- BuG Sergey Trubnikov __

Re: date problem

2009-03-30 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Heiko Schlichting on 3/30/2009 3:29 AM: > Hi, > > I read FAQ 24 ("The date command is not working right") but the following > problem is not what I expect on the day after daylight saving time starts. > All the outputs are done at epoch 1

Re: Bug in 'date'

2009-03-30 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sergey Trubnikov on 3/30/2009 5:54 AM: > Hi! > I'am find a some strange bug in a 'date' program:) > > Look at this: > [...@localhost Shell]$ date +%Y-%m-%d > 2009-03-30 > [...@localhost Shell]$ date -d "0 day -1 month" +%Y-%m-%d > 2009-03

Re: [PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Sami Kerola
On Mon, Mar 30, 2009 at 13:43, Jim Meyering wrote: > Sami Kerola wrote: >> Either this is bug or an unintuitive feature. >> >> s...@lelux ~/foo touch src dest >> s...@lelux ~/foo chmod g-rwx src >> s...@lelux ~/foo chmod g+rwx dest >> s...@lelux ~/foo ls -l >> total 0 >> -rw-rwxr-- 1 sake sake 0 2

Re: [PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Jim Meyering
Sami Kerola wrote: > On Mon, Mar 30, 2009 at 13:43, Jim Meyering wrote: >> Sami Kerola wrote: >>> Either this is bug or an unintuitive feature. >>> >>> s...@lelux ~/foo touch src dest >>> s...@lelux ~/foo chmod g-rwx src >>> s...@lelux ~/foo chmod g+rwx dest >>> s...@lelux ~/foo ls -l >>> total 0

Re: [PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 3/30/2009 6:14 AM: >> I give great value for backups, but still I would like to see new and >> old destination files to have same permissions. Of course when >> --preserve is specified expectation is changed; source permiss

Re: [PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Pádraig Brady
Sami Kerola wrote: > I give great value for backups, but still I would like to see new and > old destination files to have same permissions. Of course when > --preserve is specified expectation is changed; source permission > should appear for the new file. I agree with Jim. Backup file should mai

Re: [PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Jim Meyering
Eric Blake wrote: > According to Jim Meyering on 3/30/2009 6:14 AM: >>> I give great value for backups, but still I would like to see new and >>> old destination files to have same permissions. Of course when >>> --preserve is specified expectation is changed; source permission >>> should appear fo

[PATCH] tests: copy.c destination permissions lost when backup specified

2009-03-30 Thread Sami Kerola
Hi, Either this is bug or an unintuitive feature. s...@lelux ~/foo touch src dest s...@lelux ~/foo chmod g-rwx src s...@lelux ~/foo chmod g+rwx dest s...@lelux ~/foo ls -l total 0 -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest -rwr-- 1 sake sake 0 2009-03-30 13:16 src s...@lelux ~/foo cp --fo

date problem

2009-03-30 Thread Heiko Schlichting
after day light saving starts. $ date -d now +"%Y%m%d" 20090330 $ date -d yesterday +"%Y%m%d" 20090328 Problem! I expect this to be 20090329. More details: $ date -d now Mon Mar 30 00:01:00 CEST 2009 $ date -d yesterday Sat Mar 28 23:01:00

Re: date problem

2009-03-30 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding the list anyway] According to Heiko Schlichting on 3/30/2009 7:09 AM: > Eric, > > thank you for your quick response. I dont't send this answer to the list as > this is a frequent question and bothering people is not my intention. > > But the

Re: bug report

2009-03-30 Thread Philip Rowlands
On Fri, 27 Mar 2009, Mary wrote: I just downloaded the new beta afor 9.04 and had the following experience. For the benefit of the list, I've been trying to help to identify the source of Ubuntu queries by replying "helpfully" to address the question as well as asking where bug-coreutils@gnu

mv: the --reply option is deprecated; use -i or -f instead

2009-03-30 Thread Dennis Heuer
hello, i just read the message as in the subject as i tried to archive some web-pages. the problem with dropping this option is that there is no alternative for --reply=no, if you think twice. this option is quite helpful to not overwrite files of different content but of same name, as is often wi

Re: mv: the --reply option is deprecated; use -i or -f instead

2009-03-30 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dennis Heuer on 3/30/2009 11:10 AM: > hello, > > i just read the message as in the subject as i tried to archive some > web-pages. the problem with dropping this option is that there is no > alternative for --reply=no, if you think twice.

Re: mv: the --reply option is deprecated; use -i or -f instead

2009-03-30 Thread Kamil Dudka
Hello Dennis, On Monday 30 March 2009 19:10:11 Dennis Heuer wrote: > i just read the message as in the subject as i tried to archive some > web-pages. the problem with dropping this option is that there is no > alternative for --reply=no, if you think twice. this option is quite > helpful to not o

Re: [Bug 154602] Re: incorrect cp(1) behaviour upon "mkdir foo; cp -r foo foo"

2009-03-30 Thread Jim Meyering
Jens Ropers wrote: > 2009/3/30 jaduncan : >> This is correct behaviour as per POSIX - it's how it should work! > > Says who? I'm confident that POSIX does not require cp -r dir dir to create dir/dir ;-) >> This is something that would be an upstream bug, but they will not want >> to change this b

Re: new snapshot available: coreutils-7.1.86-9f39f

2009-03-30 Thread Matthew Woehlke
Jim Meyering wrote: One last snapshot before 7.2, just in case... Does this address any of the test failures in [1]? Or are you planning to release anyway? (For the record, I don't remember there being any failures that would keep me from installing 7.2 anyway, but I've seen almost zero foll

Feature Request: List files/directories lexicographically

2009-03-30 Thread Adam Gordon
This seems like it would be a simple feature and while it may overlap with (or be slightly redundant to) the sort command, sorting lexicographically, i.e., foo1, foo2, foo10, foo20 instead of foo1, foo10, foo2, foo20, would be a nice feature to have. --adam __

Re: [Bug 154602] Re: incorrect cp(1) behaviour upon "mkdir foo; cp -r foo foo"

2009-03-30 Thread Paul Eggert
Jim Meyering writes: > I'm confident that POSIX does not require > cp -r dir dir to create dir/dir ;-) That's certainly true: an implementation is clearly allowed to (but not required to) report an error and exit without doing anything when it sees this example. However, that's not what GNU cp