Brian Biswas [EMAIL PROTECTED] wrote:
I'm running coreutils 6.9 on leopard 10.5.1.
% cp file1 file2
works correctly. However:
% cp -p file1 file2
cp: 'file1' no such file or directory
What's really strange is that the cp ***does*** correctly occur
(with permissions
Elias Pipping [EMAIL PROTECTED] wrote:
on bsd-like systems(*), `./configure` fails with v6.9.92. The error is:
checking for library containing crypt... none required
sed: 1: /^gl_INCLUDE_EXCLUDE_PR ...: bad flag in substitute command: '}'
configure: error: internal error:
Thanks Bob,
much appreciated.
Thanks
Syed
-Original Message-
From: Bob Proulx [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 16, 2008 7:11 PM
To: Rahman, Syed A [CMB-IT]
Cc: bug-coreutils@gnu.org
Subject: Re: wc -l is not working the way it should
Rahman, Syed A wrote:
The wc
Elias Pipping [EMAIL PROTECTED] wrote:
Indeed -- all of the above work now. I grew a little more adventurous
and did a `make -j3 check`. tty-eof appears to be moody:
% env VERBOSE=yes make -j3 check -C tests/misc TESTS=tty-eof
[ works fives times in a row ]
% env VERBOSE=yes make -j3
I ran into the same cp -p timestamp problem reported earlier (from
another site):
http://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00047.html
i.e., if one does a cp -p on Linux 2.6, timestamps are not preserved
when the copy is done ***into*** an NFS mounted file
On Thu, Jan 17, 2008 at 03:34:20PM +0100, Jim Meyering wrote:
I've built a new snapshot:
http://meyering.net/cu/coreutils-ss.tar.gz
http://meyering.net/cu/coreutils-ss.tar.lzma
http://meyering.net/cu/coreutils-ss.tar.gz.sig
http://meyering.net/cu/coreutils-ss.tar.lzma.sig
and
[EMAIL PROTECTED] writes:
Did you mean to say that converting any given time to epoch is
invalid for time stamp purposes, or that the date/time format
provided to the -d option in this particular example is an
invalid time stamp?
A bit of both.
Typically the reason for converting to
Bob Proulx wrote:
$ date -d $(date -R) +%s
1200610873
Unfortunately use of -R is not portable. POSIX defines -u however.
That might work better for you in your task anyway.
$ date -u
Thu Jan 17 23:03:27 UTC 2008
$ date -d $(date -u) +%s
1200611075
Oh silly me... Since
Paul Eggert wrote:
[EMAIL PROTECTED] writes:
... or that the date/time format provided to the -d option in
this particular example is an invalid time stamp?
A bit of both.
...
I can assure you that this error occurs regardless of the time
stamp format used/provided.
No, it works
On Jan 16, 2008 12:41 AM, [EMAIL PROTECTED] wrote:
J But the main problem is to figure out where to put such a document
J so that new users will actually read it. What do you think?
Somewhere around
$ info -o - coreutils|grep -C 2 Intro
I'm not sure sure about that at all, because the
Hi, Jim.
coreutils-6.9.92 configured normally has the same problem.
After configuring with --disable-acl, though, it works (no error
message with cp -p)!
We (UNC-Chapel Hill) run coreutils (actually, all of our shared
applications software) over AFS so
disabling acl's
On Thu, 17 Jan 2008, Bob Proulx wrote:
Let me state this in a slightly different way. You are trying to use
GNU date's --date=STRING date parsing extension to parse the
historical default date format. But the problem is that the
historical default date format is not exact and has the
Philip Rowlands wrote:
I'm not quite following, sorry. Absolutely agree that strings like EST
are present as the %Z time zone abbreviation in multiple timezones,
and that robust software should use numerical offsets.
Agreed.
There are always ten zillion things that one wants to say about
13 matches
Mail list logo
